
EmberJS Confuses Me - statenjason
http://wekeroad.com/2013/03/06/ember-confuses-me
======
avolcano
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 even need to mean it's tied to a specific model type. For example, my
Dropbox integration is handled within a controller that's bound to several
separate views (in this case, those views included buttons that triggered
syncing and modals that displayed the progress of syncing). There's no
"Dropbox model," just other models that I'm using this controller to sync.
Controllers are not simply an intermediary between models and views, they are
an intermediary between _state_ and views.

> I'm trying my best to reconcile this with the notion that a controller
> (classically speaking) is supposed to ... well control the view. Here, it's
> not doing that.

I think what the author was looking for in controllers is what's actually
handled by, well, views. The view handles any user interaction, and then uses
the controller to change the state of various bits (whether calling methods in
the controller or simply updating properties on it).

To sum up: model is data, controller is state (including instance(s) of
models), and the view is user interaction. Templates can bind to properties on
any of these. Routes are what hook these components together depending on the
page.

~~~
robconery
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.

~~~
wycats
In this case, the "state" that we're talking about is "what state are you in".
In other words, the router manages high-level state ("I am looking at a post
now"), and provides long-lived controllers with data reflecting that state. So
even though there is information about the current state in the controller
(and the view), the source of truth about the current high-level state is in
the router.

~~~
steveklabnik
To expand slightly:

"Application state", rather than "stateful vs stateless" state. The router
specifies "I'm looking at a post now" and the controller specifies "Looking at
a post means loading this particular Post model as well as these comment
models"

------
ef4
> 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.

~~~
robconery
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.

~~~
ef4
> 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 build.

A flagship example would be Discourse, which is very deeply web-focused, and
nothing like the way you would structure a desktop application.

~~~
robconery
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"

~~~
tomdale
Yes, Edward Faulkner has used Ember heavily and was one of the original
contributors back when we started the project.

------
sideproject
I come from Backbonejs background with which I have worked for about 1.5
years. So I feel quite comfortable with it.

I decided to try Emberjs - not for any other reason than trying to pick up
something else and see how other JS framework approaches.

I gave full two-days worth of time into it. Initially I thought - "How
different can it get?" Plus, I believe even if it's very foreign I'll just
keep reading, googling, stackoverflowin', youtube-tutorialin' to get my head
around.

I gave up though. Here's my _hopefully constructive_ rant, though my views are
probably not as deep as the OP's.

* Many of the posts on the net are outdated. I followed a few tutorials here and there, and then things didn't work, so I asked on Stackoverflow, then the answer I got was "Dude, your code is outdated". Sure this is probably similar thing for other frameworks - but I'm just sayin'

* Models - So there is Ember Object, which you can use as models, but you can also use Ember-data.js which is more "glorified" data. Documentation wasn't clear on the difference. Plus, Ember-data.js was quite hard to get started with. It didn't work well with other versions of Emberjs. I really had to dig in to find the right one to start off with. I ended up cloning a github repo of a tutorial that worked, because nothing else did.

* Documentation on "convention over configuration" - OK, so convention over conf. is fine. But the official documentation and many of the tutorials didn't explain what all the conventions there were. I went through a tutorial app, which only had Controller, but things just "worked", because the Emberjs builds all other things for you. Well I didn't know that! THE BEST INTRO EMBERJS VIDEO I found was this.

<http://toranbillups.com/blog/>

It finally made sense in the end for me.

* But in the end, among all other things I wanted to do, I gave up, because the frustration was mounting up. I guess I can still persist through it. But I just finished AngularJS tutorial demo and in 2 hours, it makes sense to me.

~~~
rxcfc
The Ember teams has been planning for a sweep of all outdated information
about Ember. We'll be updating SO questions and asking blog authors to add a
disclaimer.

Ember Data is a completely optional component of Ember that seeks to bring
ORM-like abilities to the client side. It's not as far along or as stable as
core Ember. For what it's worth, you can easily just use jQuery.ajax and
create Ember.Objects from the response. We probably do need better
documentation in this area to make this clear. That said, it's not fair to
count Ember Data as a point against Ember since no other framework has
anything at all similar in scope.

Our overview documentation is lacking. This is something that we're actively
working on improving. The hardest part for new developers coming to Ember is
that the paradigms are very different than what they're used to. We believe
that the paradigms are the correct ones, but we need to do a better job
explaining them.

~~~
bengillies
Without meaning to offend, I'm afraid I have to take issue with your points
about Ember-Data.

Yes it's optional, and yes you can use jQuery.ajax or whatever, but in
reality, it's not quite that simple.

The official guides in Ember default to assuming you're using Ember-Data
(though they do at least mention it explicitly). This despite Ember-Data being
far from production ready (as stated on the Github page) and far too slow for
dealing with large quantities of data. At the same time, the conventions that
are found in Ember-Data appear to be built in to core Ember (it says as much
in the guides).

As far as Ember-Data not counting against Ember - it may be larger in scope
than other client side data libraries (or the M part of other MVC frameworks
or whatever) but the fact is that they are most definitely comparable, as it's
the way that Ember gets stuff off the server, and saves it back to the server.
Without Ember-Data, Ember has no built in way of doing that, which counts
against it. With Ember-Data, well, it's not really ready yet, which also
counts against it.

~~~
rxcfc
Ember is built to work with Ember Data out of the box, but it's trivial to
make your own methods that fit with the conventions. I assume you're referring
to the default `find` support in the router. All that Ember does is attempt to
infer a class name and call `find(id)` on it if the `find` method exists. You
can implement this method however you want, or even change your routes to call
an entirely different method.

I also highly recommend watching one of the follow talks about Ember Data:
<http://www.youtube.com/watch?v=_6yMxU-_ARs> or
<http://www.youtube.com/watch?v=V8nnE948zxk>. Both talks make it very clear
that Ember Data is not at all comparable to what is offerred by other
frameworks.

~~~
bengillies
I totally get that it's different to what's in other frameworks (the router is
similarly different), it's just that, for the most part, on the surface, it
pretty much serves the same purpose (other than some relationship stuff that
half works). That is, it's the same the same part of the framework, just with
extra features. Oh, and with a whole load of undocumented coventions in it.

Btw, is there a diagram or something that shows how it's put together
internally (I'm pretty comfortable with how to use it from an API perspective,
but find myself having to dive into the source code fairly regularly)?

~~~
rxcfc
Unfortunately, no such diagram exists though it would certainly be useful. The
lack of documentation is tied a lot to the instability of the Ember Data API,
both of which are reasons why it hasn't had a formal release yet.

------
jfarmer
I'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 --
but if the controller is running continuously then it needs to reflect changes
in the models as they happen. The model(s) the controller references can
change without the view changing its reference to the controller.

Without something like this the view would render stale data. I'm assuming
this is why we have a controller.model, to add that layer of indirection.

What am I missing? How is this more complicated making the controller<->view
relationship pull instead of push?

~~~
robconery
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.

~~~
jfarmer
That's not how I'm seeing it. The controller has data, some of which might be
from the model. The view shouldn't care whether the data came from a model or
not. It would be coupling if the view _did_ care.

The view asks the controller for data. The controller might delegate that
question to the model. The view shouldn't care whether the data was delegated
or not; it should just get a response from the controller.

Seems like textbook object-oriented design. Otherwise how will the views
update automatically when the models change? The views shouldn't know what
models it needs. In fact, it seems they shouldn't know that models are a thing
at all. It's just data from the controller.

~~~
clintjhill
This is actually where I think Ember does better than the Angular sample
provided. Ember controllers hold the "data" in a "content" field on the
controller (proxied). Any model can be placed there. If you do add a "people"
field to the controller (as in the sample) I'd argue that does what you're
describing here as "bad" because it's specifying information in the view about
the model.

------
pilgrim689
> 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 attributes and you're HTML-
compliant again :).

~~~
xaritas
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 think that some people prefer to
see bindings sprinkled on the DOM via code, as part of the bootstrapping
process. I haven't used Backbone for a year but I'm pretty sure it is a strong
proponent of "let nothing live in the DOM" school of thought. I don't
subscribe to that, by the way, but that's the argument.

~~~
daigoba66
> 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.

~~~
MatthewPhillips
What happens when you want to add a second, unrelated, thing? Just stick it on
the end in the onclick? Create a new function called doTwoThings()? This is
one of the reasons I prefer using an observer pattern over MVC.

~~~
aidos
That doesn't really happen though - also, Ng-click is a specific directive you
can choose not to use.

A more general argument is that any behaviour specified in markup is bad. I'd
counter that by saying that it's already there in HTML. Input boxes for
example have behaviour intrinsic to their being. So angular let's you create a
(for example) richtext tag. You attach behaviour to that tag, say on click. In
the HTML it's as clean as <richtext>. Within the directive you can make it
behave as you please.

I think that people see the shortcut directives used in angular (eg Ng-click)
and the purists shout "unclean"! The reality is that You can do things a
slightly longer way and end up with something thy looks a lot like the
observer pattern.

------
jacquesc
Really nice constructive writeup (as always by Rob), and I think it should be
addressed by some better EmberJS docs and tutorials. They do a good job
explaining the "what", but it could probably use more "why".

It took me a while as well to figure out why controllers proxied to models.
However it started to make a lot of sense in when building an app, since the
controllers are there to stay around, and the models are swappable.

Having the option to easily swap out a model at the controller level is worth
the extra layer abstraction. That and the ability to add additional UI
specific properties on the controller that don't necessarily belong in the
model (since they don't need to be persisted).

------
tree_of_item
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.

~~~
chipsy
This is the comment I agree with most. Replace a solution defined as a "design
pattern" with one defined as a data structure and you get a lot more clarity.
The problem MVC solves can be recomposed as "synchronization of concurrent,
related, mutable data structures." The relations are definable as a DAG for
each direction; the synchronization process with a cyclical graph.

~~~
rapind
"Synchronization of concurrent, related, mutable data structures" is totally
clear to me.

------
jondot
In the past I've been working on enterprise application suites for the
desktop. The kind of monstrous applications that run on electronics
manufacturing floors. Such a typical application has a shell, modules, inter-
module communication, dynamic module loading, plugins, and much much more.

One can think of it as Eclipse with its ecosystem.

To build such a system on the Enterprise with its typical NIH (not invented
here) paranoid attitude was VERY hard.

I had to reinvent a lot of wheels.

On the Web, I've used backbone for a long time now, since almost the time it
was out. I saw the same problems building complex applications with it (that
backbone-marionette amends to a great deal). For a larger project, I evaluated
Angular. Had very strong negative feelings about it.

Then I tried Ember. It took me a long time to "get" it. The only thing that
kept me motivated is knowing that Yehuda, Tom and Trek and other capable
people are contributing on it. I kept fighting through the outdated tutorials,
the outdated videos, and even the peepcode video was embarrassingly confusing
to me at some point.

But then it hit me. Ember and its infrastructure, the way its MVC is rigged,
was very similar to what I was building from scratch on the desktop many years
ago. It truly IS the one framework that "gets" desktop, or client-side,
applications.

The causer of my confusion was that I didn't completely let go of the "Web-
think" for building application. I was stuck at either server-side MVC (MVP),
or bare-bones frameworks such as Backbone.

It's been just too long out of the real complex desktop game for me, to
realize what that I'm looking at is a proper MVC framework.

So for me, Ember ended up as being great - it still takes me back to the way I
was building desktop applications, and I'm sure it will become even better and
better. To understand it, you need to cold-boot your thoughts into that
classic desktop MVC place; and if you were never in it, I think Ember is an
excellent way to get into it as opposed to other frameworks.

------
tonycoco
Curious for yourself? Try following my simple starter app tutorial of Rails +
Ember.js here: <http://www.devmynd.com/blog/2013-3-rails-ember-js>

Though, I understand the pain of coming from a server-side MVC architecture, I
found it refreshing that Ember.js takes the "desktop" MVC approach. Our web
apps are now living on the client, acting like desktop apps. Most people
struggle with this reverse at first, but can conceptually catch on if shown
the way. I think what really needs to happen is a good screencast or two
walking through these concepts. I'm interested in putting something together
and will when I have the time.

~~~
ffreire
There seems to be some very positive buzz around this screencast mentioned
both in the OP's blog and around HN in general:
<https://peepcode.com/products/emberjs> . I found it particularly instructive
but found that it only scratched the surface of this new framework. At least,
it scratched enough off the top that I feel comfortable rooting through source
and API documentation to figure out the rest. YMMV, of course.

~~~
tonycoco
Agreed. I'd like to spend some time and come up with a longer screencast that
did a little bit more of a "deep dive".

------
selvan
I tried Emberjs and Angularjs recently, as both framework offered two-way
binding between view & model, at client side.

Angularjs was easy to pickup and I have completed what I wanted to do in about
half a day, except one issue, angularjs template rendering is DOM driven. I
wanted server-side templates, hence I have to boot phantomjs at server-side. I
didn't quite like booting phantomjs for server-side templates.

Since Emberjs offered, handlebar based templates, I was happy that I could
render my templates at server-side. So tried emberjs, it took about 3 days, to
get it done. Many out dated tutorials & documents spread across internet about
older versions of Emberjs. Documentation at emberjs.com is minimal and not
helpful. I started looking at source code of discourse.org and try to
understand how they used ember. I felt the power of emberjs when I needed
complete control of context and rendering of nested templates. It was real
beauty.

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

~~~
davedx
SEO.

~~~
e12e
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.

~~~
masklinn
Also to improve "bootup time", from request to usable: server-rendered
templates can be cached, can provide at least visible content before
javascript even has to run and can use beefy servers & the like. At that point
the client "only" has to do the events binding wiring and it's done.

------
tericho
I'm by no means an "expert" but I shared the same struggles and after 2 weeks
of trying to build a complex app I gave up.

I switched to Angular (which I also had never used before) and got the same
app up and running in a couple days with even more functionality because I was
able to hash lots of the trickier "outside-the-box" functionality that I could
not for the life of me get working in Ember.

That being said I really like Ember's syntax, Handlebars integration, core
values (performance & stability specifically) and have the utmost respect for
its creators. I'm hoping since it hit 1.0 that lots of new sample apps, blog
posts and SO-type Q&A resources will start showing up and actually stay
relevant for more than a month.

------
pixelcort
Think 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.

------
andreipop
Take a look at Yehuda's talk from Seattle:
<http://www.youtube.com/watch?v=4Ed_o3_59ME> \- I think it explains a few
things very well, and helped me out a ton

------
pradeepin
Yes, I too agree EmberJS always a confusing library, Following are my resaons.

1)They say it follows MVC. Its actually MVC but MVP, if you look closely at
the implementation.

2)Controller job is not precisely defined. Example: Even the data validations
are done at controller level not a model level

So i switched to Backbone.js, which is very flexible library with tons of
plugins that can be used when needed.

Since implementation of UI is different from requirement to another
requirement. I feel EmberJS doesn't satisfy this, which leads to people using
Backbone.js.

Regarding AngularJS, please use it only if you are new javascript and prefer
learning Angular Javascript (which is not javascript by the way) :)

~~~
ganarajpr

      Regarding AngularJS, please use it only if you are new javascript and prefer learning Angular Javascript (which is not javascript by the way) :)
    

I am not sure you "know" javascript. If you are saying that there is an
Angular version of javascript then you are terribly mistaken. Angular is
probably one of the only mainstream framework that stays true to javascript.
All other frameworks ( Backbone, Ember etc.. ) are the ones that actually
mould javascript into an OOP language. I would say that Angular uses the
prototype chain ( you know javascript is a prototypical language right? ) the
best. The whole scope object inherits prototypicaly while in all other
frameworks we create an illusion of OOP. Someone correct me if I am wrong
here.

Just for clarity, I believe that when you write Angular code you are writing
the purest form of javascript. Because thats what you are writing there. Just
plain javascript. There is no constructs imposed by the framework at all. This
is probably why most people think "Angular's javascript" is not javascript.
They have been always fed layers on top of javascript because "javascript is
somehow not optimal, not right" and it has to be "changed" and "corrected" .
OOP is shoved down the throat. This is probably gone on to the extent that
when someone actually writes in pure javascript it starts looking like a
foreign language !!

~~~
WickyNilliams
Before berating other people's knowledge, you should probably make sure that
what you are saying is infallible. So with that I ask you:

Do _you_ realise that JS is an object oriented language? Prototypes are a
means for inheritance (i.e. reuse of code), just as classes are in more
traditional languages - it does not mean JS is not OO.

My interpretation of the GP comment is that he means angular to JS is like
jQuery to JS, it's effectively a DSL that you have to learn in itself. Someone
once said "people don't write javascript anymore, they write jQuery". That's
what I think he meant

~~~
Pherdnut
Uh, you were the one who suggested JS wasn't OOP-oriented. It's all JS to me.
jQuery is just a function that's spits out adapter/decorator objects. Just as
Angular, Knockout, Backbone, Ember, etc... are all just bloatworks that miss
one critical point. We already had the V and the C pretty well covered.
They're throwing a big veil of abstraction over one that was already there and
worked fine. It's like webforms all over again only this time we're trying to
pretend the client-side isn't already what it is rather than not there at all.
And while yes, IMO, we should think of web apps as two separate apps, the
client-side's concerns are localized enough that it's kind of silly to try and
apply MVC to it (not that what any of this stuff does can really be called MVC
or MV-whatever anyway). What is it with modern developers wanting frameworks
to be the answer before they understood the question in the question in the
first place? How do you even write this stuff without starting to feel a lot
silly about the fact that you're just duplicating effort? Because at some
point they all have to bind with the mechanisms already in place to bind to
their own bindings and that's just stupid.

~~~
WickyNilliams
Are you replying to the correct person? I quite clearly stated JS _was_ OO,
whilst the GP clearly says that MV* frameworks "create an illusion of OOP".

If you're not convinced of the benefits of MV* frameworks on the client,
please write a complex client-side app with vanilla JS and share what you
learnt.

I'm being sincere there - I've tried, and I quickly started drowning in sea of
boiler plate code I'd rather not have to write. Not that it's not fun to write
some of that stuff, but I'd rather be delivering value. And what happens when
I create a second app? Hmm seems there's lot of similar boiler plate stuff,
why don't I just abstract that into a framewo.. oh wait

------
melc
i've been using ember for the past three months in a fairly complex project
and i'm very happy with it ; a platform that builds business web apps
dynamically for devices (20+ pages,250+ fields per app with validations,
calculated fields, conditional flows etc , rendering/theming in jqm ->
packaged with phonegap) and client web browsers (render/theme in
bootstrap),the backend is in java. So, i certainly don't feel the same way for
emberjs as the writer.

I had decided to build the frontend in a js mvc framework and the candidates
were backbone, emberjs (pre version), angularjs. Read about them and gave
backbone a try, however from the documentation only emberjs approach felt
better maybe because of a similar in-house development java framework that we
work on. So i tried to give emberjs a try at the same time, due to the tight
deadlines. I dropped backbone, and spent more time on emberjs because
everything simply worked and fitted together nicely. All these binding
mechanisms are great and actually work :) . Haven't tried angularjs.

The system now works with emberjs (pre and rc) with a nice layered
architecture and separate independent business logic modules.

My advice is to read the documentation carefully and choose what fits better
to your needs and coding styles.

------
terbanator
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"

~~~
terbanator
<http://jsfiddle.net/sgterban/kDqBs/> \- Example

~~~
drogus
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.).

------
clintjhill
The 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?

~~~
robconery
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.

~~~
clintjhill
Except you could write identical code in Ember as well when you extend the
controller. Replace "$scope" with "content" and it's identical.

~~~
robconery
Interesting - didn't know this. $scope is injected by Angular and available to
the view - is this the same thing? I didn't think Ember had a DI aspect to it.

------
ghurlman
Here's the Google cache:
[http://webcache.googleusercontent.com/search?hl=en&biw=1...](http://webcache.googleusercontent.com/search?hl=en&biw=1256&bih=787&sclient=psy-
ab&q=cache%3Ahttp%3A%2F%2Fwekeroad.com%2F2013%2F03%2F06%2Fember-confuses-
me&oq=cache%3Ahttp%3A%2F%2Fwekeroad.com%2F2013%2F03%2F06%2Fember-confuses-
me&gs_l=hp.3...9193.10065.1.10319.6.6.0.0.0.0.70.287.5.5.0.les%3B..0.1...1c.1.5.psy-
ab.Z1SKTeDnL-M&pbx=1)

text-only:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://wekeroad.com/2013/03/06/ember-
confuses-me&hl=en&biw=1256&bih=787&strip=1)

------
anarchotroll
Seems like the big confusion about the controller is that it is closer to a
ViewModel (think MVVM) than to a Controller itself.

Potatos, Potahtos.

~~~
mcgwiz
That's the hunch I had reading this (as someone with no EmberJS experience).

To digress a little, it's not much different than the terminology confusion in
Backbone, where:

\- Router(s) work as front controllers,

\- templates (along with the browser's DOM) as views, and

\- Views as presenters (from the MVP pattern).

Models are flavored with the Active Record pattern. Presenters and views are
tightly coupled.

MVC and MVP coexist because the controllers respond to navigational input
(mapping to model-presenter pairs) and the presenters respond to page-specific
input (mapping to model manipulations and, possibly, server calls).

------
pspeter3
Watching the peep code screen cast helped a lot

~~~
BaconJuice
can you post a link to this?

~~~
rizumu
<https://peepcode.com/products/emberjs>

------
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.

------
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!?

------
Tichy
I think the way controllers work here is similar to Ruby on Rails? It confused
me in Rails at first (coming from the Java world), but I think it is
essentially just a hack to allow for "easier" passing of data to the view (the
controller gets exposed to the view). So instead of scope.whatever = "hello
world" you can write this.whatever = "hello world" (OK not really shorter, but
something like that).

That usage of Controllers is not part of the MVC pattern, I'd say. It's just a
recycling of the controller instance - not forbidden, just confusing if you
wonder what it has to do with MVC.

Actually it's also the RoR way to have short lived controllers (a controller
is instantiated for every request), other frameworks use one static controller
instance instead.

------
randall
The 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!

~~~
robconery
This is fixed - thank you.

------
stevewilhelm
> 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.

This may be the issue. I think most of us never really wanted to build web
applications, but we were forced to do so due to browser and framework
limitations.

We really just wanted to build the best damn desktop app possible that just
happened to be deployed in a browser via the Web. This might explain our
confusion and disappointment when client side frameworks don't deliver on that
desire.

~~~
Pherdnut
Most of whom? I came up in JS on the client-side. Nothing has been more
frustrating over the years than watching all of the inflexible bloat and
tightly coupled BS people have been piling on to the client-side in order to
pretend it was something that it is not. Web forms sucked ass. Everything Java
tried to do to pretend the client-side wasn't there has left massive legacy
potholes all over the web. Just deal with the thing as it is already and learn
something new. You're a programmer for chrissakes. I might indulge in writing
OS apps with webkit but I don't try to add a server to the process if it's
just a local desktop app in order to make it more like what I'm used to. HTML,
CSS and JS properly applied are doing 4/5ths of what these frameworks are
pointlessly reinventing. All you have to do is learn them properly. The rest,
keeping data loosely coupled, is basic 'duh' OOP. All the stuff that's already
there works surprisingly well if you actually give it a chance. Or have you
not noticed that web technology solutions are spreading like wildfire into
other domains or that we can implement and modify GUIs using client-side-web-
technology a lot faster than desktop OS UI developers have ever been able to?
FFS, they don't deliver on that desire because it's proven time and time again
to be a complete waste of time to try to.

------
jhysum
Instead of controlling the view directly from the controller, the view uses
the controller object (proxy to model) in any way it wants allowing you to
change the view without changing the controller and same with the controller.
I think the issue you are facing is thinking that you are tightly coupled to
the controller by using the controller object, depending on what you think
about how much coupling is too much coupling you can argue that just using one
object might really be decoupling. I'm not sure if I was able to get my point
across.

------
gosukiwi
Well, I don't know EmberJS but for the handlebars code you showed, seems like
the controller is somewhat more like a ViewModel (MVVM pattern), maybe
learning KnockoutJS first would help a bit?

~~~
msarchet
Rob has done knockout, and that's pretty unrelated I feel. I've spent a lot of
time doing Knockout and a fair amount of time in Angular and Backbone, and
personally I sort of agree with what rob is saying. I feel like they have
taken MVC and just loosely applied it in Ember, because they have Models Views
and Controllers. I see and understand where his confusion is coming from. I
probably also haven't spent enough time with Ember to get it, but I also don't
feel like I want to.

~~~
gosukiwi
Well maybe it helps to wrap your mind around Ember controllers. From what I
read, I'd rather use Backbone.

------
sandstrom
Although really old (and outdated) I found this Sprout Core introduction
useful. The first 3-4 minutes was enlightening for me.

<http://vimeo.com/24487742>

------
itsbits
I have been into MVC frameworks for 4-5 months now...mostly used BackBoneJS
before switching to EmberJS..conceptually I did felt EmberJS very tough in the
beginning..i was worried whether i made the right choice in using EmberJS for
my product..but now with the latest 1.0rc2, its so easy in
development..routing has been improved very much..Binding is the awesome
feature i liked and helps me thgh..an added advantage over BackBone...i cant
say about angular..but am quiet happy with EmberJS...

------
mark_l_watson
Until tomorrow there is a 37% discount on the MEAP
<http://www.manning.com/skeie/> The discount code is m137

------
fcatalan
Ember confuses me too. I've worked with many server and desktop MVC frameworks
for almost 20 years. I'm familiar with MVC, it plays simple and easy, like
rock-paper-scissors. My problem with Ember is that it seems to be more like
"rock-paper-scissors-lizard-spock but for us the rock punches through the
paper and the scissors cut the rock like butter. And you can play without
actually showing your hand". Confusing.

------
devinrhode2
At first read, I thought your point about routing was really good - why not
have route('about').template('aboutTemplate').controller('aboutController') -
and then I realized this is all reapeating the same mumbo jumbo. This is all
automatically matched up by the naming convention (which frustrates me too,
but until I figure out a better way...)

------
nXqd
The only reason is you are in love with AngularJS. I will find someone who
really hates angularJS because if we have a lot of validation, it will become
a messy of ng-*.

So no matter which framework we use, we should talk about real world project.
Not simple usage that only exists in trying and testing.

Use the framework, you love and you will make it beautiful no matter what :D

~~~
jonascopenhagen
> I will find someone who really hates angularJS because if we have a lot of
> validation, it will become a messy of ng-*

Are you talking about HTML validation? AngularJS supports using data-ng-*
which means it's valid HTML.

------
seivan
Wonder how many iOS developers feel home with Ember? I don't. I also do Rails,
and I feel more at home with Batman than Ember.

------
newishuser
Don't give up! Ember has a steep learning curve but once you've got a bunch of
it memorized development gets much easier.

~~~
jonny_eh
I learned Angular instead since it was easier to get my feet wet with it and
seemed to make sense to me. Am I missing something by not using Ember?

------
gavanwoolery
I have not used Ember, but you mention MVC, which immediately brings to mind
Sencha. I have used Sencha a lot, and although I think it is mostly great, I
do not like how they try to pidgeon-hole you into the MVC methodology, which
just does not make sense in many contexts.

------
richo
> I think Yehuda is a very nice and smart person

I always get confused by this. I don't understand how being nice factors into
technical decisions?

(For the record, I also think wycats is nice, but I don't really care when I'm
trying to decide whether or not what he's saying makes sense)

~~~
davidw
If you need help, want to suggest a modification, or otherwise need to
interact with the author(s) of something you're using, it's nice to have
friendly people to deal with, rather than assholes, all else being equal.

~~~
richo
I hadn't thought of it that way.

------
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.

------
nirvanatikku
+1. you hit the nail on the head and articulated what I was feeling when I
played with ember.

------
ZoFreX
Thanks for sharing this Rob, it was actually very informative about Ember to a
newbie!

------
xmlninja
You are not alone.

------
BlindRubyCoder
The whole point of EmberJS confuses me.

