Why i'm leaving ember

@dagda1 why? isn’t this pattern common in all client-side frameworks? edit: actually i see you have already answered this here Why i’m leaving ember

I recall my days coding WPF, creating OnSomethingChanged functions makes perfect sense in a mvvm pattern. ( Curious fact: Most popular framework for wpf was caliburn, which was done by Rob Eisenberg, which until somewhat recently, was on the AngularJS team ).

I for one, love the observables and the change notifications ( events, events, events ). That said, takes alot of good practices and discipline, … like everything.

As a new user of ember I have found that making the move to ember-cli too soon (that would probably be me) can be an issue. Mostly because most examples out there in the wild are not in cli and some things just work a tad different if you aren’t completely familiar with ember before hand.

I believe there will never be the silver bullet framework that will kill all other frameworks. If you have a strong Javascript foundation, frameworks will come and go, but your knowledge to leverage them will stay the same.

1 Like

I’m kind of surprised that no one mention how hard debugging sometimes is!!

I’m talking about PendingQueue and that kind of stuff when ember decided to load a model but you have no idea WHY! There are maaaaany other cases when tracing issue root impossible because stack trace is just a bunch meaningless of Queue.flush and Backburner.run


And then there are the times when you ask the same question on Stack Overflow, IRC, and here, and get nothing but crickets in all three places…


It’s funny, I came to Ember as a fairly weak JavaScript developer. I had spent a lot more of my time working on the visual side of interface development. I took to it immediately because Ember gave me is a consistent way to build out my ideas quickly. The thing that makes me feel secure in my investment is how much Ember teaches me. Because it is well structured, I can just rely on the conventions and then learn about how each piece works as I need to dig deeper.

I would also be patient with docs or contribute as you can. Keeping on top of all these changes is a herculean task, and with limited resources, you can either slow down development to make sure it’s fully documented before moving on, or you have to keep a backlog of stuff to come back and update as new conventions are implemented.

Having worked with many frameworks, platforms, and CMS’s, even the most well capitalized companies have trouble keeping up with this stuff, and the Ember community has done a pretty good job given the rate of innovation to date.



I think the weakest aspect of Ember is the documentation and availability of guides, best practices, etc.

Much of the existing documentation seems to be out of date and links to JSBin frequently seem to fail as the syntax has changed so much. All of this makes it a very frustrating experience especially when there is clearly so much promise there.

The need to use Ember Data and Ember CLI is also off-putting and is compounded by Ember CLI having yet more dependencies that need to be understood. Then you have various changes like the recommendation to move to pod structure even though the documentation rarely does so.

I’ve persisted so far but right now even though I like what Ember offers, I don’t feel confident recommending we use it because I don’t feel comfortable that my team could pick it up without a lot of hand-holding and trial & error.

I think it is a real shame that tilde lock their best ember video guide behind a $500 paywall because that rules it out for pretty much any solo dev or just an interested dev who hasn’t got the financial backing/means to cover that cost for a few hours of video.

It’s already clear that Angular is monstering Ember in terms of uptake/mindshare and I think much of that is because the initial learning curve and effort for Ember is pretty huge in comparison and it’s not that clear why you’d put the effort in. Angular is definitely not a trivial thing to learn but the basics can be picked up much faster.

So far I have found the Ember CLI 101 book to be about the best resource but that is still fraught with errors and it would be much better if someone in the Ember team rather than a 3rd party could offer something along the same lines.


That’s not fair or accurate. Most developers here have learned what they know with free resources. Ember is a participatory community- you learn and contribute by interacting, asking questions, answering questions, and submitting, reviewing, or trying out code. The books or bins rarely have “errors”- rather, you probably have seen a feature that isn’t available in the point version you’re using. Due to Ember’s community-driven nature, change happens quickly. That’s a feature, not a bug.

Other frameworks are easier to learn. Ember is easier to use. If that doesn’t appeal to you, you might be better off with a different solution.

1 Like

I meant it rules out the video not that it rules out Ember entirely, apologies if it read as “without spending $500 you can’t learn Ember”, that wasn’t my intention.

The free resources that are available are mostly out of date and I didn’t say they all contained bugs (although in my experience, many do, take this errata list for example - https://github.com/abuiles/ember-cli-101-errata/issues). What I said was they didn’t work which is true unless you find the point release they used which is another barrier to learning.

The evolving nature of Ember means it continues to improve but it also means up to date docs and guides are very important.

I’m not sure about the distinction between being easier to learn and easier to use. I do think Ember encourages good practice but there is a heavy price to pay in terms of wrapping your head around a lot of concepts first.

I’m only adding comments here because I want to see improvement, if I didn’t think Ember had a lot going for it then I wouldn’t still be persisting with it :slight_smile:

1 Like

I keep hearing these issues about documentation, and I’m just never feeling entirely sympathetic. I think the large surface area of documentation is purely because Ember does A LOT of things for you, and that breadth of functionality is naturally going to come at a cost. Nothing worth knowing was ever learned without effort–you don’t hear people complain about not being a rock star an hour after picking up a guitar, do you?

That said, I was a fairly terrible JS dev 2 years ago when I started using Ember, and I can’t recall that learning it was that difficult at all. Unlike any other framework I’ve used, it’s painfully obvious when you’ve found the “idiomatic” way of doing something. Additionally, the framework was FAR less-developed and harder to learn back then–a lot of the patterns and consistencies we enjoy today hadn’t been unified, so you would find yourself doing some very quirky things to, for instance, dance around the fact that Ember.Component hadn’t even been invented yet.

Maybe this is a question of just finding the right tutorial for your use case/application, instead of trying to read all the documentation. I would say this is like buying a new product and reading the “getting started” guide instead of the manual itself. Once you get the first 10 concepts down, learning the rest is incredibly consistent across the board.

No one is suggesting you use the CLI to develop your product. CLI just runs the tasks you need to be successful with a minimum of effort. ember new my-project; cd my-project; ember serve will literally get you a running application in seconds. If you think that the creators are suggesting development through CLI, then you should probably forget everything you think you know about ember-cli and start reading about it from the beginning.

If you like using an IDE, then use an IDE. If you want a drag-and-drop designer for Ember, then I think you may have been in the wrong industry for 33 years, and Ember probably isn’t the framework for you!

As a beginning programmer you might wonder why your expectations don’t match a framework used by very many programmers. :slight_smile: But seriously, simple programming tasks can be accomplished with simple tools, however those tools often often don’t scale well with the complexity of the programs you will want to create.

That said, use what works for you for now, learn, later you might find you better appreciate Ember (or some other tool, i am not a preacher)

Ya, this is totally annoying. Unfortunately this is a platform deficiency. :frowning: I realize this sounds like a cop-out, but it really isn’t.

I have been working with the chrome team to nail the semantics for a solution. They hope to have a prototype implemented sometime q3 or q4 of this year. (i’ll be sure to remind them again soon, incase they have forgtten

see https://code.google.com/p/chromium/issues/detail?id=332624 for more details

1 Like

that being said, we are constantly striving to close this gap. Although tricky, we believe it is absolutely possible. Simple tools that handle complex tasks are obviously the best of both worlds, they just require several more evolutionary steps.

thx. for the link! I voted for that feature =)

I`m a begginer too, and agree this case very much, but I like ember more and more. I think that ember.js has no better guides, the community should improve these, how to use the nested recourses, how to resolve the flow in the controller, router or view, etc.

For example: https://github.com/mharris717/ember-cli-pagination/issues/108

This question is:

I add pagination to my comments of a blog, when I transate from one blog to another, the queryParams(?page=2) and the pagedNumber are still of the one.

1、How to clear the existed variables?

Becouse the ember-cli-pagination access the variables in the controller, I use the willDestroy in the comments controller, but it has no effect. The doc of the emberjs.com says willDestroy called when App.reset(). I use the init(), it throw a null error, The code:

 willDestroy: function () {
    this.set('pagedContent.totalPages', null);
    this.set('totalPages', null);

The init() code: https://github.com/onecoinim/website.onecoin.im/blob/master/app/controllers/comments.js#L27

So I have to try another method like willDestroyElement of the View or the deactive of the route…

In this question, I don’t know (1) I should clear which variable, (2) where and how to clear it.

2、How to access the nested resources.

This is a very easy model: blog has many comments. I have set the routes is

  this.resource('blogs',function() {
    this.route('show', {path: '/:blog_id'}, function () {
      this.resource('comments', function () {
        //this.route('show', {path: ':blog_id'});
        //this.route('edit', {path: ':blog_id/edit'});

now it works, the demo is http://onecoin.im/blogs/2/comments

But I have a question:

If i use the url http://onecoin.im/blogs/2 to get the same content of http://onecoin.im/blogs/2/comments , like the ruby on rails, How to do?

The demo: http://onecoin.im/blogs/2/comments

The code: https://github.com/onecoinim/website.onecoin.im

help me, thanks.


Well, I can’t say I’m leaving Ember forever but the project that brought me here is also taking me away. I came to Ember to write an animal husbandry application for my hobby. While many concepts were clear, learning to implement them was difficult. I fall into the camp that Ember takes weeks/months to learn (at least to do the things I am trying to do). Also I was following the current documentation which was out of date (compared to the rest of the community) and that caused its friction.

What I can say is my last post was Apr 25th. Today is May 27th. In that time I have gotten one of the three genetic calculators (for my animal husbandry application) running in React, Fluxify, and React-Router. All of the functionality I ever did in Ember and more.

I know that React-Router is a re-implementation of the Ember router (and thus was easy to learn, Ember does Routing well).

I have to say thanks to @kylecoberly for suffering through with me and for all his efforts to help. And a big thanks to the Ember team (of which @stefan is the only one I know by name) I hope my issues might give you perspective to reach out to those in the “Microsoft stack”. Thanks also to all those who I have left unnamed who tried to help me, I learned from you all. Of course, package managers and frameworks driven development in JavaScript is the major take away from my time in Ember, it made learning React and Fluxify easy and I’m productive in those frameworks.

Thank you all.

Rock on! I’m glad you stuck it out for a bit and got something out of it. Hopefully you make it back someday. Best of luck!

1 Like

Learning Ember could be a lot less daunting for newcomers with new guides designed with input from said newcomers.

I’ve been trying to learn Ember for the past month, and every time I think that I have something figured out, I meet a million more challenges. I can’t even get a basic application rolling.

The official guides are probably great if you are a veteran developer who has experience with full-stack web frameworks, but they read like gibberish in my experience. No mention is made of services or utils, which were crucial to my understanding of Ember thus far.

I already have many ideas for how the guides could be drastically improved for people struggling like me. For starters, the order in which information is presented could be better. Take a look at the guides for knockout.js - they are so simple that you don’t even have to know JavaScript in order to understand the framework. Another issue is that virtually all resources are outdated, even if they are only a few months old, which is due to the rapid pace at which Ember is changing and deprecating old features or practices.

If I ever manage to fully wrap my head around Ember and get my application rolling, then I would like to help maintain a set of guides for complete newbies that is constantly kept up to date. Even with my limited knowledge so far, I think that I could explain some things a little more clearly than the guides do at times.