4 ms·

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

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 14y ago
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.

railsjedi 14y ago

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.