Watching the peep code screen cast helped a lot
EmberJS Confuses Me
11–20 of 142 posts
Re: EmberJS Confuses Me
#12Here's the Google cache: http://webcache.googleusercontent.com/search?hl=en&biw=1...
text-only: http://webcache.googleusercontent.com/search?q=cache:http://...
Re: EmberJS Confuses Me
#13> 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…
Absolutely true - I should add that in. I think people look at that, however, and don't like functionality etc. shoved into the DOM. But your point stands.
This is addressed in the article, the Handlebar templates have functionality too.
Re: EmberJS Confuses Me
#14The Angular example is a bit incorrect... when you do an ng-repeat, you're going to do like ng-repeat="person in people" and then each template item will be like {{person.name}} as opposed to just {{name}}.
Just a little clarity in the code. Thanks for the writeup!
Re: EmberJS Confuses Me
#15I've never used EmberJS and am not familiar with any of the front-end JavaScript frameworks, but I don't get what's confusing. It looks like instead of the controller pushing data to the view, the view asks the controller for data (which it might proxy to the model). This makes sense with a long-running controller, right? On the web both the controller and view are ephemeral -- they last for just that one request --…
The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.
Re: EmberJS Confuses Me
#16The examples provided to describe the difference between controllers in Ember and Angular do not appear to be different to me at all. In fact I'd argue that they are identical. It feels to me as though the author is wanting them to be different because maybe it's a style preference from the templating perspective?
The examples were to show how $scope is used in Angular vs direct use of the Controller/Model proxy in Ember. This makes a bit more sense to me, personally.
Except you could write identical code in Ember as well when you extend the controller. Replace "$scope" with "content" and it's identical.
Re: EmberJS Confuses Me
#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 best web applications still behave like the web is supposed to behave: they have shareable, bookmarkable URLs that allow the application's state to be recreated. This is a big reason Ember's router is different than the other examples you mentioned -- in Ember the router automatically handles a lot more of the state reconstruction stuff.
Re: EmberJS Confuses Me
#18I've never used EmberJS and am not familiar with any of the front-end JavaScript frameworks, but I don't get what's confusing. It looks like instead of the controller pushing data to the view, the view asks the controller for data (which it might proxy to the model). This makes sense with a long-running controller, right? On the web both the controller and view are ephemeral -- they last for just that one request --…
The controller is the data. The model is grafted onto it for convenience. This ties the view to the model to the controller which is sort of orthogonal to "separation of concerns". In my opinion at least.
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.
Re: EmberJS Confuses Me
#19> 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.
Re: EmberJS Confuses Me
#20Think of Ember controllers as proxies, or pointers if you will.
The idea is you can have a commentsController instance, and when you switch to a different post, the view(s) bound to it will automatically pick up the new comments array that is swapped out on behind the controller.
Routing is just rewiring the pointers on your controllers and getting the right views up on the page.