

Reasons to not use Ember.js - aokolish
http://aokolish.me/blog/2014/11/16/8-reasons-i-won%27t-be-choosing-ember.js-for-my-next-app/

======
pookieinc
Haven't used Ember.js myself (though have been wanting to for quite some
time). This struck a cord with me though:

> 8\. JavaScript

> Writing most of your app in JavaScript is simly[sic] not fun. JavaScript is
> known for being designed in 10 days. Ruby is known for being designed for
> developer happiness - which sounds better to you? \---------

I don't think it's fair to compare Ruby and JavaScript because they are
fundamentally used for different problems. You can never write Ruby for
client-side, so why is it being compared? You have to use JavaScript (or
CoffeeScript, or what have you), therefore you use it to get the job done.

In essence, complaining why use JavaScript is not a fair reason against Ember.
It's more of a reason for: "Why go with a client-side JS framework in
general", rather than specifically Ember. This was the only point I wanted to
make regarding the article.

Aside from that, I definitely appreciate the learning and will take these
reasons into consideration if/when I decide to use Ember.js. Hopefully one of
the core team members can explain more about the other reasons mentioned.

------
stepstep
I've had better experience with Angular, though some of the complaints apply
to Angular too (e.g., silent errors in templates). Recently I started using
Facebook's React framework, and so far it's worked well for me. You'll
probably end up writing more code than you would in Angular/Ember, but that's
because React is only a view framework (so it frees you up to use vanilla
JavaScript for other things, like ajax, routing, etc.). React is also much
faster than Angular because of its virtual DOM patching technique.

But my favorite part of React so far is that view logic is grouped together
with the views. This goes against the "best practice" of separating views and
logic, but I think it makes navigating the codebase easier. You want to learn
everything about how some custom view widget works? It's all in one file,
rather than spread across app/assets/javascripts/widget.js and
app/views/widgets/widget.html.erb. No directory hopping needed to learn how
the widget works.

------
prezjordan
I am shocked how highly this is rated on here. You used Ember for the first
time and thought you moved slower? That is...expected. It's called a learning
curve. The first time I wrote a Rails app I worked much slower than writing
Sinatra.

How old is this post? Google search for "Ember pagination"
[https://www.google.com/webhp?sourceid=chrome-
instant&ion=1&e...](https://www.google.com/webhp?sourceid=chrome-
instant&ion=1&espv=2&ie=UTF-8#q=ember%20pagination)

The graph? I'm surprised you didn't break "Ember Template" into "Regular
Expressions", "String Concatenation", and "Returning Variables" to further
your point. Why does "Rails" have one box?

I really hope I'm not missing some joke and making a fool out of myself right
now.

~~~
kitwalker12
he did work on it for 3 months. I haven't used ember but that seems to be a
lot of learning curve.

~~~
aokolish
Sorry, I was unclear in the post. Building the dashboard took about 3 months.
We then add features to it, and maintained it for 5 months after that.

------
tomhallett
The diagram comparing the stacks feels pretty unfair to me. You have one box
for "rails", but then break apart ember's stack into "models", "controllers",
"routes", etc. a similar diagram could be drawn for activerecord,
actioncontroller, etc - right?

~~~
sotirisk
What difference would it make? The Rails box is the same for both columns. He
could have ommitted it and just add a generic "backend framework" box with the
results being the same.

------
fineline
This is an architecture preference disguised as a tool review. It should be
called "Reasons why I don't like client-side web programming and prefer to
work with server-side logic".

~~~
charlysisto
The title and some of the critics are unfortunate but this post nevertheless
is hitting a soft spot for me. I've been through backbone & angular and I'm
starting to question the necessity of a full blown framework when all I want
is some structured js for each page/resource.

More fundamentally it seems the offer on js libraries are either tailored to
eye-candy widgets or the big SPA. Nothing has popped in my radar as proposing
an incremental step from server side HTML to MV([A–Z]) Dom/json manipulation
which entices you to almost build the app twice.

What I'd really like to see rather than a client-side-solution is a
server/client migration path from html to spa without being tide to one or the
other

The links he included (see below) bring up the same concerns....

[http://mir.aculo.us/2013/02/26/client-side-mvc-is-not-a-
silv...](http://mir.aculo.us/2013/02/26/client-side-mvc-is-not-a-silver-
bullet/)

[http://www.shopify.com/technology/15646068-rebuilding-the-
sh...](http://www.shopify.com/technology/15646068-rebuilding-the-shopify-
admin-improving-developer-productivity-by-deleting-28-000-lines-of-javascript)

------
Osiris
> Our development speed was about 1/3 of what it would have been with normal
> rails development.

How much experience did you already have with Rails? I would expect that
learning a new tool would take longer than using one you are already
intimately familiar with.

> Additionally, using Ember really increased the layers in our stack.

I don't think this is that much different than Angular.js. That would also add
a significant number of components to the stack.

> Writing most of your app in JavaScript is simly not fun.

Typos aside, this is hardly a downside of Ember.js. I work in JavaScript full
time (node.js), and while it has its gotchas, I really appreciate the
functional nature of the language. I was writing some C# yesterday and I was
disappointed at how hard it was to do function passing and function
composition compared to JavaScript.

It's good for the Ember.js ecosystem to understand the short comings of the
framework, but I don't think it's particularly useful to say "Don't use this
tool because...". The fact that people DO use the tool means that some people
do find value in it.

One of the complaints is that there isn't enough sample code posted, yet this
post didn't provide any sample code of their issue or their solutions. Doing
that would add more value than just saying "Don't use Ember."

------
pyre
> Deep linking - unreliable

The deep-linking example comes across to me as an issue of setting up initial
state. Loading those other routes first either loads data or modifies the
state of the application in a way that is required to display that route.

(or the author doesn't understand the difference between
example.com/path/to/route and example.com/#!/path/to/route, but seeing as it
"works 50% of the time" it's probably not this)

~~~
aokolish
Hi there. I omitted the hashbang just because I find it ugly.

> Loading those other routes first either loads data or modifies the state of
> the application in a way that is required to display that route

That should be a non-issue as far as I understand, because visiting a nested
route causes the parent route code to be executed first. Hence, the confusion.

~~~
pyre
Yes and no. Depends on how the routes are structured in the code. In your
example:

    
    
      /users/
      /users/15/
      /users/15/photos/
    

Your router map probably looks like this:

    
    
      App.Router.map(function() {
        this.route('index', { path: '/' });
        this.resource('users', { path: '/users' }, function () {
          this.route('index', { path: '/' });
          this.route('show', { path: '/:user_id' });
          this.route('photos', { path: '/:user_id/photos' });
        });
      });
    

This translates into a structure like:

    
    
      ApplicationRoute
        IndexRoute
        UserRoute
          UsersIndexRoute
          UserShowRoute
          UserShowPhotosRoute
    

Note how all of those Users*Route classes are all siblings rather than in
parent-child relationships. Also note that if you're sharing controllers, they
won't pass through Route.setupController on the sibling routes because those
routes aren't run.

------
iamartnez
What a terrible post.

Actually, it does have one use. If you're a recent grad or new to the
industry, pay close to attention. Don't be like this guy.

Before you envelope yourself in the comfort of frameworks and libraries, learn
how to poke around the internals and understand the underlying architecture.
Remember that these are tools written by humans just like you. They'll have
bugs. Performance problems. Maybe an edge case the creators haven't thought
of. And sometimes you'll be making the mistake.

My personal rule (YMMV) is to never adopt a framework or library unless I'm
ready to open a pull request. There are obvious exceptions like databases and
other huge projects. I'm specifically referring to small libraries and
application frameworks for this rule.

Treating frameworks and libraries as a magical-voodoo-black-box is asking for
trouble.

Moreover if you decide to write a blog post warning people not to use a
framework or library, you better have some deeper technical insight to back it
up. This is just rude.

------
smoe
Never start a real project with a deadline with a framework nobody in your
team knows. Especially if you consider the language it is written in "not
fun".

The same thing would have happend to some degree with any other choice.

E.G last year I nearly went insane doing a project with Django. Although I am
a Python developer, the framework is extremely mature and well documented …

~~~
merb
Hm... Django isn't hard. Mostly the problem is caused by using a framework.
Since you throw a tool at things which only needs like 5% of the whole
Framework. Even if it is as modular as Django/Rails etc. it's just
unnecessary. Thats why more and more Developers love tiny Frameworks/Tools
like golang/Sinatra/Flask

~~~
smoe
I totally agree with the 5%, that's why I never used Django before for a real
project and preferred Flask mostly. But for this project it made sense since
I'm using almost all of its documented features and some undocumented ones
like model swapping plus a couple of extensions.

My point was, that it doesn't have to be hard to slow you down. Whatever
framework you choose, you will get stuck at some point. A Django developer
will have starting problems with Flask, glueing together the basics and
choosing a folder/file layout (or changing it later), while for me, I had a
very quick start with django building a prototype in no time but then got
stuck a lot later on while customizing an having other opinions that the
opinionated framework.

------
bouke
It feels like the author is not familiar with JavaScript, and is taking it out
on Ember. JavaScript is a whole different environment than Ruby, not in the
least part because JavaScript provides async code-entry. Maybe that would be
causing the direct URLs to fail, as some global state is expected in the child
pages, but isn't setup yet.

------
peterhunt
I'm no ember fan, but comparing a system that talks to a transactional
database and creates html strings to one which handles low latency user
interactions and syncs state with a remote service seems disingenuous.

------
joshontheweb
I'm not personally a fan of ember but this article seems to paint it in a
pretty unfair light. In the end he reveals that he really just doesn't like
javascript so...

------
jonahx
Since a lot of the complaints here are about bloat, complexity, and the steep
learning curve, I'd recommend that anyone with similar concerns check out
Mithril:

[http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

It has a wonderfully simply design philosophy (similar to React's), can be
learned in a matter of hours, and weighs in at 5k.

------
kaushikb9
The comparison of Ember to Rails is incorrect. Rails is a serve side rendered
framework. Ember is completely client-side. Pick any client side framework and
you will face the same diffculties or obstacles. Deep linking breaks if you
are not loading depending models.

------
weatherlight
Terrible post! I'm an Angular/Rails guy myself but this guys just doesn't know
how to dig into the internals of something and figure it out. That's what
really makes an engineer an engineer.

~~~
smt88
For those of us coding for a business purpose, we don't often _want_ a library
that requires digging into the internals.

Ideally, you want something simple that saves time. But sometimes you have to
compromise and use something opaque that just gets the job done without
forcing you to understand it.

The curiosity and intellectualism that make an engineer an engineer, in your
opinion, can be toxic in a business environment. Spend a lot of time
tinkering, learning cutting-edge technology, or reinventing wheels, and your
deadline whizzes by. There's a delicate balance.

I only point these things out because, to many people, Ember.js (and many
other libraries) are time-savers rather than something we want to deeply dive
into just to use them.

------
BilalBudhani
Which version of Ember you were using? and do you experience working with
other Javascript based frameworks like Backbone, Angular, knockout etc.?

------
csallen
Interesting post. I've been using Ember on lots of projects for about a year
and a half now, and I think it's great. What this post really hits on,
however, is the fact that Ember has quite a high learning curve.

After many years of developing SPAs using plain JS/jQuery, the benefits that a
framework like Ember could provide were immediately clear to me. As a result,
I was willing to push through this curve and subsequently reap the many
rewards. For someone like the OP, however, who doesn't seem to have built many
ambitious SPAs and for whom building a traditional server-driven web app is an
option, I can understand why dealing with Ember's learning curve just doesn't
seem worth it.

For those seriously interested in trying Ember, I would advise you not to make
the mistake of confusing Ember's somewhat steep learning curve with the
quality of the framework itself.

Thoughts:

> 1\. Silent Errors.

These can definitely be annoying and difficult to debug, especially if you're
newish to Ember.

> 2\. Deep linking - unreliable.

This is probably because you're not handling your route setup properly. I ran
into lots of issues with this when I was learning Ember, and although the
guides do a better job explaining how this works nowadays, I do agree with you
that it'd be nice if there were more real-world coding examples on the web.

It's important to be aware that the "model" hook in your routes isn't always
called. When you use the {{#link-to}} helper in your templates or the
`transitionTo` method in your routes, you pass in the model directly and the
model hook is skipped. However when navigating directly to the URL, the
route's model hook is called and is expected to resolve the model using the
params from the URL.

There are also a few common gotchas that involve dealing with nested routes,
but I'd have to look at your code to see what exactly is causing your routing
issues.

> 3\. Few libraries

If you're using Ember Data (which hasn't hit 1.0 yet), I could see pagination
being somewhat of a pain in the ass. Still, I'm using Ember Data on a couple
of large projects right now, and I was able to get pagination working fine in
a couple of days.

If you're not using Ember Data, pagination shouldn't be harder with Ember than
it is with plain JS+jQuery.

> 4\. Few code examples / resources

I agree with you here. There are some good open source Ember apps that you can
learn from, but definitely not enough simple code examples online. This is one
of the reasons that the learning curve is so high.

> 5\. Slower development

Learning something new is almost always going to be slower than going with
what you know. This is especially true of Ember, which the team very
accurately bills as "a framework for creating _ambitious_ web applications"
(emphasis theirs). Ember is often overkill for a lot of the apps that people
need to build. However, if you're building something ambitious, Ember will
save you time and headache in the long run. And once you get familiar with it,
you'll be pretty speedy.

> 6\. Added layers and complexity

I think your diagram comparing a Rails+Ember stack to a Rails+jQuery stack is
totally misleading. You've simply taken everything in Ember and squished it
into "Javascript/jQuery". If you're writing a very simple front-end app or a
complex app composed of terrible jQuery spaghetti code then yeah, I guess it's
an accurate diagram. But if your front-end app is actually complex and well-
written, then you're going to have to spend a considerable amount of time
implementing some form of glue to handing routing, templating, model state,
etc on the front-end. Ember does that for you.

> 7\. It restricted our design

Ember shouldn't limit your design. It seems more likely to me that you guys
were new and unsure of how to use Ember to accomplish a specific goal. That
said, it'd be great to hear what kinds of snags you ran into, as these would
probably make for some good code examples.

> 8\. JavaScript

Ember is for developing applications in JavaScript. If you don't like writing
JavaScript-heavy apps, Ember is not for you. And that's okay. It's very often
the case that traditional server-centric applications are more than good
enough for the task at hand. But when the situation calls for building a
modern and ambitious single-page application, you're stuck with JavaScript
whether you like it or not, and I believe Ember is a great way to go.

