As a beginning programmer you might wonder why your expectations don’t match a framework used by very many programmers. 
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. 
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 332624 - chromium - An open-source project to help move the web forward. - Monorail for more details
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('new');
//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.
MoJie
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!
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.
I’m also new to Ember, but am good at googling sample code and tutorials, so it hasn’t been a big deal to get around the docs, but it’s hard to express how right you are here. The best API docs I see are ones that try to inline examples for every API call. No one gets them all, but some manage a large majority.
This shouldn’t be so rare, but it is.
Why I am almost leaving Ember is because of how it handles animations. I am certain that I would understand Liquid Fire after reading its docs for two or three times, but since I am quite used to Angular and its (now I know) awesome $animate module, I just can’t get Liquid Fire.
$animate automatically detects the element’s transition duration and delay so you don’t have to bring those to application code. And it handles animations without producing any DOM nodes, completely based on classes.
I really am not having a hard time with other parts of Ember at all. It’s Router and Data are just remarkable, miles and miles ahead of Angular’s $route and $resource. But, comming from Angular, I think animations should be something trivial and entirely handled by CSS.
Animations can be trivial and entirely handled by CSS.
Liquid-fire is for stateful transitions, many transitions aren’t stateful and that seems to be what you are describing. It would be nice for there to be a similar library for state-less transitions, but until them using velocity jQuery.animate or similar yourself is the easiest way.
Well, I did not want to give you the idea that I was talking about general animations as it was my intention to talk about the stateful ones, as you call it. To be clear, {{#if}}, {{outlet}} and {{#each}}. I understand that, since Angular and $animate act upon real DOM nodes, while Ember acts upon string templates, it might be difficult, if not impossible, to recreate $animate functionality in Ember. Sure I can use “classNames: [‘animation-class’]” inside a component and, then, write its css as “animation materialize 1s ease 0s normal forwards”, to make sure that, at the begining of the animation, the element’s opacity is 0 and, at its end, 1, still retaining the style of the last key frame. But the real problem resides when replacing the contents of those helpers. Since de DOM nodes are immediately removed, there is nothing to animate. This is precisely the problem addressed by Liquid Fire and $animate. $animate’s simplicity is, in my opinion, a much better approach. According to the directive being used, it simply adds one initial class, which would not be present normally by the time of DOM insertion, and, very quickly, adds another one. These two classes together get the animation done without any Javascript code. Liquid fire, on the other hand, utilizes a central javascript file where pretty much everything is declared. I particularly dislike this approach. I believe that the animations should be declared in the template’s markup instead of declaring in the application code that all DOM nodes with the class “materialize” should be animated with a certain duration and after a certain delay. These variables, I believe, live happier in my SCSS files. I could get used to that, but the extra DOM nodes, serving as containers for panels to slide, settled the stone, to me, as a no go. Maybe something similar to $animate could be done in a component. As I understand, the component’s property “classNames” is the place to define the classes inherent to a given component, which must be present by the time the component is inserted. Perhaps a similar property, “insertionClassNames”, for example, could hold the classes that should not be present by the time of the component’s insertion, but right afterwards. In a similar way, the property “removalClassNames” would hold the classes that would be added to the component before its removal. I actually am doing something similar. By using “classNameBindings” I add a class suited for removing a component and, when it evaluates to true, I attach a listener for the event “animationend” in order to remove the the component from the dom. Yes, I do prefer to do that by hand instead of using Liquid Fire. Also, I believe the approach I suggested, which is quite similar to $animate’s, is much more keen to whole idea of Web Components which should, by design, encapsulate its complete behaviour and styling.
Hummm… I just realized that my suggestion would not solve the stateful transitions we talked about: {{#if}}, {{outlet}} and {{#each}}. $animate can do that because it acts upon DOM nodes that already belong to the tenplate. Liquid Fire has to rely on extra DOM nodes. It is a difficult problem to solve.
Em Dom, 27 de set de 2015 11:38 PM, Paulo Oliveira oliveira.phc@cuscuz.com escreveu:
I’m on my phone so I can’t really respond extensively but you actually grossly misunderstand how liquid fire works and tell Ember templates work.
Ember templates get compiled utilizes cloning And fragments, not string DOM.
Liquid-fire works by providing its own outlet such that it can control setup and tear down of the new DOM and old DOM both. It also adds classes, or you could add your own, and you can in fact write 100% CSS animations that work with liquid-fire quite easily.
I agree that in some cases you want to declare what animation should be used directly in your template, liquid-fire also allows this via “use”. I think it could be improved further but it works extremely well as is.
In general, transition animations between routes really don’t belong in the template, and the pattern LF uses for these mirrors patterns you will find in chrome/android itself, react libs, and many game libraries.
So here is my concern. This is a really good thread that describes a lot of the reasons why people are struggling with learning Ember (as I am). I agree that other tools like Angular have their problems, and I actually appreciate the opinionated nature of Ember.
But this thread started over a year ago, and in my opinion, nothing has been done to fix the documentation problems that several members seemed to accurately identify as a root problem. That to me speaks to a bigger problem, in that the community, while passionate and knowledgeable, isn’t large enough to tackle the problems like this without having to stop developing new features.
The documentation is still atrocious. And it (as several others pointed out) bad in the simplest ways (like omitting the top lines of the file that explains where commands like DS.Store came from. And it appears to me that all focus has been on getting to 2.0 without any regard for fixing the existing documentation.
If you really want people to use Ember and have it challenge frameworks like Angular for a larger market share, then you have to start addressing the learning curve.
But bottom line, is the community of experts needs to prioritize fixing these issues. Otherwise you are the brilliant guys sitting in the garage who have finally built the better mousetrap but can’t figure out why people aren’t knocking down your door. It doesn’t matter how good it is if you don’t make it something people can figure out.
You are right. There is, however, a very recent but substantial will to address these documentation flaws.
Absolutely.
This is a reasonable critique. Context is very important, especially for new comers. It can be difficult for more seasoned Ember veterans to see this sometimes. Experience fills in the gaps and a lot of reading between the lines is taken for granted. For anyone attempting to write documentation for Ember I would suggest erring on the side of explicitness. Even to the point it seems like it is excruciatingly obvious. Put oneself in the mind of a total novice, sometimes easier said than done though.
I am glad that their is a renewed understanding and effort to fix this, but without being too cynical, the proof is in the pudding (or documentation in this case). Until people see that it’s been fixed and made better, they aren’t going to believe that it will be.
I would be willing to even help (as a newbie) do some of that documentation, but I need help just understanding how to do it first. An example is a thread I have been having on data reformatting in the controller so I can take data retrieved in the route and restructure it to comply with a component I need to use. Several responses to the thread, but I still haven’t had anyone actually show me an example of iterating through a list and reformatting it, which seems like a very common thing.
It makes me wonder if the greater community has really adopted an interest in the growing the user base, or if (as does happen to some technologies) it’s created an “exclusivity” culture that almost subversively tries to keep new users out. That often times isn’t want the leading group wants, but happens among high level users with lots of informal sway in places like StackOverflow and discussion forums.
I have read some documentation for recently released 2.1.0 and there is a noticeable improvement.
I feel your frustration, jesmith, I really do. Based on MY own frustration, that I overcame, is that I started Ember Igniter – striving not to lose the perspective of a beginner. There is no such conspiracy to keep new users out, the proof is in the amount of conversations (especially if you join the Slack chat) trying to address these documentation shortcomings.
Ember, 2 years ago, was bad. Sure, lots of good ideas and very smart people behind it, but it was a pain in the ass. Why? Too complex. (Not that alternatives were much better.) That didn’t preclude people (even a mediocre developer like me) from shipping. But you had to be armed with a LOT of patience. Ember Data: that was not bad, it could almost be classified as shit. Totally different story today.
For the past months, and with the advent of 2.x, things have matured enough to say that it’s very good. Why? Significant conceptual simplifications and many things falling into place… finally. The prospect for the 2.x series is excellent. I for one am very excited about these upcoming releases.
Unfortunately there are a few remnants of Ember’s dark ages that the community is actively working on purging – including documentation. This is still a transition period… luckily we’re at the end of it.
It’s a good moment to invest in Ember. It’s an amazing, mature technology now.
Regarding your issue with data reformatting, I want to help you. Hit me up on the other thread, contact me directly, whatever. I won’t leave that until we make it work.
I think one of the best things that Ember should add to the documentation, is either code examples or working apps of things people frequently do.
The examples you can find across most sites are way to simplistic to be helpful outside of a classroom. They need to cover things like
But I think it’s also a problem that we are only focused on fixing the documentatin for the newest versions. My company is considering a move to Ember (which I am currently voting against based on the above mentioned issues) but have a reason I am not privy to, for sticking with the 1.13 version. So fixing the HEAD versions documentation doesnt’ help me. And I am sure that their a multiple commercial places that are wary of doing to the tip of a new technology for risk of bugs, and are going to start with a 1.13 version if they were looking at things in the short term.