Advice On & Instruction in The Use of Ember.js

> Ember looks cool, but knockout lets me ship fast and it's less "magic".

I'd appreciate it if you could quantify what you mean exactly by "magic". For example, one key difference between Ember and Knockout is that Ember's binding system automatically avoids triggering the same side-effect from multiple pieces of code.

For example, if you had a piece of the DOM that was calculated from several observables (the stupid example is a full name calculated from a salutation, first name and last name), and made changes to all three of those in separate lines of code (possibly in different areas of your codebase), Ember would ensure that the DOM only updated a single time, not three times. This is true no matter where the three lines of code are, without you needing to take any special action to coalesce the changes.

This aspect of Ember's codebase adds some magic, in that it introduces a higher-level abstraction that knows about computed properties and their side-effects (the "run loop"), but the end result is more predictable propagation of side-effects in an Ember application. Ember applications don't need to know about the specific mechanism that makes this work, but good Ember developers are aware that many side-effects happen asynchronously in an Ember application.

The browser does something similar when you make changes to DOM structures: it only updates the rendered version of the DOM once all of the JavaScript code handling an event has completed.

I would agree that something simpler would probably be a better fit for simple "islands of richness" on an existing application, but there are definitely a large number of applications with significant amounts of logic happening on the client side, even if those applications run inside of an area of a larger traditional page.

In general, I would say that Ember is a good fit for applications that will end up with more than 100k of application code. That sounds like a lot of code, but it's really only a lot of code for islands of richness. Applications like rdio, documentcloud, soundcloud and other popular Backbone applications can easily reach 500k or even a megabytes or two of code.

I've also shipped an Ember app and a Knockout App. To me, there's no comparison: Ember development was easier and produced a faster app and a better organized code base.

Once my app grew complex, Knockout grew increasingly hard to reason about how it's view updating was working. It also grew slow.

Also, Knockout lacks any legitimate data laye (knockout-mapping isn't a data layer). Ember has ember-data.

I've been looking for a decent tutorial on EMBER as someone who's of merely limited programming talents and abilities. I love what I've picked up so far, and I'm going to work through this tutorial now. Thanks OP for the work put in on this.

It's all about context and single page apps definitely have their place.

In my case for example (photo portfolio websites) it makes a lot of sense to have a single page app for the user backend and plain server rendered html (with a bit of js sugar) for the frontend.

Glad to see this article. The recent buzz around convention and best practices in Backbone.js has been frustrating. A lot of the recent Backbone discussion are issues that have been thoughtfully addressed in Ember.js.

I feel that Backbone.js was first on the scene and hence has found its way into the current developer lexicon and toolset, leaving Ember.js unfairly looked over.