Hacker Newsnew | comments | show | ask | jobs | submit login
Ember.js - Rich Internet Applications Done Right (infoq.com)
76 points by joachimhs 1121 days ago | 28 comments



Hey guys, please take a look at the following app: 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.

-----


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

-----


I'm very happy and satisfied with my current development kits and methodology. I use no framework and don't write any classes.

http://en.wikipedia.org/wiki/Functional_programming

-----


Please write an article about your approach, I am really interested.

-----


"They just force beginners to not code crappy code and that's all."

That's a pretty huge deal in my book.

-----


I prefer teaching beginners the JavaScript way of doing things instead of forcing them to write spaghetti code.

-----


So it's "not crappy code" but "spaghetti code"? Could you elaborate on that a bit, I don't quite get the argument here.

-----


It sounds like you're a pretty good JavaScript developer. Great! Not everyone doing JavaScript is as good as you, and frameworks can help guide them toward better solutions.

Could you elaborate on the "horrible idea that increases the cost of development"?

-----


Better solutions are already provided by JavaScript itself. Event-driven programming was the idiomatic solution until CPS became the one everybody follows with the grow of NodeJS. See how NodeJS community deal with async programming.

-----


The idiomatic solution to what?

Ember.js and other frameworks exist to provide a basic structure for heavy client-side applications. Namely, a way to separate your "models" from your "views", if that's something you think is worth doing in your application.

JavaScript is a language, not a framework, and thusly provides none of this structure. "Event-driven programming" and "CPS" are just idioms that can be used within JavaScript.

If you don't like the way the Ember framework is structured, that's fine! But you probably have a personal style that you use in your applications that could be distilled into some kind of framework, and there's more to it than "CPS".

-----


@silvart19, I was talking about EmberJS' bindings. That's what makes Ember apps crappy. For the mention of MVC, you don't need to use a framework that forces you to live in North Korea.

-----


Do you have any open source projects that I can read through?

-----


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/

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-angul... 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/#/ )

-----


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.

-----


Another vote for AngularJS. Not your father's client-side Javascript library.

-----


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?

-----


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

-----


That was my first question too. This is the best summary I found:

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.

-----


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.

-----


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

-----


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.

-----


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

-----


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 :)

-----


Why are they images in the first place though? It's just code.

-----


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

-----


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.

-----


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

-----


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.

-----




Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: