

Choosing the Right JavaScript Framework - elkelk
http://www.airpair.com/js/javascript-framework-comparison

======
bsimpson
I just did a bunch of research on state-of-the-art JS architectures for a new
project I'm working on, and neither of my first two choices are on this list.
(Granted, they aren't restricted to MVC either.)

Polymer is interesting because it's the first one that's geared around the
idea that the browser is an app rendering engine, not a document reader. Being
able to declare your own HTML elements and bind them together could very well
be the future of web development. Unfortunately, it's still a bit immature to
use commercially.

Hence, I chose React. It's idempotent, which is a fancy way of saying the
markup it outputs is a strict function of the inputs it's given - no side
effects, no externally-mutable state. This means you can live-edit your markup
in your favorite editor without having to reload the browser on every save
(using a tool called the Webpack Dev Server with the react-hot package). Using
Webpack also means your dependencies are explicitly declared with `require`
statements. It has all the benefits of Angular's Dependency Injector without
all the boilerplate.

Finally, and perhaps most importantly, it has 0 dependency on the DOM. This
means you can render your initial request on the server, and pass markup down
to the client that's indistinguishable from what you'd traditionally get from
Flask/Django/Rails/PHP. There are no assumptions that your client speaks
JavaScript, so it's more friendly to non-browser clients like searchbots,
which is in turn safer for SEO. It also means your view is already rendered
when it reaches the client, which is important in a world where many clients
are phones with underpowered JS capabilities. You get both the benefits of a
single-page-app (slow client rendering is still faster than slower network
requests, and network requests are smaller if you don't have to also send down
the template every time) and those of a server-side one (SEO is maintained,
and the client can display your page without waiting to execute the JS first).

I should disclaim that I haven't seriously considered Ember since it's been
rebranded from SproutCore; however, I have worked on a few Angular apps; and
even forgoing the above benefits, React is just easier to work with.

~~~
someone13
If you don't mind sharing, have you done any research on data layers for
React? From what I can see, there seems to be three major schools of thought:
the Flux architecture, using Backbone's models, or just writing something
custom.

~~~
bsimpson
Still working on the data layer, but I think I'm going to use Reflux. One of
the things I was initially skeptical of React about is its lack of support for
custom event bubbling (which is the technique I like to use to keep my
components decoupled).

Flux lets you cheat around that: Since you're using require statements, you
can make an action and `require()` it in both the component it's dispatched
from and the one that's listening to it.

    
    
        // Traditional event bubbling
        child.dispatchEvent(...) ----> parent.addEventListener(...)
        
        // Reflux
        child:action() ----> store.listenTo(action) ----> store.trigger(data) ----> parent.listenTo(store)
    

The store is an extra layer of abstraction, so you can assimilate data from
different sources (user interaction, server events, etc) into one format
before passing them into your datastream. Facebook's Flux has yet another
layer of abstraction called the Dispatcher.

Honestly, I'm murky on the utility of the Store and even less confident in the
utility of the Dispatcher. That's why I'm using Reflux instead of FBFlux, and
I'm still tempted to skip the store and just listen to my actions from the
parent component.

------
thom_nic
For everyone here who says "Backbone is great except..." I'd encourage you to
try Apmersand.js from the great folks at &yet. It's nearly idential to
Backbone, fixes some of the oddities (like wrapping divs and needing to call
model.set/get) They've also worked to make it more modular and extensible.

[http://ampersandjs.com/](http://ampersandjs.com/)

------
robot
The article is very much inclined towards angular. I find Ember much easier to
develop with due to the neat separation of application logic and HTML. In
Ember, most of the logic is in the javascript, templates merely serving the
final result in a presentable way. In Angular I dislike to see the angular
specific programming logic molded into HTML. In my opinion HTML is just a
presentation layer. An example from angular:

<li ng-repeat="phone in phones | filter:query | orderBy:orderProp"> for me
this is too much programming logic in html. Same goes for React.js too. Too
much html + logic mixup, that requires two parsers to work in your head in
parallel (html + javascript, and maybe even some css?). I find it messy.

None of it in ember. Logic is neatly separated. In ember I also really enjoy
how you separate functionality on a single page into neatly defined
controllers/routes/ and components.

Also the article says you add lots of <script> tags to your code. Not true.
Using ember-cli you don't see any <script> tags.

~~~
bsimpson
I've always found it weird that many people put the HTML, JS, and CSS for one
component in three different files, but never thought enough about it to put
it into words. Pete Hunt (one of React's maintainers) does that here:

[https://www.youtube.com/watch?v=DgVS-
zXgMTk](https://www.youtube.com/watch?v=DgVS-zXgMTk)

React is about separating concerns, not technologies. Everything you need to
know to draw an App Bar is in AppBar.jsx. You can dynamically generate the
markup with JavaScript, but that doesn't change your separation of concerns,
because everything concerning that component lives in that file.

------
acconrad
The comments are already pretty deep, but I still want to mention that the
right framework is all dependent on what your needs are and what your company
is willing to support. Which is why I get tired of article comparisons like
this, and trust me, I wrote an article on choosing AngularJS[1] but I still
wouldn't push it on anyone.

Each framework has it's advantages, and it really depends on where you and
your company align with those advantages. When I started my journey I realized
I needed better testing for AJAX events in jQuery, which lead me to Backbone.
But in 2012 Backbone seemed like an outdated solution to an outdated app
landscape. Now it seems even more outdated, but learning it certainly helped
elevate my JS game to choose between Angular and Ember (though now I'd through
React/Flux and/or Meteor into the mix).

From there it's really about what you need, as I've said before. For me, a
lightweight, performance-driven solution with a great testing framework was
necessary. Angular is lighter weight than Ember, but both have great testing
frameworks, so Angular won. If I wanted better documentation, an easier
learning curve, or better community support (it happens that Rails people seem
to like Ember because Yehuda works on it) I would have chosen Ember, but that
wasn't important to me or my company. Again, that was 2012-2013, today I'm
still using Angular but entertaining the idea of having React replace Angular
directives, which I still don't like writing. Again, it's all about what works
for you and your organization, and that really is about introspection, not
about what some article can do to act as your oracle.

[1] [http://code.tutsplus.com/tutorials/3-reasons-to-choose-
angul...](http://code.tutsplus.com/tutorials/3-reasons-to-choose-angularjs-
for-your-next-project--net-28457)

~~~
fennecfoxen
> But in 2012 Backbone seemed like an outdated solution to an outdated app
> landscape

Eh. Backbone is good for enabling small elements of interactivity on mostly-
static web pages (a design which isn't dead yet and useful if you have a lot
of people landing on a lot of individual pages from third-party sources search
engines or the like, and you want to keep down page load times). Angular and
Ember are much more targeted at fancy interactive web apps where you want to
stay in one DOM for a longer amount of time while doing a lot of interaction
or page manipulation.

So this part:

> the right framework is all dependent on what your needs are

~~~
lsdafjklsd
I would absolutely not use Backbone for anything view related anymore.
React.js is a much better choice, even for just enabling small islands of
richness.

------
grimtrigger
If you're just getting started with frameworks, I'd recommend Backbone. You
can learn it in half the time it takes to understand Angular and it'll be a
good introduction to MV*. This is probably why its more popular than Angular -
its easier and its good enough. Angular has a lot of "magic" which can be
intimidating and frustrating. Also writing JS logic in html just feels icky
when separation was the manifesto for so many years.

That being said, there's many times where I work with Backbone and I feel like
its missing pieces it should have. I don't have too much experience with
Angular but it seems to be a much more complete choice.

~~~
aikah
> If you're just getting started with frameworks, I'd recommend Backbone.

Backbone only is not enough to do any serious kind of work today.One always
end up with tons of plugins making it as complicated as EmberJS or AngularJS.
There is no serious view layer,so one has to use React,Vue,or Ractive. The
router sucks,frankly,so one has to replace it. The model layer doesnt handle
relationships between model,so one ends up using something else...

There is nothing good in Backbone today frankly.It was one of the first
successfull "clientside" framework ,yet refused to evolve(like underscore or
coffeescript today),refused to incorporate good ideas from third parties that
would have made it still relevant today.

There is no future in Backbone.Maybe there is still a place for a Backbone
like framework that would still be based on jQuery and would incorporate a
better view layer. But Backbone itself is dead.

I personally prefer AngularJS ,not because of its directives but because I
strongly believe in IoC containers over any other way to build and wire
objects. But I think EmberJS is as good.

~~~
ChrisAntaki
> There is nothing good in Backbone today frankly.It was one of the first
> successfull "clientside" framework

AngularJS was released in 2009 [1], whereas Backbone was released a year later
in 2010 [2].

[1]
[http://en.wikipedia.org/wiki/AngularJS](http://en.wikipedia.org/wiki/AngularJS)

[2]
[http://en.wikipedia.org/wiki/Backbone.js](http://en.wikipedia.org/wiki/Backbone.js)

~~~
aikah
> AngularJS was released in 2009 [1], whereas Backbone was released a year
> later in 2010 [2].

Sure,that's why i said

> It was one of the first successfull "clientside" framework

Did you miss the word successfull or what?

furthermore old angularjs looked more like Adobe Spry than current
AngularJS,while Backbone hardly evolved(which is not good of course).

~~~
ChrisAntaki
> while Backbone hardly evolved(which is not good of course)

Backbone is a much simpler library than Angular. There's less of a need for it
to evolve, since it's meant to be extended on a per project basis.

~~~
aikah
I disagree totally.

------
lhorie
If you like React for its virtual dom, but are looking for something more MVC-
ish, there's also Mithril (
[http://lhorie.github.io/mithril](http://lhorie.github.io/mithril) ).

Some of the pros are that it's easy to learn (e.g. if you know js, you already
know the templating language syntax), and it's one of the fastest frameworks
in the market right now.

There's also a more detailed comparison w/ other frameworks here:
[http://lhorie.github.io/mithril/comparison.html](http://lhorie.github.io/mithril/comparison.html)

------
andrewvc
What, no React/Flux? How can this be a serious comparison without React?

~~~
megaman821
React + what? Is there a standard router/controller and model that get's used
with React?

I think they just could have added the line "As an alternative to using
underscore templates in Backbone, you can use React instead."

~~~
compedit
There's no standards, but at this point I'd say Flux + React-router are
quickly becoming it. react-router is made in the spirit of Ember's which is
pretty well liked.

\- Flux Architecture Pattern [0]

\- React Router [1]

Note that there isn't really a prescribed model in Angular aside from $scope
either.

[0] - [http://facebook.github.io/flux/](http://facebook.github.io/flux/)

[1] - [https://github.com/rackt/react-router](https://github.com/rackt/react-
router)

~~~
megaman821
I like react-router that looks quite nice. Flux looks like a description of an
idea rather a JavaScript library. Is there a flux store that persists to a
REST backend?

A model really isn't part of Angular core since it was split out but something
like angular-resource is what I am talking about.

~~~
compedit
I'd recommend looking at the docs on Flux, it explains it all better than I
could.

------
bsaul
Another framework i barely hear about and surprised me a bit recently is
sencha/ExtJS. They're growing a lot in the enterprise sector, but they managed
to keep pretty up-to-date relative to web/open sources projects such as
angular.Eg they added two-way data binding in their latest version in a not-
to-ugly way.

Anyone here got a real try on sencha (the full package, including sencha
architect) recently ?

~~~
moriarty-s3a
Don't bother. It is many times larger and slower than any of the frameworks
listed. Their code is also broken in "interesting" ways and there are lots of
undocumented and semi-documented gotchas.

It got enterprise traction because they were early to the game and promised
MVC. They were pretty good for a while, but the other frameworks have passed
them by.

------
rymohr
Every few months I review the top js frameworks and always come to the same
conclusion: for existing projects you're probably better off sticking with
what you're already using.

Each framework follows such a different paradigm that it's hard to transition
incrementally, especially if you're app has a rich data layer rooted in an
existing framework's mentality (in our case the backbone model/collection/sync
mentality).

I'd love a better view framework, but not if it requires a full rewrite of the
model layer and all the related libraries.

Until there's a ruby on rails quality model/collection/associations library
that can be paired with a performant view framework with two-way data binding,
I'll just stick with backbone where things are simple. Even if it costs me a
few extra keystrokes.

> A good rule of thumb is not to have more than 2,000 active bindings on the
> same page.

Anyone personally run into this? What are you supposed to do in angular if you
need to listen to change events for thousands of models?

------
geodude
"The scope hierarchy in Angular uses Prototypal Inheritance, which is a new
concept to grasp for people coming from Object Oriented languages such as Java
and C#. Failing to understand scope inheritance causes many cases of
frustrated developers ..."

This is javascript in general not just AnjularJS ... it seems that Google has
created a framework that does a little too much. Half the time im doing
something that has already been done a thousand times , either making a tab
content layout, displaying a dialog , performing an ajax request and editing
markup ... I dont need fancy scope for these things. And when I do ill write
my own state machine. I feel like all the special AnjularJS features are built
to handle stuff like google docs. Most of us dont need this, not every one is
on the "kill the desktop application long live the web-app" koolaid ... And
ill keep my js logic out of my view and markup, thank you very much (did we
not learn this is for the lazy not the smart a long time ago)

------
obiefernandez
It seems like Backbone is dominant, but after a couple months of using
AngularJS on an everyday basis I'm ready to switch and never look back. Hands-
down best framework I've ever worked with. The pleasure I get from it reminds
me of the early days of Rails, when the leap in productivity was palpable.

~~~
capkutay
While Backbone's strength is its lack of assumptions and 'freeness', angular
forces developers to strictly follow their constructs. Marionette [0] is an
extension of backbone that also forces developers to follow constructs that
lead to scalable, modular web apps. Marionette makes backbone feel like a tool
to make prototypes.

0: [http://marionettejs.com/](http://marionettejs.com/)

~~~
obiefernandez
But how big is its community?

~~~
jenius
Marionette has a great community, and is super easy to get help with things.
I've been involved in the marionette community for a while and it has always
been absolutely wonderful. You can almost always get help directly from the
core team on their gitter chat here
([https://gitter.im/marionettejs/backbone.marionette](https://gitter.im/marionettejs/backbone.marionette)),
and I have met in person with all of the core team members at meetups, they
are very smart, dedicated and friendly.

While angular has tons of beginner hype because of the bootstrap effect (don't
learn a technology, just put it in your html tags!), I've found that
marionette tends to attract a more mature developer crowd, and as a framework
is much better suited to building large and complex apps anyway because of the
strict modularity and separation of concerns. I say this from experience both
seeing and working on very large and complex apps with marionette. And if you
don't believe me, ask some of the developers at Etsy, who build with
marionette.

The community is a hell of a lot smaller than something like angular, but I
see that as a huge benefit, especially when that means no proliferation of
beginner problems, and easy access to the core team for help or feedback.

------
bellerocky
> Backbone lacks support for two-way data binding

Actually Backbone is painful because of the two way data binding. You do have
to write way more boiler plate, but forms and actions in views will update
your models and so will content coming in from the server and your event
listeners have to be able to ensure that your events don't runaway from you
causing all kinds of problems. Like view action -> updates model -> listener
sends something to websocket -> websocket sends a response event -> updates
model -> listener sends something to websocket -> an error or infinite
recursion.

~~~
henryw
Rivets.js can be added to backbone fairly easily to support 2 way binding.

------
rdtsc
To me, out of all of those, React looks most impressive and interesting.

------
LunaSea
"Choosing the Right JavaScript Framework" \- by someone wearing an Angular
t-shirt and an Angular sticker on his laptop

I'm sure it's not going to be biased at all.

------
clairity
i appreciate the author's effort but don't feel like i have a better handle on
the applicability of each framework to real projects (like many similar
articles). basically, this article lists some good and bad features of each
framework with some light commentary about a few of those features, which
means it doesn't really help you answer the question implied by the title
("which js framework should you choose?").

i think it might be better to use a non-trivial example and show side-by-side
implementations for 10 or so important aspects (routing, templating, data
binding, etc.), with commentary on what kinds of projects would benefit the
most from each frameworks' approach to each aspect. since airpair is about
selling programming expertise, this would demonstrate _actual_ expertise that
would be attractive to prospective customers (vs. the ability to talk about
programming, which is easier).

~~~
morty16
There's a recent release by O'Reilly called "Choosing a Javascript Framework"
([http://shop.oreilly.com/product/9781939902085.do](http://shop.oreilly.com/product/9781939902085.do))
that you might want to look at.

It covers the same frameworks (Angular, Backbone, Ember) and also mentions
Polymer and React.

~20$ for the early access version.

~~~
clairity
nice! seems a bit pricey for a rough draft ebook though. but i do like that it
includes polymer and react, which i know little about.

what i find interesting with these frameworks is that they're all moving the
templating engine (something like coldfusion from 15 years ago, ha!) to the
frontend... part of the ebb and flow of server vs client side computing i
guess.

------
j_s
The previous comparison of Angular vs Ember back in May included a lot of
interesting discussion, such as which companies were using which framework and
a lot of anecdotes from developers with experience with both:

[https://news.ycombinator.com/item?id=7679116](https://news.ycombinator.com/item?id=7679116)

------
libria
Enough with the "No X? [http://www.X.ly"](http://www.X.ly") comments.

Assuming you're not spamming, submit an article yourself or talk about your
framework's tradeoffs engaging points from the article above.

~~~
ufmace
That's the messy thing about the JS framework ecosystem. To the outsider, it
looks like there's roughly a kazillion frameworks, and it's difficult to tell
what they all do, what the differences are, and how to make a reasonable
decision on which one to use for a project. Post a decent comparison article
like this, and you get buried in comments about how you skipped these
frameworks or those plugins.

------
fndrplayer13
I enjoy that the conclusion is essentially that they all have great features
and pain points. I personally like Angular, but I know a number of developers
successfully using Backbone.

------
Terr_
After searching the comments here too... is Dojo just too old/unsexy, or is
there some sort of filtering criteria for "Javascript framework" that I'm
missing?

~~~
angersock
Dojo is huge and old and bloated, and has a lot of great features.

Personally, I'm a bit suspicious of any JS framework more than a few years
old, barring a few notable exceptions (jQuery, bootstrap, etc.).

Dojo is just too large for me to feel comfortable using it in an app--with
Angular or Backbone, I know there's only so much crazy in the tin; Dojo has
mudballed a lot.

------
himanshuy
No Meteor?

~~~
KurtMueller
I think the author is only talking about what he knows... I hope that is the
case at least.

As for Meteor, I think this was a comparison of frontend-only js frameworks. I
would love to see a Meteor vs. Rails vs Djano comparison however :).

------
al_the_x
Great article. Really loved the "Good Parts" vs "Pain Points" for each
framework.

------
desaideas
With so many js frameworks it's great to get an experts evaluation of the
differences.

------
restlessdesign
“Backed by Google…”

Yeah, but so were Google Reader and Google Wave.

~~~
aikah
Google reader wasnt open-source.As Google Wave,I believe there is an open-
source version.

------
prtkgpt
AngularJS is awesome!

------
carsongross
But, but, but... what about the Un-JS Un-Framework, intercooler:

[http://intercoolerjs.org/](http://intercoolerjs.org/)

</shameless-plug>

~~~
dmux
Thanks for posting this. I have yet to get into front-end work, but this looks
like the least painful way to dive in I've seen.

------
ld00d
No Durandal? [http://durandaljs.com/](http://durandaljs.com/)

~~~
patja
My reading of the roadmap is that Durandal is pretty much being absorbed into
Angular 2.0

~~~
bronson
Yes, here's the announcement: [http://blog.angularjs.org/2014/04/angular-and-
durandal-conve...](http://blog.angularjs.org/2014/04/angular-and-durandal-
converge.html)

If it reaches anywhere near its potential it's going to be awesome.

------
Fjejfhfheifjv
JS frameworks are absolute cancer. They do nothing but kill page load times
and degrade user experience: since when is it a good idea to recompile the
whole entire standard library each time a program is run? They're also
completely redundant in the modern browser, since standard compliance has
gotten much better and more features have been added to HTML/JS/CSS. It's just
yet _another_ api that developers have to learn to code against, despite not
offering any additional features.

~~~
themoonbus
I consider developer productivity and code maintainability to be features.
Sure, there are performance tradeoffs, but there are some obvious benefits.

~~~
aikah
> I consider developer productivity and code maintainability to be features.
> Sure, there are performance tradeoffs, but there are some obvious benefits.

In a client side application,if the app is slow,the users wont be happy about
it.

If it takes for ever to load,the users wont be happy about it.

On the server there is always caching so that requests never hit the app
itself.

On the client,if the js code is slow ,for whatever reason,you cant hide it to
the user.

What you say might be true on the server,these "features" definetly have to be
balanced with performances on the client.That's why sometimes it make sense to
use React over AngularJS,for instance,because Angular is known to be slow.

