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

121–130 of 142 posts

Re: EmberJS Confuses Me

#121

Post by e12e »

tree_of_item wrote: post #41

I think the problem is MVC itself is a confused mess. It means whatever each person wants it to mean, since it's too easy to make up a bunch of reasonable sounding argumentation for whatever you want to do if you use the words model, view, and controller a lot.

I feel that as with many things in Computer Science, the original MVC-stuff is regrettably "under-read"[1] by a lot people. I highly recommend having a look at the various links on:

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

for those that haven't read what the original model-view-controller-user idea was all about. It makes more sense from a Smalltalk/Self/Object-C/Message-passing style of object orientation ("true object orientation") than from java -- in this sense it should be a good fit for javascript as well -- but unfortunately java/c++ style object orientation (really "class-inheritance orientation") have bastardized MVC to mean something subtly different (I am not quite sure what, exactly, but I don't think I'm the only one...).

[1] "Well, I'm an old-fashioned guy. And I also happen to believe in history. The lack of interest, the disdain for history is what makes computing not-quite-a-field." -- Alan Kay http://www.drdobbs.com/architecture-and-design/interview-wit...

Re: EmberJS Confuses Me

#122

Post by e12e »

davedx wrote: post #105
Kiro wrote: post #101

Earlier quoted context omitted.

In what circumstances would you want server-side templates and how come it's easier with Handlebars?

SEO.

Not only SEO. If you need to build a webapp that is also a web page (eg: blog, wiki, cms) -- you want a rich client, but also relatively plain pages -- and ideally you want to share code/templates where it makes sense.

Re: EmberJS Confuses Me

#123

Post by ryanflorence »

floydpink wrote: post #118
nikcub wrote: post #94

Earlier quoted context omitted.

Since Ember 1.0 isn't compatible with Ember x.0 you could save yourself a lot of that work by sticking to semantic versioning and just calling it 'Ember2' I went through the same thing grandparent post did - a lot of old tutorials. I think it would be a good idea for Ember to make a complete break and to call this 1.0 release something else.

Semantic versioning states everything inthe public API should be considered unstable and changing until the major version is 1. So whatever code samples are out there on blogs and SO were from the initial days of the API when it was changing a lot. I am with you and have been going through the pain of weeding out examples from the web that works with the latest version on GitHub. There were many methods that weren't…

That's exactly what is happening.

Re: EmberJS Confuses Me

#124

Post by sudhanshu80 »

We have applied EmberJS to a fairly complex application backed by Rails backend. We had to deal with complex JSONs delivered by backend which were schemaless MongoDB documents. At lot many places we had non RESTful Rails controllers. So when we started with EmberJS we had a worry the documentation was not proper, there were very few reference projects. After a few weeks of thrill and steep learning we settled on with things. We have applied a lot of functionalities offered by Ember to our code. Migrated from router from old to new api of pre 4. But we feel in our team it was right thing to apply Ember. The way overall MVC imposes structured programming, the way HTML is seperated from JS, the way ember data can have serializer and adapter customized, two way bindings all of it had been useful. We struggled at few places with deep nested JSONs in hasMany/belongsTo relation in embedded JSONs. But doing workarounds were easy. We used fixtures to hasten development while backend was not yet ready. All in all we believe that we made a good choice to stick with Ember, though it looks difficult to comprehend on the start but thats also getting better with time.

Re: EmberJS Confuses Me

#125

Post by drogus »

terbanator wrote: post #44
terbanator wrote: post #42

Your examples are incorrect. The Route's model is set as the content of the controller, so all you need to say is #each item in content. Your model is set as the "content" of your controller, so your model is not "nowhere to be found"

http://jsfiddle.net/sgterban/kDqBs/ - Example

You should use {{#each item in controller}}, otherwise you won't get things like sorting of filtering right. Yes, content is an underlying array, but controller may present it differently (filter out, sort, paginate etc.).

Re: EmberJS Confuses Me

#126

Post by visarga »

I just think the basic idea is to keep things as separate as possible, to keep complexity down. Just encapsulate things OOP-like, hide the guts, and provide a clean access API to them. That makes it manageable.

Re: EmberJS Confuses Me

#127

Post by visarga »

tree_of_item wrote: post #41

I think the problem is MVC itself is a confused mess. It means whatever each person wants it to mean, since it's too easy to make up a bunch of reasonable sounding argumentation for whatever you want to do if you use the words model, view, and controller a lot.

> I think the problem is MVC itself is a confused mess.

I tried to get to the core idea, and I think it is to separate things as much as possible, and minimize interconnections, so as to keep complexity down.

In practice it means to create components (objects) that keep their guts hidden and offer an official "API" to use them.

This might seem far from MVC, but what is the purpose of MVC if not to protect us from the exponential complexity black hole?

Just don't mix things more than you have to.

Re: EmberJS Confuses Me

#128

Post by steveklabnik »

jondot wrote: post #103
robconery wrote: post #31

Earlier quoted context omitted.

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.

I rationalized this as the state-machine kind of state, of the application.

Hence REST: "representational state transfer." Fielding also uses 'application state' to talk about this kind of state.

Re: EmberJS Confuses Me

#129

Post by Pherdnut »

I'm confused by all of these MVetc... libraries. We had routing behavior to content/views covered already. How is anything that does more than help isolate/manage data more than cruft in regards to having some sort of MVC-but-not-really-style-app on the client-side-web? IMO, it's all just pointless abstraction of the type that JS devs should have learned to avoid from observing server-side fail over the years. What really blows my mind is the number of these frameworks that embed pointless behavior dependencies directly in the HTML and act like they're doing us a favor. That's awesome, now we're back to changing things in multiple places to make adjustments to our apps that used to happen in one place following basic "duh" best practices that the authors of these frameworks don't appear to have ever understood properly. HTML is the router you saps! Hell, how about we add pointless-in-a-language-with-first-class-function IOC fail, config files and pointless dependency management as well? Wait WHAT!? ARE YOU !@#$ING SERIOUS!?

Re: EmberJS Confuses Me

#130

Post by jtc331 »

jondot wrote: post #103
robconery wrote: post #31

Earlier quoted context omitted.

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.

I rationalized this as the state-machine kind of state, of the application.

I think that that's exactly what it is. I've come to believe that every application needs a state machine that contains the shared logic and state that everything could possibly need to interact with.
Post reply on HN