
Why I love Ember.js - ebryn
http://fleon.org/post/47401547699/why-i-love-ember-js
======
andrew_wc_brown
At the end of the day, I want to write the least amount of code, have the best
performance, and be able to have an easy way to test my code and all I had to
do was get over putting extra code in my DOM and structuring my javascript in
a way I wasn't familiar with.

Browse the AngularJS source code and you'll see it littered with jsperf, they
care about performance and you'll learn a lot about javascript performance.

You'll write fewer files in AngularJS since you don't need to create a file
for every view and model. I'd say I write 60% less javascript.

Testing is easy, AngularJS integrates easily with Testacular, and because you
never manipulate the dom directly, all your code you write is logical making
writing test code straight forward.

You won't see many tutorials but when you google for specific problems you'll
find many jsfiddle examples which made learning AngularJS easier than
BackboneJs and EmberJS.

~~~
hackerboos
Testacular is now called Karma if anybody has trouble finding the project:

<https://github.com/karma-runner/karma/issues/376>

------
Tomdarkness
I agree with most of this, Ember.js is great. However, I'm not so sure on
ember-data. It seems like it has great potential and will eventually turn out
to be excellent but currently I've found it to be very frustrating when you
actually try and use it.

To me ember-data is currently either you use it exactly as we specify and it
might work but if you attempt to do anything that even slightly deviates from
this then you're pretty much out of luck.

Firstly, it has a trivial to challenging barrier of entry depending on your
skills/environment; it requires a working ruby environment and the ability to
build ember-data from the git repo.

Then once you start using ember-data you'll most likely find yourself running
in to all sorts of problems that involve you delving into the source code to
find out what on earth is going off (no docs). Also I fell in to the trap of
assuming that ember-data should do something and trying to figure out what was
wrong with my implementation when it turns out it can't actually do that. For
example, ember-data does not automatically update hasMany collections when you
fetch a model with a corresponding belongsTo. Because of this you have to
specify every single id of the related models for your hasMany relationship in
the parent model's JSON and good luck trying to hack your way around this by
appending models to the hasMany collection yourself.

As I said though, it does appear to have promise and to be fair it does not
claim to be ready for production. However, I think it is a bit early to be
attaching words like "love" to ember-data just yet. Ember.js on the other hand
currently seems excellent and when ember-data becomes production ready I think
they'll make for a very powerful combo.

~~~
tomdale
Thank you for the detailed feedback. Working on Ember Data has been one of the
most challenging efforts of my career, but I think that it has the opportunity
to dramatically change how people write web applications. Once we've
stabilized it, of course. :)

Here are the specific steps we're taking to address your concerns:

1\. Thanks to a pull request from Stanley Stuart[1], we now automatically
publish builds of Ember Data[2] every time a new commit is pushed that passes
our suite of tests.

2\. We have begun documenting Ember Data[3] and, while not exhaustive, what we
have now is significantly better than just a little while ago. As with what
happened with Ember.js, we take documentation very seriously and you should
see the Ember Data documentation improve dramatically over time.

3\. As we outlined in a recent blog post[4], we are focused on stabilizing
Ember Data and do not have plans for new features at this time. If we made a
mistake in the initial API design, it was not providing enough imperative trap
doors to use when the declarative APIs were not sufficient. We are working on
fixing that.

Thanks to our friends at Addepar, we are able to dedicate several full days
per week to Ember Data and you should see the velocity of the project increase
significantly. Many observers have noticed the recent flurry of commit
activity[5]; this was not an aberration but an indication of what the future
holds now that we have daytime hours to dedicate to it.

If you have specific suggestions for how to make Ember Data as approachable as
possible, please let me know. Like I said, my focus right now is on
eliminating bugs, stabilizing APIs, and making sure new developers don't hit
frustrating rough spots.

1: <https://github.com/emberjs/data/pull/850>

2: [https://s3.amazonaws.com/builds.emberjs.com/ember-data-
lates...](https://s3.amazonaws.com/builds.emberjs.com/ember-data-latest.js)

3: <http://emberjs.com/guides/models/>

4: [http://emberjs.com/blog/2013/03/22/stabilizing-ember-
data.ht...](http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.html)

5: <https://github.com/emberjs/data/commits/master>

~~~
steveklabnik
I also plan on doing some work to make sure that ActiveModel::Serializers will
always work with the latest version of Ember Data. I've been spending much of
my OSS time on Resque lately, but this is in my pipeline.

~~~
sandstrom
ActiveModel::Serializers is awesome!

The convenience of having a 1:1 companion OSS package on the server-side to
hook up with an ember-app is great.

~~~
steveklabnik
Thanks! I think so too. :)

------
laureny
That's something I could have written a few months ago before discovering
Angular.js. Now, I have no reasons and no desire to go back to Ember.

~~~
adamnemecek
The main reason why I'm considering giving ember another shot is discourse
(discourse.org), which is a pretty large open-source app written in rails and
ember. Having a large app that one can reference is pretty invaluable. I'm not
aware of any larger apps written in angular.

~~~
8ig8
I can't say specifically how any of these compare in size to Discourse, but
there are a number of apps listed here:

<http://builtwith.angularjs.org/>

~~~
adamnemecek
Yeah, I'm aware of that site but most of the apps are kind of small.

------
realdope_
... So you love EmberJS because backbone was the only thing you used before
and the only thing you have to compare against?

I've used both Angular and Ember extensively, and AngularJS trounces on
EmberJS in both performance and ease of use.

~~~
Me1000
What metric are you using to compare performance?

------
jenius
Other than Ember Data, it seems like all the pieces here are things that
marionette has. I was super interested to read this, swinging more towards
marionette myself, just to get a perspective on what convinced you to change.
But there really wasn't much comparion, it seemed to just be you going over
the features of ember.

If you don't mind answering here, what made you go so strongly with ember over
marionette?

~~~
fleon
One of the major factors in the debate was community support. Marionette is
built on top of Backbone, which meant depending on support of two separate
projects. Ember.js, on the other hand is by a single developer. Kind of like
why people prefer buying Nexus phones. They are the first ones to officially
get updated with the latest Android version. Others might take months before
the handset manufacturer decides to update them.

Also, we were certain that we needed view hierarchies, and Marionette provided
them too. Back in the day though, it was still in its early stages, and we
couldn't really count on it. "What if an API change broke our app with the
next upgrade?" we thought. Ember.js on the other hand was pretty much frozen
and as in a 1.0 pre2 version. Also, there were many options available,
Backbone+Marionette or Backbone+Thorax? It was confusing.

------
combataircraft

      - How fast is your app?
      - How productive is your team?
      - How productive is Ember community?
      - How many Ember libraries do exist in Github?
      - How many JavaScript libraries exist in NPM?
      - How many of the NPM libraries can be used in client-side?
      - How robust is to manage Ember dependencies?
      - How simple is to manage Ember dependencies?
      - How easy is to debug an Ember app?
      - Do you set break points ?
      - How easy is to hunt memory leaks in an Ember app?
      - What package manager do you use?
      - What else libraries do you use?
      - Does your code integrate with other code written using Streams, EventEmitters etc?
      - How would you reuse Ember in your backend code?
      - How replaceable is your code?
      - How large is your code?
      - Is using large frameworks a best practice in JS community?
      - Have you seen alternatives like components http://github.com/component ?

~~~
tomdale
I'm glad that, unlike the previous comment thread, you decided not to refer to
Ember as "the North Korea of the JavaScript world."

However, what you're doing here might best be described as presenting a series
of "loaded questions." You can find out more about this logical fallacy here:
<https://yourlogicalfallacyis.com/loaded-question>

I'm sorry that you feel the need to attack Ember. If you have any specific
complaints, maybe we could discuss them over a beer?

~~~
moe
He does have a point though (the NK reference is hilarious because it's
actually not completely off-base, albeit a little over the top).

I looked at Ember again the other day after a long abstinence and to me it has
become frighteningly opaque. Even with my prior Ember-knowledge (before Router
and {{outlet}} existed in their current form) I completely failed to make
sense of a recent tutorial[1].

I wanted to wire the tutorial up with ember-data and add pagination (nothing
too fancy), but a series of undecipherable exceptions stopped me in my tracks
before I got either working.

A major problem for me was how everything in the "new" Ember is tightly
coupled. No longer can I just make an ArrayController, reference it in my
template and populate it with standard javascript until I'm ready to drink
more of the kool-aid. Or perhaps I _can_ , but it seems to be an anti-pattern
now. None of the (few) newer tutorials does anything like that.

It seems I'm now supposed to jump in head-first. I'm supposed to understand
all of Ember before using Ember.

Sadly that didn't work out for me, even despite knowing a bit of Ember
already. I was constantly stopped by opaque exceptions from the "runloop"
which didn't even point to a line of _my_ code. Tracking those down is a Royal
Pain In The Ass.

At one point I had enough and just wanted to drop back to "old-style" Ember
(who needs a Router anyway!) but quickly gave up on that, too, when it didn't
work right away and I realized I'd be completely on my own in that style
anyway.

So, from my short (but _second_ ) endeavor with Ember I have to conclude that
you seem to have turned the learning curve into a perfect square-wave. Every
time I made a mistake (even as much as a typo) the useless error messages
threw me back a mile. It took only a few of these cycles before I gave up in
frustration.

I think you're on a dangerous track here. When I compare my first contact with
Ember (about a year ago) with my recent experience then it feels like you're
about to re-invent Sproutcore. If my memory serves me right Sproutcore was
pretty awesome and powerful, but so opaque and unapproachable that nobody
ended up using it.

I really hope this doesn't happen to Ember. I hope you're going to modularize
it so newbies stand a chance to _start small_ instead of being bombarded with
meaningless exceptions from all directions at once. I hope you'll add
narrative guides with little "run" buttons to augment the Reference
Documentation that you accidentally filed under "Guides".

I hope you'll try to be more jQuery and less Dojo. More Sinatra, less Rails.
More library, less framework.

In short, I hope my next attempt at Ember will be more like the first and less
like my last weekend.

[1] [http://twbrandt.github.io/2013/02/11/Ember-
Quick_Start_Guide...](http://twbrandt.github.io/2013/02/11/Ember-
Quick_Start_Guide/)

~~~
redeemedfadi
I had almost the exact same experience. I originally used Ember 0.9.5 for an
app and it worked very well. When I moved to 1.0.0-pre I felt that I had to
completely relearn everything.

+1 on trying to track down errors. They never point to a line of user code!
It's extremely frustrating when something breaks and you have no idea why.

~~~
combataircraft
We all are gonna be arrested by the Ember officers soon for this attacks.

------
gphreak
Good read, I'm a sucker for those love it/hate it posts.

Still being in the process of playing around with Ember and I really want to
like it, but my mine gripe is still the documentation. Take for example the
linkTo helper which I wanted to use with the Twitter Bootstrap navigation. I
found a few examples on how this could be done, but no API documentation for
the helper? The Ember.LinkView documentation does not really help as well.

Maybe I'm blind or just too inexperienced with Ember.Js Views, but something
like that really puts me off.

------
Skoofoo
I really wanted to like Ember.js, but I had difficulties writing tests for my
app and there isn't substantial documentation for it, which was a deal breaker
for me.

~~~
tillk
This.

We're using emberjs right now as well. But the lack of test integration is a
huge problem for us. We right some tests with busterjs currently, but none of
these tests are unit tests and tell us what exactly went wrong — somewhere.

So not to mis-read my comment: our application works and we deployed to
production, and it's being used by customers, etc.. But whenver we need to
dive into an emberjs-specific issue (e.g. we had a few regressions to fix
which were introduced with the RCs) it gets messy.

If anything, the lack of testing (and currently lack of ideas how to integrate
any) is the number one reason why I don't want to use emberjs again any time
soon.

ember-data seems fine for us. Lots of conventions to adhere to (otherwise it's
no fun at all). Once you figure out the side-loading, you're fine. We had to
write a custom adapter so we don't have to repeat the things they call REST on
the server.

But that part is solid and seems to work. :)

~~~
ekidd
A big fraction of the Ember community uses ember-rails, and tests using
standard Rails tools.

For those of us not using Rails, here's a jsFiddle that shows how to test an
Ember.js application: <http://jsfiddle.net/ekidd/hCsws/>

This includes both unit tests (for models, views and controllers) and full
integration tests (using jQuery and chai-jquery to drive the GUI). There are
one or two rough edges, which are documented, and which I plan to submit bugs
about soon.

------
ldn_tech_exec1
This is great insight, thanks.

------
pdog
What are some of the differences between Ember.js and AngularJS?

~~~
mcrittenden
[http://www.quora.com/Ember-js/Which-one-of-angular-js-and-
em...](http://www.quora.com/Ember-js/Which-one-of-angular-js-and-ember-js-is-
the-better-choice#)

<https://news.ycombinator.com/item?id=4147035>

