

EmberJS and Confusion, Part 2 - ericmj
http://1fifty9.com/post/45053521205/emberjs-and-confusion-part-2

======
charlieflowers
This article hits the nail on the head.

Remember, "MVC" means so many different things. Originally, the "controller"
was needed for low-level keyboard processing, something no modern "MVC"
framework needs in the same way. (See Martin Fowler's history of the term if
you're unfamiliar with it).

So really, all "MVC" means these days, is, "Hey, we put some thought into how
to have better separation of concerns in our UI code."

But past that point, it is hard to make simple, true statements that include
all of the MVC frameworks out there. Rails controllers are different from
Ember's controllers are different from Backbone controllers, etc.

So when someone tells you, "Here's an MVC framework," the only reasonable
expectation you can come in with is that they put some thought into separation
of concerns. Where that thought led them is likely to be very different from
other MVC frameworks.

And in Ember's case, the particular details are, "Our whole philosophy was
strongly influenced by Cocoa."

Ultimately, we seem to just now be getting to the point where we can, as an
industry, intelligently figure out what concepts do make sense in a single-
page javascript framework that "puts some thought into separation of
concerns." It's not likely to be any of the approaches we've already tried,
because our "javascript platform" was immature, and all we have done so far is
borrow ideas (from Rails, or from Cocoa, or wherever).

------
sideproject
Another interesting post! It's even more interesting for me, since I've been
testing with various JS frameworks in the last two weeks; namely the three
major ones - BackboneJS, EmberJS and AngularJS.

Aside from the points you've raised, here's a small conclusion I have made.

"Creating a complex web application with Views, Sub Views & Deep-linking is
difficult, no matter what framework you use".

I feel comfortable with BackboneJS because there isn't too much abstraction
and convention. Therefore, once you get the hang of it, you know what you are
doing (not sure if it sounds right, but it feels... pure, or purer than
others).

But BackboneJS does in fact make me repeat a lot - which is why there are a
number of plugins and other frameworks that try to cover this (e.g. Backbone
Marionette, Backbone layout manager, Backbone.Subview, Backbone.Courier).

After 'giving up' on EmberJS, I've looked at AngularJS. Their example was
quite simple and made sense. But as soon as I tried to create a complex app, I
got stuck.

Working with these frameworks has been quite interesting, because we are
trying to somehow capture the state of the app in the URL (e.g.
<http://a/#b/c/1/3/2>) so that if that URL was bookmarked and user directly
goes there, we want the web app to be able to render all the parent + child
views, grab the necessary data (sometimes making sure that the order is
correct) and display them as expected.

It's all do-able in either BackboneJS, EmberJS and AngularJS, but this type of
apps are complex and I'm not sure if any one of these frameworks make it
"magic".

~~~
krob
I'm going to have to agree with your statement, "Creating a complex web
application with Views, Sub Views & Deep-linking is difficult, no matter what
framework you use". I tried using emberjs, their docs at the time were all
over the place since they were not in-sync with their distributed code-base
for learning. I've noticed more people have created good tutorials working
with backbonejs and seems the right path moving forward for atleast making
something remotely understandable.

~~~
logical42
the documentation has improved rather drastically as of late. the router api
is stable going forward, so it's actually a pretty good time to be
experimenting with ember (though this was not true about 4 months ago).

Personally, I really like ember. I think most people would have a better
experience with ember if:

(1) they avoided learning off of the master branch during the crazy api
changes over the last few months

(2) avoided ember data for the time being (or ever, I have my doubts about how
viable it is)

(3) they asked questions on stack. the ember core team is actually pretty
snappy at answering questions.

but there is still a bit of lingering weirdness with the router that people
should look out for, the things that come to mind are:

a) back button errors

b) awkwardness in the serialize/model hooks depending on whether you're
navigating through the app, or trying to get to a url in a new browser window

but despite its shortcomings, I've really grown to love the organization that
ember gives to my javascript code base, and how it would make my program scale
as it grew in size and complexity.

~~~
ollysb
When I took a look at emberjs a few months bach ember-data was one of the most
appealing parts. What are your concerns regarding viability?

~~~
logical42
read-only attributes comes to mind, but that was four months ago and it seems
that it's been pretty much worked out here,
<https://github.com/emberjs/data/pull/303.>.

Regardless, I still think it's a bit overkill. You'd be surprised to see how
much of the basic ember-data functionality you can achieve just by using
Ember.A and Ember.Object.

