Copied from one of my posts on the previous announcement with some tweaks:
Both Ember and Backbone fall into what I call the KVO frameworks category (Angular, Javascript MVC, Knockout, Batman, others). Both use jQuery for DOM manipulation and revolve around the idea of having a canonical model and having that as the center of your app. As you change the model, it fires events that you use to update the DOM. The difference is that Backbone is philosophy.
Backbone provides a basic but complete set of tools for observing model changes combined with a set of utilities that are useful but not prescriptive to make wiring up DOM events, URL handling, etc straightforward. It works with what's in jQuery/the browser. All together, it provides the organization most js apps are sorely lacking but doesn't dramatically reduce LoC over what you could do with well factored jQuery and underscore. It's nice enough that the YUI team basically adopted it wholesale for the App framework in 3.5.
Ember is all about binding. You can not only observe properties but bind them to other properties bidirectionally so that changing one causes the change to propagate through all bound values including things like values being arrays. This extends to the Handlebars templating (which was written for Ember) where you can bidirectionally bind, for example, a boolean on your model to a checkbox and to a class on a div so that checking the checkbox toggles the class without anything in your app directly manipulating the DOM. Setting this up is just the attribute plus two object path strings in the template. This works not just between the template and model but also between model objects, for arrays of models, and for nested models and nested views. Used properly, this takes care of a significant fraction of client side state managment and a resulting reduction in LoC.
The cost is that Amber is 7x the size of Backbone, the templating language is tied to the framework, and there's more overhead in understanding the concepts, how they fit together, and how to apply them to your code. When I talk to people who are writing jQuery spaghetti, I steer them towards Backbone for the simplicity and superior docs but mention that I use Ember for my own projects.
My impression is that the biggest difference is automated two-way bindings between views and models. Under Backbone, you have to do that binding manually. With Ember, this means that you don't have to always be explicitly triggering events to cause view re-rendering or invoking persistence callbacks from your views to trigger model saves.
The "computed properties" is also nice; it looks to enable the decorator pattern on models pretty trivially in the context of the two-way bindings, which generally does a lot for producing clean code.
My gut is that this is "Backbone biased towards a specific flavor of application design". Backbone is awesome, but by its own admission, is more of collective toolset than a full-blown framework. Ember looks like it's sort of a midpoint between Backbone's spartan foundation and Sproutcore's kitchen-sink framework. I'm excited to try it out.
Ember seems to be far stripped down from Sproutcore - specifically, it doesn't come with any kind of existing view resources or existing widgets, which is what enables those sorts of standard UIs. I suspect this is because Ember is targeted at web apps (where visual diversity is often an application requirement), while Sproutcore is going to be more focused on mobile apps (where a standard UI toolkit is not just nice, but expected).
As I posted elsewhere, it's been estimated that every pronounceable set of letters in the English language will be registered as a domain name by 2017*
Sooner or later we're going to have to work out an approach to globally distributed names that's less naive than "somebody else chose that first, choose a different name!"
If the Ember.js authors keep the library focused, I'm convinced this could be a very important project. Having tried the popular MVC frameworks out there, and having lots of experience with KnockoutJS, nothing out there is a clear winner yet for just binding Views. We need a library that focuses only on this problem, and excels at it, with no knowledge of URLs, AJAX, routing, storage, or default widgets/styles.
Unfortunately still lacking any progressive enhancement story to run their logic at the server and contribute to the world-wide web of linkable resources. Content imprisoned behind a 1990-vintage client/server architecture seriously sucked (there's only one client that works, it's terrible, and you can't even fix it) and I'm losing hope that we can escape a repeat of it.
What about the current state of the browser market (assuming that's what you mean by client) leads you to believe we're moving toward a single terrible client that we can't fix? We have several good browsers and engines on the market, half of them open source.
You know what's 1990-vintage? The set of HTML controls you have at your disposal, right now, even with HTML5, to send to the client to progressively enhance. At some point you have to draw the line. Require JavaScript and offer an API for the content. It'll be better specified than a bunch of markup anyway, which has a tendency to change at the whim of designers and marketing.
This library is supposed to be small and tightly focused. Providing progressive enhancement should be up to the developers using the library, not the library authors. Including it in the library would dictate too much about how things must work on the server, thus limiting the audience.
It's "released" but it doesn't have a license file yet. In reply to this issue on their github repo, they state it will use the MIT license, but I don't feel comfortable using a library until I know what the terms are.
Any non-trivial application will contain more than one code file. What is the Ember.js solution for this? Makefiles? And what about HTML? I'd like to organize those by sections of the app. How is that achieved?
Check out slinky[0], which in addition to solving the minification/concatenation issue for JS/CSS also does compilation of CS/HAML/SASS and provides a proxying development server. It's designed sort of in the mold of the sproutcore build tools, but unconnected to any particular client side framework.
I come to HN mostly for info about new tech used to develop software, which includes Ember.js. I wish there were more stories like this and fewer stories about social networks, consumer electronics, famous individuals, gender and race issues, pop-sci, pop-econ, etc.
[+] [-] dmvaldman|14 years ago|reply
[+] [-] grayrest|14 years ago|reply
Both Ember and Backbone fall into what I call the KVO frameworks category (Angular, Javascript MVC, Knockout, Batman, others). Both use jQuery for DOM manipulation and revolve around the idea of having a canonical model and having that as the center of your app. As you change the model, it fires events that you use to update the DOM. The difference is that Backbone is philosophy.
Backbone provides a basic but complete set of tools for observing model changes combined with a set of utilities that are useful but not prescriptive to make wiring up DOM events, URL handling, etc straightforward. It works with what's in jQuery/the browser. All together, it provides the organization most js apps are sorely lacking but doesn't dramatically reduce LoC over what you could do with well factored jQuery and underscore. It's nice enough that the YUI team basically adopted it wholesale for the App framework in 3.5.
Ember is all about binding. You can not only observe properties but bind them to other properties bidirectionally so that changing one causes the change to propagate through all bound values including things like values being arrays. This extends to the Handlebars templating (which was written for Ember) where you can bidirectionally bind, for example, a boolean on your model to a checkbox and to a class on a div so that checking the checkbox toggles the class without anything in your app directly manipulating the DOM. Setting this up is just the attribute plus two object path strings in the template. This works not just between the template and model but also between model objects, for arrays of models, and for nested models and nested views. Used properly, this takes care of a significant fraction of client side state managment and a resulting reduction in LoC.
The cost is that Amber is 7x the size of Backbone, the templating language is tied to the framework, and there's more overhead in understanding the concepts, how they fit together, and how to apply them to your code. When I talk to people who are writing jQuery spaghetti, I steer them towards Backbone for the simplicity and superior docs but mention that I use Ember for my own projects.
[+] [-] cheald|14 years ago|reply
The "computed properties" is also nice; it looks to enable the decorator pattern on models pretty trivially in the context of the two-way bindings, which generally does a lot for producing clean code.
My gut is that this is "Backbone biased towards a specific flavor of application design". Backbone is awesome, but by its own admission, is more of collective toolset than a full-blown framework. Ember looks like it's sort of a midpoint between Backbone's spartan foundation and Sproutcore's kitchen-sink framework. I'm excited to try it out.
[+] [-] burke|14 years ago|reply
[+] [-] Jacob4u2|14 years ago|reply
[+] [-] acak|14 years ago|reply
Ember.js does not show such examples at - http://www.emberjs.com/examples
Will such examples be showcased in the future or is it not a part of Ember.js?
[+] [-] cheald|14 years ago|reply
[+] [-] ericflo|14 years ago|reply
[+] [-] bigiain|14 years ago|reply
Sooner or later we're going to have to work out an approach to globally distributed names that's less naive than "somebody else chose that first, choose a different name!"
*Yes, I made that "fact" up myself.
[+] [-] rxcfc|14 years ago|reply
[+] [-] jpadilla_|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] exogen|14 years ago|reply
[+] [-] prodigal_erik|14 years ago|reply
[+] [-] exogen|14 years ago|reply
You know what's 1990-vintage? The set of HTML controls you have at your disposal, right now, even with HTML5, to send to the client to progressively enhance. At some point you have to draw the line. Require JavaScript and offer an API for the content. It'll be better specified than a bunch of markup anyway, which has a tendency to change at the whim of designers and marketing.
This library is supposed to be small and tightly focused. Providing progressive enhancement should be up to the developers using the library, not the library authors. Including it in the library would dictate too much about how things must work on the server, thus limiting the audience.
[+] [-] wwweston|14 years ago|reply
[+] [-] freejoe76|14 years ago|reply
[+] [-] calvin|14 years ago|reply
[+] [-] ebryn|14 years ago|reply
[+] [-] MatthewPhillips|14 years ago|reply
[+] [-] ebryn|14 years ago|reply
Most of the Ember apps I'm aware of are using it.
Also, you might want to check out rake-pipeline-web-filters for additional functionality: https://github.com/wycats/rake-pipeline-web-filters
[+] [-] necubi|14 years ago|reply
[0] https://github.com/mwylde/slinky
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] swah|14 years ago|reply
[+] [-] chezandre|14 years ago|reply
[+] [-] ale55andro|14 years ago|reply
[+] [-] cheriot|14 years ago|reply
Do you recommend any libraries for managing url state?
[+] [-] ebryn|14 years ago|reply
https://github.com/emberjs-addons/sproutcore-routing
[+] [-] lux|14 years ago|reply
[+] [-] rxcfc|14 years ago|reply
[+] [-] viandante|14 years ago|reply
[+] [-] socialist_coder|14 years ago|reply
[+] [-] subsection1h|14 years ago|reply
[+] [-] raganwald|14 years ago|reply
;-)
[+] [-] cookiestack|14 years ago|reply
[+] [-] tenderlove|14 years ago|reply
[+] [-] cheap|14 years ago|reply