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