5 ms·

Ember.js - Rich Internet Applications Done Right

76 points by joachimhs 15y ago

antinitro 15y ago
The quality of the code images honestly put me off reading the article.
- joachimhs 15y ago
  You can click to enlarge them, or you can click the link in the figure text to be taken to the correct GitHub revision of the file :)
  - davej 15y ago
    Why are they images in the first place though? It's just code.
    - joubert 15y ago
      Sidenote: I love how Posterous has nice github code integration. I wonder what other blogging systems have something close/similar (for when I have to move off P).
    - deleted 15y ago
      [deleted]
msluyter 15y ago
I went to the ember.js home page, which looks a lot nicer than parent article. Looks pretty cool. Anyone have any input how this compares to backbone or knockout?
- JackC 15y ago
  That was my first question too. This is the best summary I found: http://smus.com/backbone-and-ember http://smus.com/backbone-and-ember It links to a much longer IRC argument between their respective evangelists -- the whole thing is an interesting read if you like that sort of thing. But the takeaway is that Ember is pretty opinionated about how to connect views to subviews to templates to models to controllers to data stores, and backbone pretty much lets you/makes you do it yourself. So backbone might mean you're writing a lot of boilerplate, and ember might mean you're locked into decisions you don't like and slowed down by cruft you don't need -- same old tradeoff. I'm excited to give ember a try, because my initial response to backbone was "wait, where's the rest?" I was expecting the level of handholding of, like, Django. So it'll be interesting to see what that's actually like in practice.
  - haberman 15y ago
    I've been extremely impressed with Knockout; just the right amount of "opinion" to make things easy without being too imposing. Its data binding interface is exactly what I was looking for to connect my models to views.
- davej 15y ago
  Ember is more of a fully featured framework than Backbone: it has bindings, computed properties and does some nice auto-updating stuff with handlebars templates — Backbone is more lightweight. Backbone is more popular and has been around for longer so it is arguably more battle-tested and there are more community resources. Here's a podcast which contains lots of dialogue between the two framework creators (Katz and Ashkenas): http://javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas/ http://javascriptjabber.com/004-jsj-backbone-js-with-jeremy-...
- ww520 15y ago
  I actually like Knockout.js much more than Ember or Backbone. Its two-way binding is simple to use. Ember and Backbone feel heavy weight conceptual wise and code wise. Knockout doesn't have routing but there are so many little routing packages out there. I just use Crossroad.js for routing.
- Lazare 15y ago
  This is going to sound unfair, and maybe it is, but here goes: The biggest difference between Ember and Knockout is that Knockout has excellent documentation and tutorials, and is very easy to pick up. The tooling and knowledge needed to get a basic proof of concept app up and running from scratch is trivial with Knockout. It fits into whatever toolchain or build process you already have; as a result it's easy to add Knockout to an existing Django or Node project. By contrast, Ember has poor documentation and tutorials. This was especially bad at launch, but even today it's very limited, and significant chunks still refer to Sproutcore. Some of that documentation is apparently still relevant, refers to the Sproutcore v2 project, and just haven't been updated with the new name. Other bits are apparently referring to the Sproutcore v1 project, and aren't relevant. Good luck figuring out which ones are which. Ember also has very idiosyncratic ideas about how projects should be built; again this isn't really documented. It's hard to build an Ember app from scratch, and it probably will not work with your current build process. It feels, in some difficult to define fashion, more like what I'd expect from the Java ecosystem. I'm not a fan. As I said, I'm sure that sound unfair, and it may well be. Ember fans will no doubt be able to explain that it's much easier than that, that my problems were all my own fault, that the documentation is already much improved, and that any quirks that do exist do so for very good historical reasons. And they're probably right! But I came at Ember cold a month or two ago, tried very hard to figure it out, and bounced. As a result, I have no idea how Ember really compares to Knockout, because I figured out how to write my app in Knockout, but I couldn't figure out how to write it in Ember despite a very concerted effort. Take that for what it's worth. :) (My impression, incidentally, is that Knockout is sort of what the Ember project wants to be, but they're still struggling to strip out the cruft they inherited from Sproutcore. Both projects have a focus on magical "it just works" dynamic bindings, which means you have incredible awesome power but have to be a little careful not to blow your leg off via some behind-the-scenes magic you didn't even realize existed. Backbone, on the other hand, is a very barebones framework; it's almost more like a toolkit you can use to build your own MVC framework. That's valuable too, depending on your needs.)
taude 15y ago
By having all these images for the code sample makes it almost useless for me to tag and read later in one of my instapaper-esque tools.
moondev 15y ago
Anybody else confuse this with ender.js at first? Time for another rename!
- a15i 15y ago
  speaking of renaming, how about making a post on HN and asking everyone what the new name should be? this has nothing to do with publicizing, just a democratic way (the right way) of naming a framework.
pentarim 15y ago
This is almost the best article I have read about Ember.js which is not a compliment in this case because there are so few of them. I dont even mind images for code parts, because of rarity of this content type. I like Ember a lot but it still has a long road ahead, until community matures around it and helps out with more blog posts, examples, tutorials. Best of luck because its cool stuff.
a15i 15y ago
'done right'? like the way they call 'the rails way' the right way?
creamyhorror 15y ago
If we're discussing JS client MV* frameworks, take a look at the demos of the various options (including Ember.js, Backbone.js, Ext.JS, AngularJS) on: http://addyosmani.github.com/todomvc/ http://addyosmani.github.com/todomvc/ I've been getting into AngularJS myself, which is positioned as an alternative to Backbone, KnockoutJS, etc.: http://stackoverflow.com/questions/9588921/ember-js-vs-angularjs http://stackoverflow.com/questions/9588921/ember-js-vs-angul... http://zdam.posterous.com/angularjs-vs-knockoutjs-knockout-gets-kod http://zdam.posterous.com/angularjs-vs-knockoutjs-knockout-g... (AngularJS is undergoing a flurry of development so don't use the v0.9.19 branch on the site - instead, wait for v1.0 to be released, since v1.0.0rc2 is already out. http://angularjs.org/#/ http://angularjs.org/#/ )
- deleted 15y ago
  [deleted]
- va_coder 15y ago
  That's a great project. I've been learning coffeescript, backbone, etc and it's dawned on my how little I know about JavaScript, even though I've been using it for years.
- oluckyman 15y ago
  Another vote for AngularJS. Not your father's client-side Javascript library.
combataircraft 15y ago
Hey guys, please take a look at the following app: http://editgrid.com/untitled http://editgrid.com/untitled It's the coolest web-based spreadsheets application built 6 years ago using no library, no framework. I'm a fan of it. It was looking just like this current version 6 years ago and was pretty fast at even IE6. And its 6 years old JavaScript code follows the rules of coding good JavaScript code way more than Ember itself. Here is another story: I was working for a competitor of EditGrid and built a Microsoft Excel clone with dozens of features in 6 months, using no framework, no library, 5 years ago. We were two guys at frontend and two other guys in at backend. And our source code was almost pure object orient, mixable, reusable and relying on MVC, event-driven programming. I've been shipping rich web apps for more than 6 years and recently had the chance of working with both Backbone and Ember. Here is my feedback: The size of Ember library is bigger than total source code (including an AI library) of the last multiplayer game I built. And both of them solve no problem, simplify nothing. They just force beginners to not code crappy code and that's all. Good JavaScript code should benefit of functional programming very well, like some NodeJS apps and libraries. They got no understanding of FP. Especially Ember relies on a horrible idea that increases the cost of development very huge. Very ironically, ember code is not reusable, not mixable with other web apps. It's not even unobtrusive, pollutes Object prototypes. When you finish your app, you got a huge garbage that has not even one piece of reusable code. To summarize, there is nothing Ember does right. It tries to solve already solved problems in a very absurd way and is very irrelevant with the new problems JavaScript community tries to solve (such as code-reuse with NodeJS apps, it's partly solved) It's the new, communist North Korea of JavaScript world.
- edwardhotchkiss 15y ago
  I think that you should check out Angular.js. I have a blog post on it. Basically to write the app "no library no framework" (or even using jquery) - would be a lot more work. I think that you're trolling but I'll bite and link you anyway. http://edwardhotchkiss.com/blog/2012/03/11/jekyll-live-search-with-angular.js/ http://edwardhotchkiss.com/blog/2012/03/11/jekyll-live-searc...
  - combataircraft 15y ago

76 points by joachimhs 15y ago

antinitro 15y ago

The quality of the code images honestly put me off reading the article.

joachimhs 15y ago
You can click to enlarge them, or you can click the link in the figure text to be taken to the correct GitHub revision of the file :)
- davej 15y ago
  Why are they images in the first place though? It's just code.
  - joubert 15y ago
    Sidenote: I love how Posterous has nice github code integration. I wonder what other blogging systems have something close/similar (for when I have to move off P).
  - deleted 15y ago
    [deleted]

msluyter 15y ago

I went to the ember.js home page, which looks a lot nicer than parent article. Looks pretty cool. Anyone have any input how this compares to backbone or knockout?

JackC 15y ago
That was my first question too. This is the best summary I found: http://smus.com/backbone-and-ember http://smus.com/backbone-and-ember It links to a much longer IRC argument between their respective evangelists -- the whole thing is an interesting read if you like that sort of thing. But the takeaway is that Ember is pretty opinionated about how to connect views to subviews to templates to models to controllers to data stores, and backbone pretty much lets you/makes you do it yourself. So backbone might mean you're writing a lot of boilerplate, and ember might mean you're locked into decisions you don't like and slowed down by cruft you don't need -- same old tradeoff. I'm excited to give ember a try, because my initial response to backbone was "wait, where's the rest?" I was expecting the level of handholding of, like, Django. So it'll be interesting to see what that's actually like in practice.
- haberman 15y ago
  I've been extremely impressed with Knockout; just the right amount of "opinion" to make things easy without being too imposing. Its data binding interface is exactly what I was looking for to connect my models to views.
davej 15y ago
Ember is more of a fully featured framework than Backbone: it has bindings, computed properties and does some nice auto-updating stuff with handlebars templates — Backbone is more lightweight. Backbone is more popular and has been around for longer so it is arguably more battle-tested and there are more community resources. Here's a podcast which contains lots of dialogue between the two framework creators (Katz and Ashkenas): http://javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas/ http://javascriptjabber.com/004-jsj-backbone-js-with-jeremy-...
ww520 15y ago
I actually like Knockout.js much more than Ember or Backbone. Its two-way binding is simple to use. Ember and Backbone feel heavy weight conceptual wise and code wise. Knockout doesn't have routing but there are so many little routing packages out there. I just use Crossroad.js for routing.
Lazare 15y ago
This is going to sound unfair, and maybe it is, but here goes: The biggest difference between Ember and Knockout is that Knockout has excellent documentation and tutorials, and is very easy to pick up. The tooling and knowledge needed to get a basic proof of concept app up and running from scratch is trivial with Knockout. It fits into whatever toolchain or build process you already have; as a result it's easy to add Knockout to an existing Django or Node project. By contrast, Ember has poor documentation and tutorials. This was especially bad at launch, but even today it's very limited, and significant chunks still refer to Sproutcore. Some of that documentation is apparently still relevant, refers to the Sproutcore v2 project, and just haven't been updated with the new name. Other bits are apparently referring to the Sproutcore v1 project, and aren't relevant. Good luck figuring out which ones are which. Ember also has very idiosyncratic ideas about how projects should be built; again this isn't really documented. It's hard to build an Ember app from scratch, and it probably will not work with your current build process. It feels, in some difficult to define fashion, more like what I'd expect from the Java ecosystem. I'm not a fan. As I said, I'm sure that sound unfair, and it may well be. Ember fans will no doubt be able to explain that it's much easier than that, that my problems were all my own fault, that the documentation is already much improved, and that any quirks that do exist do so for very good historical reasons. And they're probably right! But I came at Ember cold a month or two ago, tried very hard to figure it out, and bounced. As a result, I have no idea how Ember really compares to Knockout, because I figured out how to write my app in Knockout, but I couldn't figure out how to write it in Ember despite a very concerted effort. Take that for what it's worth. :) (My impression, incidentally, is that Knockout is sort of what the Ember project wants to be, but they're still struggling to strip out the cruft they inherited from Sproutcore. Both projects have a focus on magical "it just works" dynamic bindings, which means you have incredible awesome power but have to be a little careful not to blow your leg off via some behind-the-scenes magic you didn't even realize existed. Backbone, on the other hand, is a very barebones framework; it's almost more like a toolkit you can use to build your own MVC framework. That's valuable too, depending on your needs.)

taude 15y ago

By having all these images for the code sample makes it almost useless for me to tag and read later in one of my instapaper-esque tools.

moondev 15y ago

Anybody else confuse this with ender.js at first? Time for another rename!

a15i 15y ago
speaking of renaming, how about making a post on HN and asking everyone what the new name should be? this has nothing to do with publicizing, just a democratic way (the right way) of naming a framework.

pentarim 15y ago

This is almost the best article I have read about Ember.js which is not a compliment in this case because there are so few of them. I dont even mind images for code parts, because of rarity of this content type. I like Ember a lot but it still has a long road ahead, until community matures around it and helps out with more blog posts, examples, tutorials. Best of luck because its cool stuff.

a15i 15y ago

'done right'? like the way they call 'the rails way' the right way?

creamyhorror 15y ago

If we're discussing JS client MV* frameworks, take a look at the demos of the various options (including Ember.js, Backbone.js, Ext.JS, AngularJS) on: http://addyosmani.github.com/todomvc/ http://addyosmani.github.com/todomvc/ I've been getting into AngularJS myself, which is positioned as an alternative to Backbone, KnockoutJS, etc.: http://stackoverflow.com/questions/9588921/ember-js-vs-angularjs http://stackoverflow.com/questions/9588921/ember-js-vs-angul... http://zdam.posterous.com/angularjs-vs-knockoutjs-knockout-gets-kod http://zdam.posterous.com/angularjs-vs-knockoutjs-knockout-g... (AngularJS is undergoing a flurry of development so don't use the v0.9.19 branch on the site - instead, wait for v1.0 to be released, since v1.0.0rc2 is already out. http://angularjs.org/#/ http://angularjs.org/#/ )

deleted 15y ago
[deleted]
va_coder 15y ago
That's a great project. I've been learning coffeescript, backbone, etc and it's dawned on my how little I know about JavaScript, even though I've been using it for years.
oluckyman 15y ago
Another vote for AngularJS. Not your father's client-side Javascript library.

combataircraft 15y ago

Hey guys, please take a look at the following app: http://editgrid.com/untitled http://editgrid.com/untitled It's the coolest web-based spreadsheets application built 6 years ago using no library, no framework. I'm a fan of it. It was looking just like this current version 6 years ago and was pretty fast at even IE6. And its 6 years old JavaScript code follows the rules of coding good JavaScript code way more than Ember itself. Here is another story: I was working for a competitor of EditGrid and built a Microsoft Excel clone with dozens of features in 6 months, using no framework, no library, 5 years ago. We were two guys at frontend and two other guys in at backend. And our source code was almost pure object orient, mixable, reusable and relying on MVC, event-driven programming. I've been shipping rich web apps for more than 6 years and recently had the chance of working with both Backbone and Ember. Here is my feedback: The size of Ember library is bigger than total source code (including an AI library) of the last multiplayer game I built. And both of them solve no problem, simplify nothing. They just force beginners to not code crappy code and that's all. Good JavaScript code should benefit of functional programming very well, like some NodeJS apps and libraries. They got no understanding of FP. Especially Ember relies on a horrible idea that increases the cost of development very huge. Very ironically, ember code is not reusable, not mixable with other web apps. It's not even unobtrusive, pollutes Object prototypes. When you finish your app, you got a huge garbage that has not even one piece of reusable code. To summarize, there is nothing Ember does right. It tries to solve already solved problems in a very absurd way and is very irrelevant with the new problems JavaScript community tries to solve (such as code-reuse with NodeJS apps, it's partly solved) It's the new, communist North Korea of JavaScript world.

edwardhotchkiss 15y ago
I think that you should check out Angular.js. I have a blog post on it. Basically to write the app "no library no framework" (or even using jquery) - would be a lot more work. I think that you're trolling but I'll bite and link you anyway. http://edwardhotchkiss.com/blog/2012/03/11/jekyll-live-search-with-angular.js/ http://edwardhotchkiss.com/blog/2012/03/11/jekyll-live-searc...
- combataircraft 15y ago