The terror of choice
You’ve now seen (or at least glanced over) four to five different ways of building single page apps:
- Vanilla JavaScript
- Using only small libraries like jQuery and Underscore
- Using Backbone
- Using Angular
- Using Ember
The TodoMVC web page currently has more than 16 different frameworks and libraries listed with a TodoMVC example. Given that not all existing ones are listed at TodoMVC, the abundance of choice can be overwhelming. But rest assured: It’s even harder for me as an author to give you some advice here. I’ve used some of the frameworks, some in more depth than others, but the variables are just too a many.
What I can do, though, is try to explain some of the criteria I would use to choose a framework.
The ecosystem
All big names on TodoMVC have a decent eco system, especially the ones I’ve used as examples. And with ecosystem I don’t only mean a lot of plugins, extensions and examples, but also stuff like a strong support community and useful documentation. How many books are available. How good are the StackOverflow answers. And so forth. This seems not so important at first, but believe me, it makes a huge difference in the long run.
Aesthetics of code
I personally find this important. For example, I find Angular templates, and Angular code relatively unpleasant to read. All the dollar signs. And the wild mixture between HTML and code. I’m not a fan. I find Ember code to be quite nice to read, on the other hand. But opinions on aesthetics differ in many ways and for some people, it’s just not as important. One way to test for this is relatively simple: Open a random file from one of the TodoMVC examples and see how long it takes you to understand what’s going on. Because if it appeals to your sense of aesthetics, chances are that it is easier to understand for you.
Structure
How much structure does the framework or library provide? How easy is it to change this structure or to use your own? How much does the framework resist bending the original conventions? Does the framework have strong conventions in the first place? These are things to reason about with the whole team you’ll be working with on the application, as every team has different opinions on all of these topics. I personally find strong conventions helpful as they usually mean that you can start relatively quickly actually building stuff. On the other hand if you have the feeling that you constantly have to work against these conventions, then it’s probably not the right framework for you.
Performance
Different frameworks have different performance characteristics. For example, Ember has a very efficient way of doing intelligent updates on views, so if you’re doing a lot of small view updates in your app, this might be a factor. And performance does matter, especially when building mobile applications. As there’s no clear “this framework is slow” vs. “this framework is fast”, when in doubt, benchmark your specific usecase.