4 ms·

Ember looks cool, but knockout lets me ship fast and it's less "magic". Also, I think single page apps have a place as part of a greater architecture, but not

Ember looks cool, but knockout lets me ship fast and it's less "magic". Also, I think single page apps have a place as part of a greater architecture, but not as the entire app. If I wanted an entire app everything to be JS, fine, use Ember or something like it, but most parts of the web don't need this and single page apps make the web a bit worse if not done correctly. Single page apps are the new hotness, but once the fad is over and the newness wears off, they'll be fit into their proper place over time and won't take over the entire app.

wycats 14y ago
> 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.
- skilesare 14y ago
  I think ember and knockout do the same thing here. In fact my impression was that knock out actually only rerenders the part of the template that was affected while ember does the whole view. This may have changed since 0.9.6.
aidos 14y ago
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.

wycats 14y ago

> 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.

skilesare 14y ago
I think ember and knockout do the same thing here. In fact my impression was that knock out actually only rerenders the part of the template that was affected while ember does the whole view. This may have changed since 0.9.6.

aidos 14y ago

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.