As probably every other javascript developer wannabe in the last few years, i’ve been completely paralyzed in my analysis of different framework options for future JS development. There is so much going on and the landscape is changing so rapidly that it’s really hard to keep track. But after an exhaustive research I think I finally decided on the technology I am going to choose for my next project. Do note that this is not going to be a pure developer-side analysis, this should also be relevant to someone who wants to choose a solid career path or a product manager who is choosing the next team tech. I must say this is definitely the right time to get into JS MVC frameworks since we can finally see some consolidation going on, which i will explain shortly. The candidates i considered are the ones from the title: React.js, Ember.js, Durandal.js, Angular.js, Knockout.js, Backbone.js. First a few words and impressions about individual tools:
Knockout.js
Binding library which is also a part of Durandal, i think it’s a good solution for basic binding needs, but not quite the type of solution i hoped for. Anyway on to the next…
Backbone.js
The grandpa of JS mvc frameworks. I haven’t looked at it much since everyone says it’s pretty basic, you need plugins like marionette (good/bad), and from what i gathered everyone’s transitioning to play with the newer kids on the block. For a guy that came from Silverlight, using Caliburn.micro with conventions and MVVM, when i saw a lot of “boilerplate” written next to it’s name i hardly gave a serious thought to it any more. FINAL VERDICT: Oldie but goldie. Speaking of new kids on the block…
React.js
Definitely the one i was most interested in, i really think it’s an amazing solution. It’s a paradigm shift and a way of thinking that really resonates with me. I love the tools, philosophies and extensions people are developing around it (like Om, Clojurescript support ). But it lacks battle proof. As a .NET guy, i don’t like the tooling story just yet. Altough you can get MVC5 supported nuget packages, JSX Visual studio support (judging from my Google search) is non-existant. If i was a sublime text guy, i would absolutely consider it. The other problem i have with it, i’m not quite sure how it would behave with data intensive applications with grids and forms, and i don’t see how to integrate it with some out-of-box components, like syncfusion or kendo. I absolutely love the principle of js-only components, doing away with templating etc. I just need to see more examples, better support, bigger community etc. FINAL VERDICT: Up and coming and very promising, something to keep an eye on, but more examples and support needed. Strong backing, and judging by how they treat ASP.NET, a very bright future is in it for a .NET guy. Speaking of support….
Durandal.js
Aaand we have our first JS MVC war victim (and as always, the innocent suffer first). Durandal.js was my favourite just a few months ago. It looked extremely solid, and it was built by a guy who was into UI frameworks for the last XY years, the father of Caliburn and Caliburn.Micro, Rob Eisenberg. I fell completely in love with Caliburn.Micro, it’s the best code i’ve ever seen and having a same guy do a JS framework… well, i was completely sold. Until 2 weeks ago that is. Turns out Rob is now in bed with the enemy.He joined the Angular 2.0 team and they are building the next generation of web. Which honestly is kind of relief because that leaves me with less to choose from. FINAL VERDICT: Silverlight-inspired framework going the way of silverlight:(. So now that would make Rob’s biggest “enemy”….
Ember.js
That would be my second favourite. I’m always keeping an eye on what’s going on over the fence, and since Ember is a brainchild of Rail-heads, I was very intrigued by a prospect of integrating Ember with my ASP.NET MVC app. The opinionated nature, the convention based development, the battle-proved worthiness, the genuine open-source nature of the project, the pit-of-success enforced structure resonated very much with my way of thinking. I still feel it’s the most complete solution, and the one that has the best feature set and performance, and it’s an ideal one…. for a rails developer. Or even for a python dev, or php. It’s just not that great for a .net dev. The main issue is the fact that Ember owns your data model and therefore it makes it harder to use data library like Breeze. And Ember-data doesn’t support OData, which i may or may not use (haven’t decided yet). Other than that, when searching for a kendo-ember integration, results came out pretty scarce. There are some Ember-specific girds and controls, but i really don’t want to be framework-bound when choosing my controls. FINAL VERDICT: Fantastic framework with the right idea, but without appropriate following, support and mindshare. And speaking of mind share…
Angular.js
Takes the crown. Angular strikes me as a middle-of-the-road solution all-around. It’s opinionated but not completely, it has less then Ember but more than the rest, it’s somewhat structured but less than Ember. I don’t like it honestly, it has too many weird and angular-specific concepts (and i usually don’t like the middle-of-the road things). But I’m completely buying the future of Angular and the mind share. Every control vendor i googled has some kind of angular integration, and 3rd party libraries cannot afford to ignore it. If you want to use them, your best bet is Angular by far. Model is a simple Javascript object (Pojo) so it’s dead simple to integrate with breeze or similar. The 2.0 version will be also built and supported by a guy who did Durandal, so I have high hopes for that one. The visual studio integration is also very decent, the Microsoft team is also using it, PHP guys are using it, Angular guys are well connected to Chrome developers (not something you should ignore), basically everyone is using it. Oh and there’s also this…
It’s a pretty safe bet your Angular skills will be in high demand, and learning the concepts and quirks should pay off in the long run. And to all the PMs, the Angular talent should be the easiest to find in the future.
FINAL VERDICT: King of the hill, whatever you might think of that.
So that would be my recommendation for a JS MVC framework. Keep an eye on React, try out Ember to learn the proper way to structure a JS app, forget about Durandal, for widgets and smaller stuff try Backbone or Knockout, but keep your Angular strong.
Seva Jan 21 , 2015 at 6:52 am /
Thank you for the great overview! 3d party support for data and ui libs playes huge role in enterprise web apps.
J. Merrill Jan 25 , 2015 at 5:17 pm /
Now that Rob has fired the rest of the Angular team (so to speak) and is going back to Durandal, are you going back? I certainly am.
benzen Feb 17 , 2015 at 5:45 pm /
Hi,
I found it very interesting to use google trends to find out what is hot at a time.
But i things the terms you searched are not exactly the one used by the community.
I think that these one are more accurate.
http://www.google.com/trends/explore?hl=en-US#q=Angular%2C%20Backbone%2C%20Ember%2C%20React&date=today%2012-m&cmpt=q&tz=
Your point still hold, but the number looks more realistic.
By the way, if you can change the css of the comments to make it bigger, it will be helpfull.
Bruno Samardzic Feb 20 , 2015 at 12:17 pm /
What difference a year makes:)
J. Merill, not sure really, i like the new initiative from Rob, but as I already highlighted in my post, i am pretty intrigued by React, and that interest has only grown lately. I am currently investigating into how far i am able to push it in terms of convenience.
As i see it, there are basically 2 different types of web applications: data manipulation apps, and data presentation apps. For instance, on a typical web site, The back-end is all about making data manipulation as convenient as possible and the front-end is for making display as convenient as possible. Frameworks like angular, ember etc, can only justify their complexity overhead if you have lots of forms, interactions and data, otherwise you don’t really need the data-binding that much. React on the other hand is view only, and very much suited for front end, but some people have extended the concept to some new heights, and i’m currently investigating that. If the solution proves lean, i might just ditch the databinding alltogether, and go with the react+flux. The thing is, with data heavy apps, presentation is very much dictated by data, which makes data-binding a natural fit (think validation, conditional formatting etc). I’m interested how React solves those types of problems.
@benzen: yes, your results are probably more inline, but i was worried about false positives (backbone, react and probably angular are also plain english terms, especially backbone). I did make a mistake in my chart, i ommited the dot from angularjs. If you put that dot in, the results look much more different.
Bruno Samardzic Feb 20 , 2015 at 12:23 pm /
Ok, i updated the chart to reflect yours, i think it’s better aproximation. One very interesting thing about angular is a huge drop during holidays.
This probably means that angular is currently an industry standard, ie. it’s used a lot at work, but less outside it.