Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EmberJS Confuses Me

wekeroad.com

Post reply on HN
Print view View original

31–40 of 142 posts

Re: EmberJS Confuses Me

#31

Post by robconery »

avolcano wrote: post #28

While I actually totally agree with the confusion in the router, I want to explain what I see in Ember's MVC: As far as I attempted to implement it in my app ( https://github.com/thomasboyt/noted-app ), it seemed simple enough. Models were data; all they contained was their properties and operations that controlled their properties. I mainly used controllers as the "state" for parts of my app. In Ember, this doesn't…

Seems reasonable, but the Ember team sees it differently... they put state in the router:

>Most of your controllers will be very small. Unlike other frameworks, where the state of your application is spread amongst many controllers, in Ember.js, we encapsulate that state in the router. This allows your controllers to be lightweight and focused on one thing.

Re: EmberJS Confuses Me

#33

Post by acoleman616 »

robconery wrote: post #25
clintjhill wrote: post #18

Earlier quoted context omitted.

The controller is responsible for rendering the view when the data changes. It does graft the model data - and any other data you want renderable into the view. I wouldn't characterize it as "the data" however.

{{#each controller}} {{name}} {{/each}} How is the controller not the data as far as the View is concerned?

As mentioned above, the proxied model data is actually stored in a controller's "content" field. So that snippet is actually just shorthand for {{#each controller.content}} {{/each}}

Re: EmberJS Confuses Me

#34

Post by robconery »

ef4 wrote: post #26
robconery wrote: post #19

Earlier quoted context omitted.

The team has been rather clear that Ember is Desktop MVC, not web/server based: https://twitter.com/trek/status/309315009291378690 They say as much in their guides as well.

> The team has been rather clear that Ember is Desktop MVC, not web/server based That's orthogonal to what I'm talking about. I agree that their use of the term "MVC" is much closer to the original meaning it had on the desktop (like in Cocoa) than the meaning in server-side frameworks like Rails. But I'm not talking about what MVC means. I'm talking about what kind of applications Ember is intended to be used to bui…

Your assertion is that "Ember is not about desktop apps". Yes, it is entirely about Desktop apps in terms of structure and approach.

These apps are built on the web. One look at the Discourse Ember code and I think you'll understand perfectly the confusion I'm writing about.

But I'm curious: do you use Ember or are your responses "what you think"

Re: EmberJS Confuses Me

#35

Post by daigoba66 »

xaritas wrote: post #29
pilgrim689 wrote: post #4

> The downside to this approach is that your HTML is "compromised", if you will, and many developers don't like that. My thought is that it's already compromised using Handlebars so what's the difference here? Personally I have no issue using the ng-* directives. Some people do, and I respect that. I'm a bit off-topic, but you don't need to "compromise" your HTML with AngularJS, you can place "data-" in front of your…

When I hear this argument I believe the concern is not the syntax of the binding with respect to the HTML spec, but rather the declaration of bindings in HTML at all. So the issue is not "ng-click" vs. "data-ng-click", but that "ng-click" in any form is no different than the pre-JS MVC horrors of onclick="mutateGlobalStateAndPerformIO()"; which is precisely the barbaric approach we thought we were vanquishing. I thin…

> onclick="mutateGlobalStateAndPerformIO()"

What's wrong with that? Other than scoping problems (which Angular solves), this is far more in line with classic view-controller than anything else.

Re: EmberJS Confuses Me

#36

Post by robconery »

jfarmer wrote: post #27
clintjhill wrote: post #18

Earlier quoted context omitted.

The controller is responsible for rendering the view when the data changes. It does graft the model data - and any other data you want renderable into the view. I wouldn't characterize it as "the data" however.

@rob: The controller should be the data as far as the view is concerned. Otherwise the view knows too much and the controller can't re-proxy a different model.

Knows too much about what? The view lives to present the data to the user - that's all it should know. The fact that the controller is the data is a design problem.

Re: EmberJS Confuses Me

#37

Post by blktiger »

robconery wrote: post #19
ef4 wrote: post #17

> When talking routes, urls, and resources - that's a RESTful consideration and involves stateless state "stuff" (sidestepping the REST debate here). What is this concept doing in a desktop app?. Ember is explicitly not about "desktop apps". That's actually why Ember broke off from Sproutcore. Ember is very opinionatedly focused on building web applications that are native to the web and stick to web conventions. The…

The team has been rather clear that Ember is Desktop MVC, not web/server based: https://twitter.com/trek/status/309315009291378690 They say as much in their guides as well.

I'd definitely say that Ember is more Desktop MVC than MVC2. True to it's Sproutcore/Cocoa roots, you are supposed to be able to wire up a lot of the application with the built-in controllers that don't have to be customized (or at least customized very little). Ember is trying to take that approach, make it more familiar to web developers, and add in some additional parts that are part of what makes the internet work (ie, routers for managing state/bookmarkable urls).
Post reply on HN