[railsjedi]

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.

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

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

[MatthewPhillips]

But Rails was built for a different world, so trying to recreate what made Rails nice in the browser feels like an answer searching for a problem. Client-side JavaScript frameworks should be compared to UIKit and the Android SDK, not to Rails, which was only interested in routing, fetching, and rendering. Giving me code organization without giving me structure is only helping with a tiny sliver of the problem.

[railsjedi]

Sorry, I just meant compared to Rails in terms of impact. Ember is nothing like Rails architecturally. There's a good comparison here: http://emberjs.com/guides/ember_mvc/

So yeah. Ember's problem is convincing people there's a problem (hint: there definitely is).

[MatthewPhillips]

Those are implementations details, to the developer they serve a similar purpose. This is my problem with it, a web framework that gives equal weight to M, V, and C is missing the point; in the client the View is fucking everything. It is where any developer will spend the vast majority of their time; not in code organization. The frameworks and I mean this plurally, that win will be those that give structure to applications. Here's how the Android SDK provides structure to applications: http://developer.android.com/design/patterns/app-structure.h.... Web frameworks need the same thing. They should ship with HTML, JS, and CSS.

[wycats]

Just because a framework has models, views and controllers does not mean it gives them "equal weight".

[jguimont]

Then you do not understand what M and C does. It might be called a client but it is a stateful client. Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app).

[MatthewPhillips]

> Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app).

That's because we're not writing good reusable views. We're writing one-off views that corresponding to the current needs of the current application we're working on. Here's a good view: http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/...

It was created 5 years ago and I'm pretty sure it's got a lot of life left in it still.

[erikbryn]

Perhaps you'd be a fan of SproutCore?