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.
Especially considerring Knockout Model plugin that basically adds Backbone-style capabilities to KO models. Other notable plugins give easy bindings for jQuery UI widgets, Underscore support for collections and external templates:
My favorite are control flow bindings that let you write templating code right inside your HTML and not withing script tags. When you have to write markup inside a script tag you editor might get the whole autocompletion, formatting and syntax coloring wrong. And in past it was relly annoying for me. So having templates in HTML, not in script is really great.
One thing that helps a lot is that all bindings are defined inside data-attributes which keeps markup valid. Most editors support them well, too. Ember's double-braced template attributes are really weak choice in this regard.
And if you're worried about javascript bits inside data-bind attributes you now have an option to separate them via binding providers (see blog post above). The syntax is somewhat clunky but still workable and I suppose it can be improved.
Provided that Knockout has a vibrant community and growing support inside .NET world I think Ember has nothing to offer to make me switch.
And that's unfortunate. Today I see like most frameworks converges to some common ground. Knockout gets more features from Backbone. Backbone gets more features from Knockout (there's at least one bindings plugin for BB although it pales in comparison to Ko). And as far as I can see we as a JavaScript community reached the next base.
- We started with simple Ajax libraries.
- Then we moved to widgets.
- Now we got MVP frameworks and think more about organizing our applications in general.
What's the next step? That's the most important question for me and for other JS professionals that I talked to at recent local conference. When I saw Yahuda's announcement I really hoped that he'd give us a clue. Instead we got another MVP variant and not a top one although a pretty solid.
I suspect that Ember still will get some users. Yahuda has dedicated fans (me included) and Knockout as something coming from .NET world has a somewhat hard time getting adoption among the general JS crowd. Maybe that's a good thing: two frameworks are very similar and can learn from one another. But I personally hoped for more.
Still, congrats on releasing the thing! Keep it up!
> What's the next step? That's the most important question for me and for other JS professionals that I talked to at recent local conference.
Components with bindings IS the next step. Douglas Adams quote:
"The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why and Where phases. For instance, the first phase is characterized by the question, 'How can we eat?' The second by the question, 'Why do we eat?' And the third by the question, 'Where shall we do lunch?'"
Whenever the topic of web app development has come up in the past 5 years or so, I always think of this quote. In the case of front end development, the questions are "Can we do this?" (CGI, asp/jsp/php), "Can we make this feel better?" (ajax, rails & co), and "How shall we structure our app?" (components, binding, widgets). This last phase only kicked of in earnest about a year ago and I'm still evangelizing the approach to even relatively up to date developers. They've heard of Backbone, for example, but haven't investigated and don't know how it applies to day to day work.
Going forward, expect to see interoperability concerns addressed. I've seen proposals for this in the form of html5 component model [1][2] and style tag's scoped attribute [3]. This provides a common ground for people to mix different libraries/components on the same page with a reasonable confidence that things won't break.
I also expect one of the KVO frameworks and it's associated widget system to "win" like jQuery has won DOM manipulation. What makes widget frameworks in the browser fun is that people have an expectation of being able to completely restyle everything and the only way I know of to do that cleanly without forcing a lot of fragile markup is with sass/less/stylus, so I expect to see those increase in popularity.
As a whole, web apps have been less sophisticated than equivalent complexity desktop and mobile apps. I've long believed that much of this is due to us re-writing a half-assed widget system from scratch for every project. This consumes a significant fraction of the time/money/effort allocated to a project which apps on other platforms can put into additional capabilities or polish. As such, I think the wide adoption of a KVO framework and widget library will be an inflection point for the quality and sophistication of apps in the browser. I'm looking forward to it.
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).
That's true. Ember isn't trying to provide a set of UI widgets out of the box. I'm confident that Ember-compatible UI libraries will be released in the near future.
SproutCore 1.x isn't very mobile-friendly at the moment. The original reason the SproutCore 2.0 rewrite began was to make the framework lightweight so that it'd be more suitable for use on mobile platforms.
I've started a project, Ember-Titanium, that enables native mobile app development using Ember's runtime on the Titanium Mobile platform. The project is still in it's infancy, but I've already been successful at building apps with it.
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.
By "client" I mean the unhackable blob of minified js which is the one and only piece of code in existence that knows how to get any useful content out of today's revision of one server's undocumented protocol. APIs are the problem, they are displacing portions of the web which were far more reusable. They require custom clients (usually in js) per site, and the authors who aren't responsible enough to do progressive enhancement are the same ones who aren't capable of (or even interested in) maintaining a documented, stable, backward-compatible API for years. Markup changed but was at least mostly self-describing before it became acceptable to serve obfuscated data and repair it using code that end users shouldn't need and oughtn't blindly trust.
> 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.
All modern JavaScript frameworks still generate HTML that's shown in the browser, so it's not like we no longer have to worry about that. The only thing that has changed is that we now generate the HTML in the client, not on the server; this has both its advantages (only needs to download data after the first load, only needs to update what has actually changed etc.) and disadvantages (you need to implement your own "progress indicator", slow page load on mobile where the cache is smaller, the webpage no longer gradually loads when you're on a slow connection, you need to worry about state).
If you have a simple request/response page on your website, nothing beats what we have today. And all websites have some plain request/response pages. These JavaScript frameworks seems to be an all-or-nothing and it seems to be hard to share components between the browser and the server. Why should I need copy-paste templates/layouts around?
> 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.
Looking at the example application (Todos), I'll have to say I wonder how to make this work on the server:
{{view Todos.CreateTodoView id="new-todo" placeholder="What needs to be done?"}}
<!-- Insert this after the CreateTodoView and before the collection. -->
{{#view Todos.StatsView id="stats"}}
{{#view SC.Button classBinding="isActive"
target="Todos.todosController"
action="clearCompletedTodos"}}
Clear Completed Todos
{{/view}}
{{remainingString}} remaining
{{/view}}
{{view SC.Checkbox class="mark-all-done"
title="Mark All as Done"
valueBinding="Todos.todosController.allAreDone"}}
{{#collection contentBinding="Todos.todosController" tagName="ul" itemClassBinding="content.isDone"}}
{{view SC.Checkbox titleBinding="content.title"
valueBinding="content.isDone"}}
{{/collection}}
</script>
I can't see one easy way to render this on the server side. The only solution I can see is to write a custom template engine which specifically targets Ember.
The view could be rendered by running Ember with Node or another server-side JavaScript runtime. That actually isn't even the hard part.
You're right about JavaScript generating the same controls in HTML that could be rendered on the server. I wasn't very clear about that, but the hard part is the progressive enhancement of the interaction with the controls, not their rendering. When people talk about progressive enhancement, they don't just mean the visual/DOM rendering. I really think that a number of people still expect these controls to work (even if just primitively) without JavaScript, by just using typical form submissions and no AJAX. This is where I meant that you have to draw the line. At some point the typical submit form, follow link, request/response cycle is so far from the user experience you're going for that you just have to admit that your application requires JavaScript.
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?
That looks pretty awesome, thanks. However I feel like this is something the framework should handle for the basic use cases. Learning rake-pipeline is probably worth the effort but should never be required. Developers should spend their time thinking about their app, not deployment details.
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.
Ok. But it still explains why it took so long to load for swah. Because when you run index.html from your hard drive locally it wil use the file:// protocol instead of http://
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.
Odd, that’s exactly how we do things up here in Canada: You vote for the candidate you like. There is no way to vote against anybody.
Just like the HN front page, there is only room for the candidate who gets the most votes to win a seat in Parliament, so our democracy functions without downvotes.
And politicians aren't news articles. So how is it that you get to draw a parallel between Politicsand a web site when it suits the point you wish to make, but when someone retorts in kind, you claim they are more different than similar?
If what you are trying to say is that it's not democracy regrdless of how the arrows work, I agree. It's not democracy because it isn't a system of social governance.
