Todo MVC

I started doing web development four years ago. That was the beginning of long fights with my girlfriend who blames me for spending too much time with my computer. Well it’s kind of true but on the other hand, I learned a lot and I came to a conclusion:

I like Lego

whatchu talkin' bout willis?

I believe it’s better to conceive an application by splitting it into smaller and self contained components with lower responsabilities. It gives more control over your application which becomes easier to test, reuse and maintain (see Artery).

Building an application should be like playing with Lego. You choose only the bricks you need, and assemble them to build something amazing. The possibilities are limitless! A brick is something simple, that has one shape and one color. Also, removing a brick and adding one won’t break the others.

I don't need a framework

The future of web tends to be more like lego. A good example would be the imminent coming of custom web elements. That’s one of the reason why I don’t use MVC frameworks anymore!

Instead, I use some small components I developed that does one thing and only one. By assembling them, I have all the features and sometimes more that provide some MVC frameworks. Here's the famous todomvc app built with these components:

All the components can be reused on both client and server side (with nodejs). An other advantage is the control you have over your development. For example, you won’t finish using jQuery just to do some query selections. Therefore, your implementations would be smaller and probably faster. Not convinced? Take a look at my todo implementation and compare to Backbone (implementation and benchmark).

Note

I presented in this post my own implementation of todomvc. The todo mvc website is kind of great to compare frameworks but I don’t think you should use it to choose a framework though. First because building a large scale application is totally different than building a simple todo list. You need to think about the environment before choosing a framework:

  • what client side dependencies manager? (requirejs, commonjs, etc)
  • what package manager? (component, bower, etc)
  • what client side builder? (component, requirejs, yeoman, etc)
  • unit/bdd testing? (mocha, jasmine, etc)
  • assets management? (styl, less, sass, etc)
  • isomorphic? (nodejs)

By experience, asking myself these questions lead me away from choosing Backbone, Angular or Ember. In my opinion, some classic arguments for chosing a framework such as the community or the number of examples found on the internet are not neccesarilly the best ways to go. Unfortunately, the squeeky wheel always gets the greese but it shouldn’t be with coding. If you have a squeeky wheel maybe it’s time for a new one, and that’s my approach to choosing a framework.

I will soon write an article about how important it is to consider an holistic approach when choosing a framework in the industry.