6 ms·

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

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/ http://emberjs.com/guides/ember_mvc/ So yeah. Ember's problem is convincing people there's a problem (hint: there definitely is).

MatthewPhillips 14y ago
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.html http://developer.android.com/design/patterns/app-structure.h.... Web frameworks need the same thing. They should ship with HTML, JS, and CSS.
- erikbryn 14y ago
  Perhaps you'd be a fan of SproutCore?
- wycats 14y ago
  Just because a framework has models, views and controllers does not mean it gives them "equal weight".
- wycats 14y ago
  Just because a framework has models, views and controllers does not mean it gives them "equal weight".
- jguimont 14y ago
  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 14y ago
    > 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/Reference/UITabBar_Class/Reference/Reference.html#//apple_ref/doc/c_ref/UITabBar 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.

MatthewPhillips 14y ago

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.html http://developer.android.com/design/patterns/app-structure.h.... Web frameworks need the same thing. They should ship with HTML, JS, and CSS.

erikbryn 14y ago
Perhaps you'd be a fan of SproutCore?
wycats 14y ago
Just because a framework has models, views and controllers does not mean it gives them "equal weight".
wycats 14y ago
Just because a framework has models, views and controllers does not mean it gives them "equal weight".
jguimont 14y ago
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 14y ago
  > 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/Reference/UITabBar_Class/Reference/Reference.html#//apple_ref/doc/c_ref/UITabBar 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.