This is the sixth, and final, part of my series on MVCs, where I collected and offered links for getting to know, and get started with, MVCs.
I have focused on what I consider to be the big four right now:
- Intro
- AngularJS
- Ember.js
- React
- Backbone.js
- Summary (this post)
Summary
For me, AngularJS, with its HTML-attribute-approach, had the most comfortable entry, and it certainly has a very strong community right now. Though, with the upcoming Angular 2, which is a complete and total rewrite of the framework, much of what I like about AngularJS seems to be changing to a much different approach, so, take that into consideration…
Ember.js and Backbone.js, with their JS-heavy-approach, had the hardest entry. I also felt both of these had some unintuitive and inconsistent bits here and there (nothing that would make them impossible to use, just stuff you would have to remember, which means they will be Gotcha! moments). But I do love the fact that both of these have the ability to create pages server-side…
And while React also has a very JS-heavy approach, I felt like the more I got to know its code and approach, the more I felt like it would be the one for me. The code seems very well organized, and once I got to know the constructs, they all just made sense to me, and it seemed easy to learn the next one. I am also curious about React Native, which seems to have pretty huge benefits if you think your web app will ever need to be ported to a native app.
I also did some pretty heavy job ad searching to try to get an idea of which is most desired (or at least most commonly referenced). AngularJS easily won the day in my searches. Backbone.js and Ember.js both had respectable showings, and React the fewest (possibly because it is also the newest). So, if you are considering only the job market, then AngularJS is probably the one you should look into, at least right now.
Additional Readings
I was hoping to find a table that compared the total size of each MVC, but since Backbone requires some templating engine, but not a specific one, it is hard to compare accurately. I was also hoping to find a chart that somehow compared community size and update history in an attempt to show each framework’s reliability, but I could not find a good single resource.
The closest comparisons that I did find were Uri Shaked‘s article that I referenced in the Series Intro (which only compares AngularJS vs. Backbone.js vs. Ember.js, but does list Community and Framework Size for each of them, with and without dependencies) and Craig McKeachie‘s Choosing a JavaScript MVC Framework article (which compares several MVCs, including three of the four that I do here (again, React gets the short straw)).
And while hunting for the above data, I also stumbled across two other MVC articles that compare the same four that I have just finished comparing: John Hannah‘s Choosing the Right JavaScript Framework for the Job (which offers individual framework Benefits, Concerns and Bottom Lines), and Tobi Borlinghaus and Daniel Clasen‘s Comparison of 4 popular JavaScript MV* frameworks (part 1) (which compares the Dynamic UI Binding, Reusable Components, and Routing, with textual and code sample comparisons; in Part 2 they compare the Market Share, Community Support and Estimated Growth).
Jonathan M. Hethey writes a comparative piece about Angular, Backbone and Ember. Actually, somewhat similar in depth to this series, he provides high-level analysis and comparisons, and also mentions dependencies, licensing, and additional resources for each.
Moving beyond just the four I compare, Gordon Hempton offers a quick comparison table and pros and cons for several MVCs (including these four). Not much detail, but great at a glance!
Addy Osmani wrote an online book called Learning JavaScript Design Patterns that might help you work through some of the terminology and principles of the MVC world. (Actually, design patterns reach well beyond just MVC constructs, but for the scope of this post, let’s just leave it at that, shall we? :-)
The good folks at The Filament Group have taken the time to do research on, and write about, the Performance Impact of Popular JavaScript MVC Frameworks. With obvious concerns over connectivity, available bandwidth, and download and load speeds, this article should be part of any framework selection process.
Paul Lewis also wrote an interesting piece, based on his presentation at FFConf, in which he discusses “the cost of frameworks”, including framework size, performance impacts, developer time (some decreased, some increased), and discussing the ethical comparison of developer-time versus user-time. Well worth the read or watch, whichever you prefer. Maybe both, it is an important topic…
And to that article Tom Dale offers his response. The point of this rebuttal seems to be that Paul uses TodoMVC for his comparison, and Tom feels the simplicity of this app does not properly evaluate the frameworks because the app is too simple. But wouldn’t a more complex app simply be worse?
But what I think Tom really seems to be asking about is summed up in this statement: “How much productivity will I lose to having to invent, author, and maintain my own abstractions for managing complexity?” And this goes right to the heart of Paul’s article, regarding measuring developer-time versus user-time: which is more important, faster and easier for the developer, or faster and easier for the end-user… It’s your product, and they are your users, so you decide.
Well, I hope this series helped shed some light on the world of MVCs, and which, if any, you might want to start tinkering with. Best of luck!!
Happy MVCing,
Atg