Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Contrary to popular opinion Ember.js isn't a 'more heavy weight approach' to Backbone.js. They're different kinds of tools that target totally different end products. Ember's sweet spot is applications where the user will keep the application open for long periods of time, perhaps all day, and interactions with the application's views or underlying data trigger deep changes in the view hierarchy. Ember is larger than Backbone, but thanks to <code>Expires</code>, <code>Cache-Control</code> this only matters on the the first load. After two days of daily use that extra 30k will be overshadowed by data transfers, sooner if your content involves images.</p> <p>Backbone is ideal for applications with a small number of states where the view hierarchy remains relatively flat and where the user tends to access the app infrequently or for shorter periods of time. Backbone's code gets to remain short and sweet because it makes the assumption that the data backing the DOM will get thrown away and both items will be memory collected: <a href="https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400">https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400</a> Backbone's smaller size also makes it better suited to brief interactions.</p> <p>The apps people write in both frameworks reflect these uses: Ember.js apps include <a href="https://squareup.com/">Square's web dashboard</a>, <a href="http://www.zendesk.com/">Zendesk</a> (at least the agent/ticketing interface), and <a href="http://www.groupon.com/scheduler">Groupon's scheduler</a>: all applications a user might spend all day working in. </p> <p>Backbone apps focus more on brief or casual interactions, that are often just small sections of a larger static page: <a href="https://www.airbnb.com/">airbnb</a>, <a href="http://www.khanacademy.org/">Khan Academy</a>, <a href="https://foursquare.com/">Foursquare's map and lists</a>.</p> <p>You <em>can</em> use Backbone to make the kinds of applications that Ember targets (e.g. <a href="http://rdio.com">Rdio</a>) by a) increasing the amount of application code you're responsible for to avoid problems like memory leaks or zombie events (I don't personally recommend this approach) or b) by adding 3rd party libraries like <a href="http://marionettejs.com/">backbone.marionette</a> or <a href="https://github.com/onsi/coccyx">Coccyx</a> – there are many of these libraries that all try to provide similar overlapping functionality and you'll probably end up assembling your own custom framework that is bigger and requires more glue code than if you'd just used Ember.</p> <p>Ultimately the question of "which to use" has two answers.</p> <p>First, "Which should I use, generally, in my career": Both, just like you'll end up learning any tools specific to work you'll want to do in the future. You'd never ask "Backbone or D3?"; "Backbone or Ember" is an equally silly question.</p> <p>Second, "Which should I use, specifically, on my next project": Depends on the project. Both will communicate with a Rails server with equal ease. If your next project involves a mix of pages generated by the server with so-called "islands of richness" provided by JavaScript use Backbone. If your next project pushes all the interaction into the browser environment, use Ember.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload