Note: these are pretty rough notes I made for my team on the fly as I was reading through some pages. Some could be mildly inaccurate but hopefully not terribly so. I might resort to convenient fiction & simplification sometimes.
My top contenders, mostly based on popularity / community etc:
- Angular
- Backbone
- React
- Ember
Mostly about MVC (or derivatives, MVP / MVVM).
- A way of cleanly separating data, presenting data, and business logic
(e.g. “To get the total exports of a country, you must sum its exports
with every individual country”). Following definitions differ slightly
depending on which interpretation you’re using, but the gist is similar.
- Model: Provider of data - could be an API. Could be a javascript object. Could be anything. It’s the “state” of the application, anything from the data in your viz to which buttons are current clicked and whether we’re showing exports or imports.
- Controller: Sits between everything and decides how to process the user input, where to gather data from, what to do with it, etc.
- View: e.g. templating - how the application actually looks to the user and where the user interacts with the application.
- Why? e.g.
- You can change the data source for a viz without changing any visualization code
- You can change the design of a viz to, say, use a different CSS library without changing UI logic
- Basically much less entanglement in general. http://programmers.stackexchange.com/questions/105352/why-should-i-use-an-mvc-pattern
Some terminology:
- Two way data binding
- I change something in the view (UI), the model (state data) changes automatically. I change the model, the view changes automatically. See: http://n12v.com/2-way-data-binding/ especially the angular example is pretty concise. Saves a lot of time and reduces bullshit boilerplate code.
- Dependency injection
- A technique where the framework loads modules automatically for you. So let’s say your app needs a NetworkGraphVisualization and that one requires a D3Visualization and a SliderWidget, which in turn requires JQuery, a dependency injection framework will initialize all that junk for you. This also encourages separation of concerns.
- Routing: Being able to index a specific view in the app with a specific URL and having the URL change with the app state.
- Templates: You define the structure of HTML and provide slots, then you can plug in any data you want. Can be generated from a string with templating code in it or by writing html-like DOM stuff - handlebars is the former and Angular directives is the latter.
My impressions:
-
Angular:
- Create custom DOM elements: e.g.
<slider start=-5 end=5 />
- Two way binding
- “Views do the UI, Controllers work out the logic behind the UI, Services take care of communication with the backend and hold together pieces of common and related functionality, while Directives make it easy to create reusable components and extending HTML by defining new elements, attributes and behaviors.”
- Invents its own concepts sometimes: scopes, directives, transclusion
- Some concern with performance over many DOM elements
- Angular 2.0 is coming out, but isn’t there yet, but will be the future. And it will break API. How wise it to start an angular 1.x app today?
- Create custom DOM elements: e.g.
-
Ember:
- Two way binding
- Very low boilerplate - I like
- Performance focus
- Templating engine / handlebars
- Routing & data layer
- Server rendering is a bit easier - pure JS
- Ember API was changing a lot but is now stable
- Litters the dom with placeholder script tags - technically this is invisible but a bit gross. But they’re fixing this with a new component called HTMLBars. UPDATE: This isn’t an issue anymore, changes merged in.
- Docs and API seems a tad more friendly than angular in general
-
Backbone:
- Light & fast
- 3rd party templating, usually underscore
- No two way binding
- Views manipulate DOM directly - kinda icky in my POV, makes code harder to test and allows things to get tangled
- Unopinionated and barebones - sometimes a good thing but doesn’t provide structure, many competing plugins / frameworks to choose from
- Probably will have to use with marionette at least
-
React:
- Pretty much just a glorified view layer: Has no routing
- Uni-directional data flow: These guys say “no no no 2-way binding is evil” and eschew it in favour of explicit updates. But then
- Virtual dom: Your changes get reflected to a virtual DOM. Then you diff that with the actual dom, and only update what changed. This makes updates faster.
- Probably will need to be used with flux: an architecture template that facebook made that includes a dispatcher.
- React router: http://github.com/rackt/react-router
- Flux: https://scotch.io/tutorials/getting-to-know-flux-the-react-js-architecture
- JSX looks like templates mixed with code to me, a bit gross IMHO - react devs disagree, and their disagreement is cogent but didn't really convince me. You can use raw JS but it's not idiomatic.
-
http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html
-
React vs ember https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBHCZkLbR1TEsRnd3yyxuSQ5YY/edit#slide=id.p
-
More react vs ember, examples: http://instructure.github.io/blog/2013/12/17/facebook-react-vs-ember/
-
Angular vs ember https://docs.google.com/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview?slide=id.p
-
Why react is awesome (more about the ideas than react itself): https://news.ycombinator.com/item?id=7738194
@mohamadatieh Maybe it's a bit late to answer, but I advise you a lighter framework for apps containing a lot of elements client-side. In fact, the nested loops consume a lot of resources, and the two way data binding, if used in a bad way (too much calls or updates, useless watches, ...) can also hardly slow your front-end performances. I'm currently doing a fat-app with Angular 1.x and I start to wondering if it was a good choice. If I could re-start from scratch, I would maybe pick up Backbone or Ember. Even if I'm not well-informed about the differences, it's my current feeling of the thing.