Here's my petition for the site to join the contrast rebellion:<p><a href="http://contrastrebellion.com/" rel="nofollow">http://contrastrebellion.com/</a><p>The page is basically unreadable in FF 7.0.1 on RHEL 5.3. I realize light grey on white with a really thin font is dead sexy on your Mac (probably looks great on my home computer as well) but it's useless to me at work.
I've now shipped an Ember.js application and a knockout.js application. I enjoyed ember quite a bit but feel that knockout gives me all the magic with half the complexity.<p>It is true as the author mentions that it doesn't aim to fix the UI/statefullness issue, but I slapped on Backbone Routing on to my knockout code and it made capturing 'state' and urls a breeze.<p>The last time I used ember was 0.9.6 and I don't think this routing stuff was even in it so I was excited to see talk about it. Unfortunately it looks to be even more complicated then I expected it to. :(<p>Knockout may be creating some massive memory footprint in the background that will bite me down the line, but I'm writing significantly less code than I was with Ember. For example, In ember you have to create view objects and if you want your view objects to sync data with your controller you have to explicitly define them:<p>App.userController = Ember.Object.create({<p><pre><code> content: Ember.Object.create({
firstName: "Albert",
lastName: "Hofmann",
posts: 25,
hobbies: "Riding bicycles"
})
</code></pre>
});<p>App.UserView = Ember.View.extend({<p><pre><code> templateName: 'user',
firstNameBinding: 'App.userController.content.firstName',
lastNameBinding: 'App.userController.content.lastName'
</code></pre>
});<p>Now I get to do my handlebars template
<script><p><div>{{firstName}}</div><p></script><p>In knockout just have to do:
App.UserController = {<p>content = ko.observable(new content());<p>}<p>ko.applyBindings(App.UserController);<p>And now I get to do a knockout template inline with my html:<p><div data-bind="text: content.firstName"></div><p>It just seems like there are fewer steps with knockout and I'm getting more done. The html is a lot uglier, but it also clearer what is going on when I read it.<p>The ember guys have come a long way on their doc and they should be commended on it. I like the patterns they are talking about I'm just not sold that it has to be done the way they are doing it. Thanks to the author for putting together such an in depth post to me in the right direction in getting back into Ember.
As the guy who wrote the first bits of the Rdio code in question, it seems worth mentioning that the part in question has nothing to do with Backbone, or Ember, or anything else. That code is a cleanup function on an object that helps to abstract HTML5 <audio> vs our Flash fallback.<p>No matter what framework you are using, if you are solving the problems that we are solving, you are going to end up with that code.<p>Now, that said, I agree that learning all of the frameworks out there is advantageous, but you can't assume that the code in the blog post is indicative of anything having to do with Backbone or any other framework.
Let me tell you why I don't care about Ember.js at the moment:<p>It's an "all or nothing"-solution. I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site <i>any</i> time. Of course, some parts might require more dynamicness than other, and in that case it's <i>lovely</i> to jump to client side MVC. But it doesn't seem that Ember.js wants to play this game. Every time I look at Ember it seems that it wants to define the architecture of my application. Thank you very much, I like my stateless-ness very much!
Perfect article and explanation. After having bought into Ember a couple months ago and using it heavily, it's been really hard to express to others why it feels so revolutionary.<p>Ember really changes JS development in ways that the other frameworks don't even attempt. And in a way this hurts it in the perception of developers, since it more often than not is just tagged as "too complicated" or "too much to learn".<p>The more great articles like this, and I think there'll be a solid chance Ember catches on in a big way the same way Rails did. With 1.0rc, the tech seems to be solid enough now and it just needs a push on the other stuff (education, marketing, etc). And most importantly: some more successful Ember apps out in the wild (I'm working on that one).
Does anyone else thing that the documentation for ember.js is really lacking? Some of the classes it has aren't even documented (ContollerMixin comes to mind) and others are lacking in the documentation depratment. Also, I don't seem to be able to find a full listing of instance methods for a class, I have to climb up the inheritance tree in the docs class by class.
With regards to view cleanup code in Backbone - in the github develop branch [1], the view is now a little more active in its memory cleanup. A dispose() function was recently added which removes any handlers added in the view's 'events' object, as well as any collection or model listeners where the view is passed as the third argument (callback context). This function is also called by the view's .remove(), taking care of the majority of basic memory cleanup needs when the element is cleared from the screen.<p>[1]: <a href="https://github.com/documentcloud/backbone/commit/3ae1af6df1b542bfb3e38f2fdfe7a471f2b830a0" rel="nofollow">https://github.com/documentcloud/backbone/commit/3ae1af6df1b...</a>
Ember looks cool, but knockout lets me ship fast and it's less "magic".<p>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.<p>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.
Glad to see this article. The recent buzz around convention and best practices in Backbone.js has been frustrating. A lot of the recent Backbone discussion are issues that have been thoughtfully addressed in Ember.js.<p>I feel that Backbone.js was first on the scene and hence has found its way into the current developer lexicon and toolset, leaving Ember.js unfairly looked over.
As I said in another thread, despite hilarious disagreement by jashkenas, <a href="http://news.ycombinator.com/item?id=4427974" rel="nofollow">http://news.ycombinator.com/item?id=4427974</a> that Backbone is perfect for big projects so long as you build on top of it with other libraries.<p>Ember.js is just too opinionated for its own good.
This is such a timely article, thanks! I was just listening to the video on this week's JavaScript Weekly and considering where to start among the js application frameworks. It would be nice if the author expanded on the different categories of js app frameworks.<p>Video: Beyond the DOM: Sane Structure for JS Apps:
<a href="http://www.youtube.com/watch?v=cd7HHN6IkrU" rel="nofollow">http://www.youtube.com/watch?v=cd7HHN6IkrU</a>
For anyone trying to follow along with the tutorial beware that there's a typo the whole way through the code that stops it from running.<p>connnect -> connect
Do any of these JavaScript frameworks have decent documentation yet? API docs are all well and good, but I'd really like some examples other than to-do applications. All they really need is an equivalent to the Rails guides at <a href="http://guides.rubyonrails.org" rel="nofollow">http://guides.rubyonrails.org</a>, which are ample.<p>Frankly I'd take any example application over a to-do app at this point.<p>As an aside, I've been using Sammy.js (<a href="http://sammyjs.org" rel="nofollow">http://sammyjs.org</a>) more than most of these other frameworks lately, as the effort involved is disproportionate to the rewards unless you're building the entire frontend in JavaScript. For any less-than-enormous project, you really don't need all that complexity.
Emberjs in production:<p><a href="https://github.com/emberjs/ember.js/wiki/Production-Deployments-Page" rel="nofollow">https://github.com/emberjs/ember.js/wiki/Production-Deployme...</a>
<a href="http://emberjs.com/" rel="nofollow">http://emberjs.com/</a><p>The font here really sucks, for me anyway. I cannot see the "cross" of the t. It just looks like an l. Anyone else see this?
Can anyone tell me whether a website built with Ember.js's default settings suffers from the same readability problems with font and contrast? If so, that tells me that I probably won't want to invest any time in learning to use Ember.js.