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.
It's the Todo Minimum Viable Product - the simplest and most extensible application you can write - but perhaps it's also the Most Valuable Player in your web development toolkit. I like to think so!
- 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
- ???
- PROFIT!
The project consists (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 that has been put into developing client side browser applications in JavaScript, it's my contention that a good deal of that functionality can be achieved by the correct application of the tried and tested technologies of HTML and CSS, especially in the modern versions, CSS3 and HTML 5.
I also like many of the server side frameworks that are used to write web applications in - Ruby on Rails, Spring, Django for example. But I also believe that for many of the simple (and not so simple) applications that we build on the Web we do not need them.
That is to say that, while I think these frameworks have their place, they can be cumbersome and obfuscating, often no better than using simpler libraries and technologies and often a lot worse.
The subject of this demonstration is the 'todo app', an application for keeping track of a list of tasks and marking them as completed, implemented in a server side language and presented in HTML and CSS.
I don't want people to write everything themselves. That would be stupid. Rather, the idea is to keep it simple. The simplest possible solution to writing a todo application is not a single page app; it's a server side implementation.
'Simple' does not mean we go back to banging the bytes together in raw assembly code, or that we 'build our own framework' (whatever that means). We could argue all day over what exactly 'simple' means. This project represents my idea of simplicity in building an web application - I hope you'll agree.
The following constraints are been followed:
I love JavaScript - I've written it professionally for my entire career. It's wonderful, and fun, and empowering - warts and all. But it's not necessary to write a simple Todo application, and so we won't use it here.
By 'framework' I mean software which requires certain folder structures, configuration files, special commands to run it, and a feeling that you're working in magickal environment where the software you're writing is not in control.
It doesn't mean no libraries - feel free to import any external code (hopefully well written and tested) to build the application.
Put simply, "Libraries: you call them. Frameworks: they call you."
This may be a controvertial definition. Please see this Stack Overflow question if you want more nuance and better links.
As there is no JavaScript, there will be naturally be no front-end frameworks or libraries (React, Angular et al.).
If we were building a real todo application, we would save the todo information to something with a lifespan longer than the running application. As it is, I've taken the decision that to do so would add a fair ammount of incidental complexity, and so the data is stored in memory.
But, as the interface for accessing the todo information should be well defined, it is trivial to swap the in memory implementation out for something else (database, file on disk, etc.).
Again, a 'real' application would have some way of identifying each user uniquely and associating them with the items they create. This would commonly be done with another data store and browser cookies.
I was definitely in two minds as to whether an implementation should support user sessions, but in the end concluded that it would distract from the core of the project. I may feel differently about this in the future.
Each implementation (when there are more than one) should conform to the same API as documented in the acceptance test.
Firstly, every implementation should render the same HTML.
Secondly, that HTML should be accessible.
Thirdly, that HTML is HTML 5.
How that HTML is rendered is entirely down to the application - handlebars, React templates, some big html library. Just as long as it is the same HTML.
Plain, readable CSS 3 should be used pretty-up the presentation. That's not to say that you can't be adventurous, or artistic, or amazing - take a look at what's possidle in the CSS Zen Garden. Only that we don't want any CSS pre-processors constructing that CSS.
And as the HTML is always the same, then the same CSS should work on every version of the application. Which is a nice bonus.
There is an acceptance test which asserts on the HTML and the API of the application. See the acceptance test [README.md][acceptanceReadme] for details.
Please see the CONTRIBUTING.md documentation for details about how you can help.
This started with an angry blog post on Dev.To.
This project takes its sublect matter from TodoMVC, a project which shows off how to build a simple Todo application using client side technologies (such as AngularJS, React and Vue.js).
It was inspired by:
- Adrian Holovaty's dotJS talk A Framework Author's Case Against Frameworks
- Chris James's The Web I Want
It is nothing to do with the Android architecture MVP.
It is up to developers to make their sites work (or at least fallback gracefully) whether JavaScript is or isn't available. The reason for JavaScript being unavailable, whether it's user choice, network conditions or browser interventions, is unimportant. Building a resilient experience is the only way we can serve our users best.