Earlier this year I wrote:
which caused something of a kerfuffle. I think the polite way to describe the response would be 'mixed, but passionate'.
So, because it's better to light a candle than curse the dark, I'd like to introduce a small project I've been putting together called Todo-MVP as a way of demonstrating some of the ideas I've
ranted talked about.
But first - I'll recap the original post and have a go at responding to some of the more common criticisms.1
I think that web frameworks add incidental complexity to projects, taking control from the developer who is using them and placing it in the hands of whoever wrote the framework. As such, we're forced down particular ways of architecting and configuring an application which may not suit our needs or purpose. We will probably not recognise this at the beginning of a project, but by the time that we do we will be so 'embedded' within the framework's system that it will be hard to make the necessary changes.
More strongly, the reliance on frameworks becomes a vicious circle; when we lack the skills to build web applications from simple libraries we will turn to a framework to build our websites, and when that inevitably fails us in some way we will seek another equally unsuitable framework.2
Finally, the 'framework first' mindset scares people away from even trying to write an application without a framework - they automatically assume it must be hard as, if it weren't, then there wouldn't be a framework in the first place. This is untrue. It is just as easy to understand and use a collection of well written libraries to build your applications as it is to use a framework, and you do not leave yourself open to the problems listed above.3
Some people seemed to think that I want to write everything in C. Or assembler. No; although that might be fun it would probably be inefficient in terms of time.4 My issue was specifically with frameworks. A good definition of a framework might be:
You call a library's code. A framework calls your code.
Read this Stack Overflow question if you would like more nuance. But, if you hadn't guessed, in my eyes the libraries are (mostly) the good guys. So - use libraries (hopefully ones which have good abstractions), avoid frameworks.
Others claimed that they 'would end up building a framework themselves' if they didn't use a framework. This is unlikely, unless they want to optimize for churning out multiple applications with identical structures. You will not 'build a framework'.
What you will build is the application you were trying to build in the first place and - nothing more. If you've done it right it will be flexible enough to change and grow in the future.
Adrian Holovaty puts it better than me in this talk - he's fluent, polite, and plays better jazz guitar:
So in the interests of putting my money where my big mouth is I wrote this:
The objective of this project is to demonstrate that it is relatively simple to build web applications using HTML, CSS and a small amount of server side code written in a language of your choice.
- Working Todo-MVP application
- Nice CSS
- Good a11y
- Simple acceptance test
- Best in class a11y
- Implement in multiple languages
- Multiple CSS files
- Automated deployment
- Automate the acceptance test
The Todo Application
The project consist (or will consist) of the following:
- Many Todo applications, written in multiple languages, all each serving the same HTML and implementing the same API.
- An acceptance test to confirm that the application does the above
Whereas I respect the skill and effort…
This is my take on the TodoMVC idea, but instead of building the Todo application using a variety of frontend frameworks, I've tried doing it with a variety of webservers written in different languages.
They all implement the same API using HTTP network calls to control the application. And they all render the same HTML elements, which can be styled with the same CSS.
I'm trying to demonstrate here that you don't need a framework - you barely need any libraries - to build something that works, is usable, and that you can understand and build again and again.
The idea isn't to build a complete application - in real life you'd want to provide some persistence (like a database), individual user sessions, identity, authorization... all things that I'm happy to skip over with this example but which should not be hard to implement as much or as little as you need.5
A running instance of one of the implementations can be found at todo-mvp.com.
Please help me! Could you spend a bit of your hacking time building a simple implementation in the language of your choice? Even if someone else has done it in a language you like, you could do it again but demonstrating different libraries, a different approach - even using a framework if you'd like to show how that would work.
Read the contributing guide, write an implementation, run the acceptance tests and get a pull request in.
Also - everything can be improved in every way! Feel free to write some amazing CSS if that's where you can shine, help me improve the app by spotting and fixing accessibility issues, help write some documentation...
There's so much... to do 😉
You should really read the original comments and criticisms - some of them are comedy gold (in a good way!). ↩
This also leads to groupthink (framework think) with respect to architectural patterns. Your application may not fit neatly into a MVC RESTful CRUD application, but it's likely that that is what you will have to build with a framework. ↩
The real point of a framework may be to enforce a project structure and architecture on you. If you want this - then fine, go for it. But I don't believe that that is a good value proposition. ↩
But it could be amazingly efficient in terms of your paycheck - keep billing kids! ↩
Or use an external service - IDaaS is increasingly popular. ↩