
Why we're moving away from Ember.js - pauldix
https://errplane.com/blog/why-we-are-moving-away-from-emberjs
======
MrMcDowall
I've been using Ember for nearly two months to build a product. Every day I've
been writing Ember code and learning, and making plenty of mistakes. I've
loved every minute of it.

To be clear, I was a huge Ember skeptic last year. I've lived through the
Microsoft WPF and Silverlight attempts to bring bindings and all that goodness
to developers before, and then watch them make it so complex and poorly
documented that no one used it, and they died except on banking LOB apps. I
worried that the same would be true of Ember.

So I started to give it a crack of the whip, and really use it to build an
ambitious (at least for me) product. Yes, it's been tough, and yes at the
moment there is an almost Wittgenstein-esque 'throw the ladder away once you
have climbed it', but I've never felt so productive with a product that looks
and works really well. My conversion came when I finally had something click,
was able to start removing bunches of code and lean on Ember to co-ordinate
almost everything.

I recently had a run-in with Ember Data that left me really frustrated, and
now (today even) I'm re-learning and checking my assumptions and to be honest,
I think the problem was my understanding and not Ember Data. That said, it is
clearly marked DNUIP, so if you do use it in production, you should be
prepared for a bumpy road.

------
EvilTrout
Discourse doesn't use ember data and it has been an absolute pleasure to code
in EmberJS. I think a lot of people don't realize just how simple it is to
create an Ember object from an AJAX call and start using it. A finder is
usually as simple as:

$.get("/user/eviltrout.json").then(function(json) {
Discourse.User.create(json) });

I'll probably end up writing up an AJAX tutorial because I think a lot of
people are underestimating just how simple it is.

~~~
psycr
This is our strategy as well at Uniiverse. This is also an effective way of
ensuring that data is in sync, should that be a requirement in a particular
state. Just attach the call on State.enter() and you're good to go.

~~~
terbanator
We use this strategy also. In setupController functions, (of your routes), we
typically run fetches and fill content of our controllers. Why does everyone
get hung up on Ember-data?

~~~
ulisesrmzroche
How are ya'll caching your stuff? Sounds like all that is doing is just making
fresh requests for every route.

~~~
psycr
The Controller. Then you can do a quick check to see if
`someControllerForState.hasData()`.

------
troygoode
Ember being impressive but not yet ready for prime time seems to be a common
refrain on HN these days, and one of the big gaps holding Ember back appears
to be Ember.Data. I have no doubt the team is working hard to improve
Ember.Data and move it into "ready for prime time" territory, but why move
Ember-proper to a "1.0" release without Ember.Data also being ready? Every
major competitor to Ember (including its predecessor, SproutCore) has a data
layer that does more than pass the buck off to jQuery. Yes, the move to 1.0
locked the non-Ember.Data portions of the API, but it seems short-sighted to
believe that that will be enough for most users.

The "1.0" is communicating a set of implicit expectations that I suspect the
core team didn't intend for it to quite yet. It was a mistake to "release"
Ember itself as a 1.0 before Ember.Data was ready.

~~~
wycats
> Every major competitor to Ember (including its predecessor, SproutCore) has
> a data layer that does more than pass the buck off to jQuery

SproutCore had a robust data layer, but 2013-era frameworks mostly expose HTTP
directly as the abstraction to use, either via $.ajax or a framework-specific
HTTP library. Other frameworks are not trying to solve data persistence and
loading beyond delegating to HTTP, but Ember's solution isn't ready yet (so we
don't get to say that it's a win of using Ember over the competition -- yet).

~~~
coolsunglasses
>Other frameworks are not trying to solve data persistence and loading beyond
delegating to HTTP

I don't think that's true, given how Backbone and Angular are designed.

~~~
steveklabnik
I'm not an expert in JS frameworks, but my understanding is that backbone
converts 'save this model' to '{PUT,PATCH} /models/:id', and then makes the
request.

Isn't that just delegating to HTTP?

~~~
coolsunglasses
I'm not sure how Ember Data is different beyond providing a smarter interface
to collections and models than BackBone.

~~~
steveklabnik
Hence 'not ready yet.'

------
ebbv
I am working on a meeting agenda site which is all a JavaScript app talking to
a backend API (Node) which hands out JSON in response. The project seemed
simple enough to me that I felt like learning Ember, Backbone, etc. might take
longer than it was worth.

So I solved some of these issues myself with rather simple solutions/brute
force. For example the navigation issue; mine is a single page app. To handle
reloads I am storing a cookie with what page the user was last on and any
appropriate object ids to know what to load from the API. If they come back to
the app at any point before closing their browser, it remembers exactly where
they were and returns them there. That of course works for Refresh as well.

As for being able to link to a point inside the app from outside, that's what
location.hash is for. For pages users need to be able to link other people to
(in my case, the page where you view the agenda and can write minutes, etc.),
I update the location.hash to one that if clicked on will send them there (and
takes precedence over the cookies.) Granted it's not super elegant, but it
works.

I've found that my single page app is remarkably fast even on a slow, old
computer. I'm really happy with it. Starting out I was a little worried it
might get unmanageable (and it may yet) but at this point I have a large
majority of the functionality I wanted and it's still quite manageable.

------
allenc
Hi, I'm the lead Square Dashboard engineer at Square, and the one who wrote
that blog post a year ago on building our app in Ember and D3.

I'll say that after a year's worth of experience with Ember, we've gotten much
better at it, but we've still had to add our own components (e.g., a
validation framework) or fork off what components and use + fix them before
they're completely production ready. We accepted these tasks as a cost of
living on the bleeding edge, but admittedly given the rapid pace that the API
has changed in the past year, we've acculumated a bit of necessary tech debt.

W.r.t. Ember Data, that wasn't a consideration for us, as the component didn't
exist when we were building Dashboard. That said, we chose to integrate with
ED in one of our more recent features, and while I'd be lying if I said there
weren't any pain, what we took away were learnings about how our non-ED models
related to each other and informed subsequent refactors that made the overall
app better.

------
andrzejkrzywda
We all expect to find a Rails/Django equivalent for JavaScript apps.

There's nothing like that.

All of the JavaScript frameworks are in their infancy. It doesn't mean we
can't use them yet. It's just that they are not mature enough to be easy to
use.

~~~
jitl
The original SproutCore was pretty close to rails-level usability. At least,
it helped frame up controllers and views with a handy tool.

------
bcardarella
We are going full-in on Ember at my consultancy, DockYard. I've been a big fan
of the organization and the possibility of the framework. I've been developing
in Rails and for me Ember has the most common-sense choices for building
larget-scale complex client side apps. The framework is such that building
abstractions on top of Ember is very nice. (for example my form builder
library: <https://github.com/dockyard/ember-easyform>)

I do feel the pain of Ember-Data at times but the bad rep it is getting is not
valid, this is pre-release software we're talking about. There are people
(like us) "living on the edge" and working around the difficult sections of
ember-data but there is a great plan in place to move ember-data forward:
<https://gist.github.com/stefanpenner/9ccb0503e451a9792ed0>

------
steveklabnik
ActiveModel::Serializers maintainer here.

We've been working closely with Discourse (which is currently running edge
AMS) to make sure we have the easiest and best way to get data from your Ruby
web framework into shape so that it's easily consumed by any JS framework, not
just Ember.

It's important to get all of this stuff right: the seam in the middle is where
your SPA talks to the back-end, and provides the ability to, for example, have
two different teams work on each side without worrying as much about the
format, or possibly even writing a new back-end without affecting the client
side.

Feedback and comments very welcome: [https://github.com/rails-
api/active_model_serializers/issues...](https://github.com/rails-
api/active_model_serializers/issues/) for bugs and
<https://groups.google.com/forum/#!forum/rails-api-core> for feature requests
and discussion.

------
ekidd
I've been treating Ember-Data very cautiously, and feeding it carefully
prepared data. The biggest irritations involve multi-record commits and
validation/error handling. But it's working well enough for my straightforward
needs. Still, don't touch it unless you like reading the source, and you're
willing to use something that's marked "NOT PRODUCTION READY".

The Ember.js tutorial situation is abominable, but I see two or three new
tutorials are out in the last two weeks. And after much head-scratching, I
finally figured out what's up with Routes vs. Controllers vs. Views.

Keeping all those caveats very firmly in mind, I'm really happy to be using
Ember. My code is lot cleaner than that of my previous web apps, and features
are getting done fast.

When it hits 1.0 (including Ember-Data!), I think it's going to be one of
several excellent choices.

~~~
dageshi
Yeah, I know nothing about ember.js, can anyone point my in the direction of a
tutorial or a simple example app so I can get my head around it?

------
lsdafjklsd
I am an illustrator, turned front end developer, turned "just get it done"
rails developer. I am currently working on a basic forum for a website that is
100% Ember powered.

Before finding Ember, I created "islands of richness" with Backbone.js. What
was frustrating for me was my own lack of software engineering skills. I would
design these hard to maintain apps that were just an absolute mess at the end.
Like Rails, Ember opened this world of application development that has been
such an absolute thrill to get into. It teaches me good practices, you
instantly feel when you're doing something wrong.

I have been working with Ember every day for the past two months, and yea
there are times that I get lost and it's frustrating, like struggling with
complex forms in Rails for the first time, but you eventually move past it and
the feeling is gratifying. I'm not the best dev in the world, but Ember has
shifted my vision on what I can create completely, and I am really excited for
the first time in a while.

For me, Ember isn't just a framework, I find myself using the Ember runtime
everywhere. Where I used to take Backbone models and collections, I know take
Ember core - even in a Node environment.

I really appreciate what Tom and Yehuda have done as well as the rest of the
community. It has me excited to create in this new way I had not been able to
before.

------
STRML
His complaints about the router also plague Backbone apps - how do you cleanly
deal with users reaching the route through your app, and users navigating to a
route directly?

I have had some luck with Backbone.routes
(<http://siong1987.com/posts/introducting-backbone-routes/>) but it is still
not quite where I want it to be.

~~~
andrzejkrzywda
Think of the router as the "main" method of your application. It's passing you
the initial arguments. You just parse it and run the correct logic and/or
display the view that is required.

~~~
tomsthumb
That's a pretty handy shift in perspective.

------
wesleyworkman
We've been using Ember in our production environment for nearly a year now.
There are lots of plus' and some minus', but I'd like to take a few minutes to
share our experience.

We picked up Ember 0.8 in March of last year. Having some prior SproutCore
experience it was a pretty easy thing to get going with. Back in those days,
Ember was pretty nonconventional, there was a right way and a wrong way to do
things, but the framework didn't really enforce a strong point of view. This
was really good and really bad at the exact same time. The good was there was
a much lower learning curve. The bad was it was so easy to head down the wrong
path and shoot yourself in the foot.

I think in the summer of last year, just after Ember 0.9.8 was released, many
of the core team members started to explore some the criticism and problems
with the framework at the time. The end conclusion, from my view, was to
restructure the architecture of the framework. The pieces were the same, but
they fit together differently. The biggest of these changes was with the
introduction of the strong router conventions. In addition, there we're major
changes to the default template context, view hierarchy, runtime and metal,
among others. IMHO this was the first time Ember really expressed a strongly
enforced convention through the framework.

Fast forwarding to today. Ember has a lot of concepts that people have spent
months and months working on. I can sit here and endlessly explain why how the
router's pattern makes your application more flexible, or how the template
patterns make for easy reuse, etc etc etc. But the truth is you won't really
appreciate them until you've given Ember a fair shake.

EDIT: A fair shake doesn't mean picking it up on a weekend. A fair shake means
trying to build a reasonable size application with it. Spending a two or three
weeks. It has a big learning curve, but that doesn't mean it isn't valuable.

------
ryanflorence
This post is titled wrong:

 _> I'm not yet ready to leave my server-side framework behind_

That is the right title, pulled from the concluding paragraph.

This sentiment happens to apply to angular, backbone, knockout and everybody
else.

The first thing I ever programmed was a single-page web app built with
MooTools 5 years ago. Its still the most impressive application I've built and
people ooh and ahh over it to this day (which is sad, since I was clueless).

When I think about all the JS I've written from then to now, nothing has the
promise that ember + ember-data do. My ember code is so straightforward,
declarative, and minimal.

Perhaps I haven't gone as deep as the author with ember, but when you pick a
framework that is very openly pre-release software, and you're already
apprehensive about "asynchronous data" (welcome to the web?) don't expect much
success.

------
tytyty
My company moved away from ember-data recently in favor of our own simplified
replacement. I like the concept of ember-data but we just ended up fighting
with it more than we'd like.

It's a bad idea if you go into ember expecting it to be a solution to all of
the javascript development hurdles. You should expect to fight the framework
from time to time. You should expect a learning curve.

The solution is to be a patient developer, become familiar with the ember code
base and it's concepts, keep up to date on the community happenings.

We are more than ecstatic about the results of our nearly complete product and
I am positive having used any other framework would have made our development
more difficult, and without a framework would have taken multitudes longer.

------
outside1234
I used to hate doing frontend work because of all the gruntwork: Now I love
it. I used to hate javascript: Now I love it.

I attribute a lot of that to structure and grunt-work-handling of Ember.js.

I can't go back. Ember.js might not be where we end up in terms of the SPA
framework we end up using (but if I were betting I'd say yes), but in general
this is where web apps are going.

------
clintjhill
I wish there was more information about "where" they're going now. They imply
that it's not Ember that's broken rather Ember isn't done and the problems are
hard that Ember is trying to solve. So I'd ask - why not stay with Ember and
help solve the hard problems? Or did you find another technology that "solved"
it?

~~~
toddpersen
Those are both good questions. Currently, we're a team of two trying to
maintain and evolve a production application. Believe me, we'd both love to
have spent more time pushing the ball forward on Ember Data, but it just
wasn't feasible. Besides, it's already on a maturation path that will resolve
all of the issues before long - it just needs a little more time.

In the meantime, we're just keeping it simple and making magic with D3 and
plain jQuery. We pushed all of the CRUD back to Rails, which is probably where
it should have been in the first place.

Regardless, it was a great learning experience. I still highly recommend
giving Ember a shot on something that's not on a tight deadline to get
deployed to production.

------
devinus
The great thing about Ember is that it is NOT all all-or-nothing proposition.
We have several apps that don't use Ember Data or the router, several that
don't use one of the two, and some that use both.

------
codereflection
Well it says right on GitHub, "Is It "Production Ready™"?" - "No. The API
should not be considered stable until 1.0."

<https://github.com/emberjs/data>

------
seilund
Ember.js is as close to being finished as it can. We have a really large app
under development, using Ember.js. It works so well. Better than anything I've
ever used (and I've made single page Javascript apps since way before it was
cool). Development is fast and fun. Often I sit back with a feeling like "Was
that all that I had to do to make this work??". The performance is good, if
not great. Ember cleans up everything it creates itself, which makes it very
simple to make advanced apps that are easy on browser memory consumption.

It seems like Ember Data (and documentation, which is an easy problem to
solve) is currently the only achilles heel of the whole Ember. But PLEASE
don't judge Ember.js based on a pre-alpha version of an add-on library. There
is no sense in that. Ember Data will receive its glory once it's done. Anybody
who's every implemented a data persistence layer can tell you that it's not a
trivial problem to solve.

Conclusion: Ember.js IS awesome. I love it. A lot of people love it. If you
don't like it, then fine. Don't hate on it for no reason. I don't like
cauliflower (I hate it), but I don't hate on people who eat it. I admire that
they want to be healthy.

------
lukenyc
Yapp is built on Ember and it has been a joy. Terrific community and a lovely
layered design that lets you work at the level of abstraction appropriate to
the interaction you are building. We have ember-data in production in
selective places, and it definitely has a ways to go to deliver on its full
promise. That said, you can't really build an ambitious app without some
model/persistence concepts, or without an identity map, so it is a big win for
that already.

The common refrain that I hear talking to people in NYC and the wider internet
world is that people _want_ Ember what Ember promises and has begun to
deliver. More and more of those folks (including my team) are rolling up their
sleeves to help make it fulfill its promise.

------
darthdeus
I've been using Ember Data in all of my applications so far, two of them are
in production, another one will be very soon.

Yes there are some rough corners and the documentation is really not that
great, but that's something you have to expect from a pre 1.0 release,
especially in the case of Data where it's clearly stated that it's unfinished.

The "problem" with Ember is that it's nothing like Backbone, and Ember Data is
nothing like $.ajax. It is no surprise that Ember makes you do things a
certain way, which is different than most people are used to.

This sometimes leads to thinking that "Ember is broken", but in reality most
of the times you're just doing it wrong. I'm not saying that everything is
rainbows and unicorns. I'm not even saying that Ember is easy, there's a
pretty steep learning curve.

What I'm saying is that once you get past a certain point, most of the issues
will just disappear, because you'll know why things "appear to be wrong" and
how to fix them :)

I really don't think there's any good alternative to Ember right now, and if
you're not satisfied with Ember Data, go ahead and use $.ajax. Discourse does
it and it works great for them.

------
rohandey
I like Ember over Backbone as it follows C over C which I found missing
completely in Backbone. Though I feel that client side MVC have a serious case
to use across all projects if file uploading and multi model support is
seamless. File uploading hacks actually stops me from using it in major
projects of mine.

~~~
jcromartie
Convention over configuration is fine until all you need is a little
configuration, at which point it becomes a game of hunting down where the
magic comes from and how to override it, because nobody thought that anybody
would need anything other than the conventional approach, and so they didn't
document how to configure it, and then your code turns into a bunch of
workarounds.

I think Backbone is pretty aligned with this philosophy:
<http://www.python.org/dev/peps/pep-0020/>

------
ibrahima
I've played around with Bootstrap and didn't like the idea of trying to
replicate MVC on the client. Like the article said, I'm not yet ready to move
away from server side frameworks for the most part. However, I like the data
binding style of programming a rich client UI and I've actually found that
Knockout.js is really nice for just doing that part. Does this seem
reasonable? Would I gain anything by moving to Ember to do the same thing?

------
jamesinsf
Nice informative article. People are always trying to go to the extreme with
javascript and they should realize that its good to practice application
development in moderation. Trying to heavily front-load an application almost
always get you in the end, and its just taking a step backwards in application
development. And especially so when dealing browser compatibility and JS.

Balance the front end and back end application development people!

------
sync
I also started out using Ember.Data and later abandoned it due to similar
issues (lack of validations being the biggest), but have stuck with Ember.js
itself and am really enjoying it for a basic CRUD app.

Entering a route through a user hitting it directly vs. transitioning within
the app should not be a problem with Ember.js, everything seems to just work
for me at least. I suspect this is an education thing more than anything else.

------
combataircraft
Let me give you one reason to stop this bullshit: No Ember code is
replaceable, can work together / integrate with any modern JavaScript code
like over 30.000 NPM modules. It is the North Korea of the JavaScript world.

~~~
tomdale
Your comment history indicates that this is a troll account, but I'll reply in
case a bystander takes your post seriously:

Ember is actually composed of many smaller, independent packages. For example,
we built four microlibraries for use in Ember that you can use totally
independently: router.js, route-recognizer.js, rsvp.js and metamorph.js.

Additionally, many people use other great projects from the JavaScript
ecosystem to do Ember development, like D3, Crossfilter, mocha, Jasmine, etc.
Your assertion that it does not work together or integrate with other tools is
100% false.

~~~
combataircraft
If my assertion is false,

\- Where is one single Ember example re-using an NPM module by one of the
brilliant & profilic authors producing high quality libraries, such as
substack, visionmedia etc. ?

\- Where is one single Ember example that can be required by a CommonJS
project?

\- Where is one single Ember module in NPM registry?

Sorry for trolling.

------
jm3
It would be helpful if some of you could share links to the production Ember
apps you're working on.

------
blissofbeing
Totally agree.

