Why i'm leaving ember



at first ember seemed to be a great solution for development. But as a beginner in development (1,5 years) i felt more and more lost in the world of ember. Ember and Ember-Data seem to be very powerful. But it is hard to get the whole picture in how things work together. The documentation shows many details of ember, but not how they work together.

Multiple times i was stuck cause things didn´t go as expected. The good thing was though, that ember has a great community of very helpful and friendly people. So i went on the last months. But i´ve now realised, that ember doesn´t do the things the way it would seem obvious to me.

I´ve started with a full-stack framework (not sure if i should name it here) and in about 2 weeks i´m at a point which took me over 4 months with ember.

This post is not to make look ember bad (probably it is more my lack of experience) but to give feedback.



This is a fair issue- I think Ember is a little rough for beginners, and I don’t know that there’s an easy way to fix that. Getting up to speed is dependent on knowing not only programming concepts, javascript syntax and a bit of jQuery, but some architecture concepts and design patterns like MVC, getters/setters, pub/sub, and separation of concerns. Furthermore, even a medium-sized project will require some understanding of build tools and asset pipelines. Lastly, a lot of the good stuff is a work in progress, so you have to have some comfort level regularly reading release notes and participating in forums or IRC. Frameworks like Angular and Backbone ask much, much less of you and I don’t think anyone has disputed that it’s faster to get started in them.

Ember’s advantage is that you consistently encouraged to do things in the most architecturally sound way. It makes adding new features, pivoting, troubleshooting, and scaling easier by factors over any alternative.

The advantage of non-opinionated frameworks is that you can build stuff exactly how you always have, just a little faster. The downside of this is that an “angular app” could mean just about anything, and the skills you use on one project have a good chance of not transferring to the next one. Contrast this with Ember (especially a CLI project)- unless the developer went to an effort to conceal their intent, I can probably figure out everything I need to know about their app with a quick look at the code- no comments necessary. This means developers are easy to add to a team, and 3 years from now it shouldn’t be difficult to patch something (no “I think this was from around the time Jerry was into giving each function its own file, so…”).

For your situation in particular, the most important thing is to produce working software. If that’s not happening with Ember and it is with some other approach, absolutely no one will fault you for switching. You may want to check back with us in a couple years though- Ember has some serious magic waiting for you when the time is right.


I’m a similar case, most definitely new to development and find the documentation extremely difficult to get exactly what I need out of it. Similar to the aforementioned perspective, I did try a bit with Meteor. There is a lot to like about Meteor, but it may be because I am so invested with Ember already, I have stuck with it. Quite frankly, I am not a hater or lover either way. Rather I am somebody who loves efficient solutions.

I am not a hard core developer. Likely I never will be. As a result, I am extremely excited to see the rise of so many extremely robust and viable frameworks making it possible for people like me to create solutions. Slap together a little Ember.js + Bootstrap frontend with a MongoDB + Node.js + Mongoose + Express backed and wow…I can actually (try) to build stuff. If you are a tater head who instead of Computer Science got a degree in Parks, Recreation and Tourism, this is pretty exciting stuff!


I’ve found that if you’re new to web development or programming in general, you’re likely to have a better time picking up any JS framework than if you’re already an intermediate or advanced developer. So it’s a good idea to just empty your cup and learn to love the dark (client) side.

Routing is a good example, in Ember, most of your business logic will end up in your routes, and is tied to application state so you can be far more liberal and creative with them. They mostly depend on your UX, so there are no real guidelines, in fact, as long as it looks and feels good, I suppose that’s the right way to do it.

In something server-side, you’re essentially tied to REST, so your routes become very rigid, state-less, and reduced to little more than a hook.


Ember is tough, even if you have been a dev for a long time. I find the idea of putting logic into routes hectic. Some of the ideas I am used to like IOC surface differently in ember but once it clicks it clicks. The fact I needed to get to grips with all these new concepts like grunt and the way ember cli works, the conventions used etc, it’s not easy but when it clicks it clicks. Some of the “magic” is confusing too - I’m used to being explicit about everything. I’ve only been using ember for a week and so far I’ve managed to pick the discourse header apart, reverse engineered it, isolated it in my own project, wired it up to my own api ( to extend the search feature for instance) and I’m now moving on to the rest of my app which we’re integrating into discourse. I’m yet to play about with the BDD testing stuff but it looks immense. The community seem patient and informed and I’ve found a degree of success because of this. It’s a rough ride but I’ve found it worth while.


Perhaps this is related to your experience level and the technology stack you came from. I came from a background of Java, Flex, then Sencha. My experience with Ember is completely opposite to what most people have. I have found that Ember is a lot easier to understand than Angular.


same here and a lot more empowering, there’s nothing out there that gives me that ease of use and power


I’ve been doing back-end programming in Perl for well over a decade – used a couple of frameworks for that, and I’m quite familiar with JavaScript and front- and back-end integration. For my recent personal projects I’ve mostly used JavaScript.

I can say that I don’t strictly find Ember easy all the time (working on quite an ambitious app with a Firebase driven back-end and it’s sometimes tricky to figure out how to achieve something), but I do agree with pretty much all the design choices that have been made, and much of it makes perfect sense. It basically gives me the MVC I’m used to doing on the back-end, but on the front-end instead. I thoroughly enjoy working with Ember, even if sometimes I have to plough through pages of documentation. And ember-cli is brilliant, I’d probably have a much harder time without it.


Thanks @tellsapfel for sharing your experience. Maybe you’ll find another tool you like better, and maybe some day you’ll try Ember again after both Ember and your experience have continued to evolve.

Your post is related to one of the most important questions in programming: how can we close the gap between beginners and experienced programmers so they can work together and learn from each other.

We experienced programmers often do a bad job of understanding what it’s like to be a beginner. We still struggle constantly, but we struggle with different problems and we forget that beginners haven’t even discovered those problems yet. So we often talk past each other.

Ars longa, vita brevis.

I would encourage all experienced programmers to spend some time coaching raw beginners in coding. You will learn a lot.


Well said @ef4, I’ve been doing this and helping people getting into Ember by offering a free hour of pairing every week to anyone, is not a lot of time since I have other commitments but it has helped me to figure it out where people is struggling and how we can help them.

If anyone reads this and you are having a bad time with Ember feel free to reach me through my blog http://blog.abuiles.com/ (check the section free pairing for details).


I have been working in development for the last few years and I agree ember is pretty hard to just get up and go with, I decided to use it for a new project in work, and well compared to what I was using before ( jQuery on its own ) things get put together so much faster, and in a much nicer structure. I have found at times some of the docs leave out important details, showing parts of things but not the whole process. Either way I am still finding learning ember rewarding and fun ( though my boss may currently be disagreeing a little ahhaha ) I think the payout will be worth it in the end. Sad to see anyone give up on things, but its about what works for you! Kinda nice to know other people are just as befuddled as me to begin with!


Would agree with the general consensus that starting out can be steep. The general issue I found with docs is that there is no continuation. While there is a lot of docs (which weirdly actually makes it worse since the small bits you need are split out over multiple pages instead of 1 or two paragraphs), it’s not easy to find all the key pieces you need instinctively.

While it can be tough I think more tutorial style docs can be a place to start lowering the incline. For example, if you’re not using a rails style rest server, the whole side loading thing, while justified and understandable isn’t typical in other environments.

Little details like if you do a record.update() only the updated record should be returned, that and any related objects (can’t remember if that’s the case)…otherwise you’ll end up with uses. In the process of figuring out some of the nuances of ember-data I created https://gist.github.com/zcourts/4781a4c00f635d9e9b3a

Again, most of that is documented, but not in the same place.


I’m gonna shill my tutorial for beginners here :sunglasses: , https://medium.com/@ulisesrmzroche/lets-build-jwt-backed-authentication-with-ember-and-express-5425a1977d23.

It’s a “Lets Code!” rolling out our own authentication mechanism for an Ember App using JSON Web Tokens and an ExpressJS API. I’ve gotten kinda busy recently, but it’s at the top of my list right now to finish out the next part.

@zcourts side-loading is for the case when you don’t want to spend another request to the server to get the associated record, it’s not a rails-specific thing, it’s actually quite widespread.


For those who are more advanced and running into roadbumps, check out @alexspeller talk on Ember Pitfalls. If you’re coming from Rails, check out Brandon Hayes’ Refactoring towards Ember https://www.youtube.com/watch?v=VMmaKj8hCR4 and Matt Jones’ Empty your Cup,


Its not the framework

I’m thinking of making the switch also, and here’s why, it’s not the framework per say.

Ember does have a steep learning curve, but once you get certain concepts, it’s like, boom, now I get it. And it’s great. But getting there is a nightmare.

It’s the documentation

The issue is, the documentation is just horrible horrible horrible. Meaning it’s horrendously over simplified.

I’ve been working on my first Ember app for two weeks, it’s a dynamic form type thing, think survey monkey, that kind of thing.

With all my stackoverflowing, googling, even BINGing it - that’s what it got to :slight_smile: - I have failed to find ONE updated end to end example of just an effing basic form in Ember, with text inputs, checkbox groups, radiobutton groups etc. As in, a basic form we’ve been dealing with for years.

The todoMVC app is all well and good but it’s such a weird specific app with a very specific workflow.


I had never used a Javascript framework before. I had never really written anything in javascript other than JQuery to do stuff with . I just graduated college and had only been programming during my 3 years of CS. I’d written one app in Django, and a few of my own projects in frameworkless MVC style in Java. And yet, I was able to feel extremely comfortable with Ember CLI over a weekend solely from reading the documentation. I have since written a decent sized application that would have been impossible without Ember or some other SPA framework. Note: I don’t use Ember Data.

Sure, parts of the docs are weak (I’m looking at you, pods docs), but it’s really easy to internalize whats going in Ember from the docs IMO. I think the docs explain how the framework works really well. The API is incredibly useful too.

Maybe I’ve never been part of a community that spoon feeds you examples all over the internet and have nothing better to compare these docs against. But I know these docs were a hell of a lot better than lex/yacc, Tomcat, or anything other tool I’ve used before. I guess my approach has always been: find some example that’s ballpark what I am trying to do, tinker with it for a while, figure out why it works, and then tailor it towards what I need. From my experience, its been really easy to find examples of form views such as select or input on the web.

I think Ember’s docs make the assumption that you are a web developer and feel the need to only show you how Ember’s infrastructure works. And that’s the most important part to building an Ember app. Internalizing where aspects of you application should go.

Whats the url? Put it in the router.js

Do I need a library? Make sure to import it after using a bower install in my brocfile.

Whats the model behind this page? Add it to the model hook.

Do I need more than one model? Use a promise hash

Do I want some data to load after? Put it in the setupController so it doesn’t block on promises.

Is my model an array of objects? Use an array controller else object controller.

Am I doing manual rerendering? Setup named outlets. Add renderTemplate hook. Add action to rerender

You get the picture. The beauty of what I just described is that Ember made these decisions for me. This is a beautiful thing because any other developer on my team knows exactly where to look.


I think Ben’s experience has been repeated by quite a number of folks. I remember having quite a few false and frustrating starts with EmberJS myself.

Too many times I think new folks unfamiliar to the framework are prematurely dismissed as not having enough rudimentary skills, lacking basic programming experience, and sometimes treated with an undercurrent that they’re not smart enough to get it.

Usually by the time someone has opted to jump into Ember, they’ve done enough roll-your-own work to appreciate what Ember brings to the table. Embrace these folks as future contributors and tutors for those that follow.

The fact that one can go over to Meteor and “get it” doing pretty much of the same concepts, suggests the problem is somewhere between the communication of ideas between framework designers and the target audience. But we’ll explore that in a moment.

Frameworks are supposed to not only remove the tedious work, do the heavy lifting, but also be approachable. Given that many of the folks having problems do have experience with advanced JavaScript, functional design patterns, other web frameworks, something is amiss. A close look at EmberJS shows that it has elegance, so it’s hard to blame the framework itself. Something else is going on.

@thatandyrose nailed it. It’s the documentation.

Ember’s documentation is beautiful looking, and that’s deceptive, because its polish conveys a degree of comprehensiveness and completeness that actually isn’t present.

When I dug my heels in to learn Ember, I took a bunch of notes, with the thought that perhaps a book would roll out. At the time of writing this, I have literally 72 separate concepts in my outline that are prerequisites for learning Ember from scratch. Somewhere between five and seven are what I’d consider the crucial concepts for groking EmberJS, but because Ember unifies these together so tightly, it seems there’s a chicken and egg problem buried in there somewhere.

Aside from outright problems and inconsistencies, which the community accepts from version drift, the documentation appears to be written in the form of a reference guide aimed at someone who already knows Ember. It’s not readable sequentially, as it makes forward references to unintroduced concepts. Consequently, at a minimum it takes multiple readings. Thank God it’s beautifully hyperlinked …with a tiny number of links to chapters that don’t appear in the outline.

As a development resource, it’s great. As a user’s guide, it does very little to let us into the mindset and design decisions that were made and how the framework designers expected it to be used. Explain by example doesn’t always convey why.

To be quite fair, this is a common problem for opinionated frameworks. Conventions are more than just naming conventions.

Suppose you want to something slightly more advanced than just displaying a form with reactive values in a template: store something trivial and do it the Ember way.

That means learning ember-data; one can surmise that it does ORM stuff, and maybe you’ve got years of Hibernate (or something similar) under your belt already – you’re not dumb. Click on ember-data in the documentation, you get a list of classes …but what are they for, what do they do, which ones are internal, which doe you extend through subclassing, which hooks do you override, which must you, and which can you?

Click a class, and you get a list of methods, but not the order they should be called in or used (alphabetical isn’t helpful); which ones are common, what’s the design pattern this is a part of, what are the ranges for the parameter values, where are the examples? How do these relate to other classes?

Terminology could be better. Oh, store as in data store, not as in a verb such as to store(). Can I use just a model, or do I need a store? What responsibilities does the class pick up? Which am I responsible for? Is the adapter thingy for the store, the model, or the application? Why do I need one?

If you’re familiar with Ember you may know the answers, having discovered for yourself, but the new person is going to be faced with hundreds of these kinds of questions. What seems silly or even nonsensical to you now is a legitimate question for the uninitiated.

Documentation’s purpose is to solve this problem. Right now, in its current state, it isn’t. Some day it will, Ben. Some day.

The documentation isn’t quite clear either with its examples. Again, it’s not the what or how, but the why. Take a simple example:

MyApp.Store = DS.Store.extend();
store.find("person", 123).then(....)

Is the .Store in MyApp.Store just a name I made up, or is it somehow wired where Ember by convention expects to see it? Why are we subclassing if we’re not adding anything to it? Why is DS not in Ember’s name space? When did the store instance get made? How did it get into scope? What naming conventions do I need to know? What is “person” the find is looking for? Does it do pluralization? Does that map to “People” somewhere else that I need to be concerned with? If a Person class expect a JSON object with “person”, why did REST becoming /people. Maybe .fmt() is guessable as format, but .loc(), what’s that – location? an offest? or localization?

Note the set of novice question has nothing to with things like “what’s a Promise?” You’d figure that’d be the hard part. If they can get what that’s doing, then what they’re really asking is a better understanding of how Ember is put together.

Yes, the answers are out there – spread all over like a massive Google treasure hunt.

And this is the point where things get snotty, and the community says “go read the code.”

The code, frankly, is pretty brilliant. And that’s turns out to be a problem, too.

Library authors are super-talented coders, using advanced constructs and techniques, and are focused on concerns like size, performance, and reusability, taking advantage of state that’s not transparent in the higher level abstraction. Sometimes the implementation of simple API magic is some hardcore under the hood stuff that requires detailed knowledge of other system internals, like how the browser really manages the DOM. A novice might not get it, the same way as someone learning C might not get clarity by reading how the compiler emits assembly code while mixing concerns with instruction timing optimizations.

More over, if the novice is only familiar with JavaScript from a web-client perspective, an excursion into NodeJS, Ruby, compilation tool chains, package managers, dynamic loaders, and ES6 transpires are most likely things they’ve never encountered before. Let’s be fair when we dole out that advice. EmberJS should be for the masses, it doesn’t need to be the framework of the elite as it’s sometimes treated.

One of the things that I really respect about Meteor is that it doesn’t just throw an API at you. It’s documentation explains the foundational concepts first, building them up with trivial JavaScript code, and when you see how it goes about doing it, it then says something along the lines of Meteor saves you from doing all this with the xyzzy() function, but the actual implementation takes into account a number of additional edge cases you don’t need to worry over. The actual code is far more impressive, but you’ve got a metal model that’s usable immediately. I think that’s how Meteor gets an accelerated head start over Ember, even though it’s doing both the front end and the back end.

That said, in using Meteor, there’s a lot of freedom it gives that makes me long for how EmberJS opts to do and organize things.

So Ben, you’re not alone. And I’d encourage you not to give up on EmberJS entirely, but consider taking a break from Ember for a bit.

If the concepts are tripping you up, go read Meteor’s introductory materials, it will turn the light on for you – and you’ll see the parallels, at least conceptually, that Ember is also doing. Then come back to Ember, and I think you’ll like the way Ember has carved up the problem space and where responsibilities lie once you start using it.

If the convention is tripping you up, welcome to the club; working example projects are probably going to give you better insight than the documentation for now. Where Meteor has what appears to be a lot of stuff floating around globally, EmberJS has things nicely packaged into a namespace. Although, you’ll often be left wondering if you’re just using the name space as a registry or actually plugging into something by convention hidden in an implementation class – for now a lot of reading of the documents will help, but I’d rely on asking the community to get clarity.

In the end, I think you’ll really enjoy using Ember.


It would be brilliant to see you put in your experience / notes to www.howistart.org


I think one of the things that lack documentation is the container.

The guide mentioned it as part of dependency injection, but the class is not documented as part of the API. EmberJS’s core team also had been saying that the container is an internal class that the public should not concern with. But I think it’s actually pretty core to understanding how Ember does its magic.


Except for .get and .set central, that is atrocious, was atrocious and will continue to be atrocious until it eventually dies and becomes an old battle story we tell Ember newbies in a few years time.