The most valuable answers will come from non-Ember programmers as they are the ones that we want to attract to Ember…
I am business guy in tech, not a developer and perhaps my worldview can add something to this discussion.
Years ago I had a consultancy with dozens of Java developers and we were deciding how to migrate to web development. We decided to go with Rails and what sold me into it was Convention over Configuration.
Maybe a more restrained framework is bad for developers, but it is wonderful for business. I don’t know if the learning curve was steep for Rails, it didn’t matter to me. What was important is that whenever I found someone with Rails background his learning curve inside our project was nothing. And that is good for business.
Now I am betting on Ember, because it is intended for ambitious applications.
For sure it is still a risky bet because there aren’t so many Ember developers… right now. But like in football, you shouldn’t chase the ball, but run to where it will be. The future are in ambitious web apps that look like native ones. I am talking about applications like this very Discourse app we are using right now .
A simple app can be made in any framework and Ember probably isn’t a good fit in this case. And if this means that Ember should be considered a niche thing… so be it. It may not be the leading framework, but it can be the leader for ambitious apps. Eventually, the market will shift and then…
So, IMO the Ember core team has made a terrific job in building a great framework. They should shift their focus to making it easier to people learn and use it at its max as so many have already said. But the future of Ember lies on its community shoulders and its capability in showcasing Ember’s true potential: If we build really ambitious apps, they will come.
5 Likes
Better guides, better docs.
The learning curve is steeper for front-end developers than the Angular (1.x) learning curve. We need more help for new Ember developers. There is a good paid guide offered by Tilde. http://www.tilde.io/events/introduction-to-ember-online/ It is $499.
We need to have a guide of this quality for free and maintained by the community. Otherwise Ember will end up as Betamax.
2 Likes
Please, improve the guides and docs. I’ve had the same issue as @szimek before and it’s really discouraging as a beginner. Adding animations would be great, although Liquid Fire is an awesome addon 
Help the angular community migrate to angular 2.0
Edit: I think it would be helpful to gain a deeper understanding of angular (not just how to use it but how it works) and to gain a better understanding of the migration problem in software communities. We can bring that knowledge back to ember and apply it.
I completely agree with this. The company I work for uses a php backend and server side rendering and ember is completely useless unless you have a node or rails server setup. OK, not necessarily useless, but you can get seo out of the box easily with angular and php. If you guys would add php in there, you’d probably get at a ton more developers on board.
Also, the docs need to be updated. I’ve tried finding things only to do a quick search h on Google and the docs weren’t updated. E.g. components have a state property that isn’t anywhere in the docs but can cause issues if you use the same name.
One thing I wish was a lot easier is being able to share code across multiple apps. I think I have to move things over to an ember add-on but also heard that things are changing in the future.
IMO (I might be spoiled coming from a Rails background) there is too much confusion in Ember-land. Everybody is talking about routable components and not using controllers and “data down, actions up”, yet we clearly are not there yet and we still have to deal with controllers, etc.
Maybe this will get better with Ember 2.0. I don’t mind losing controllers in general; they seem quite confusing as a concept anyway (they act both as view decorators and “real controllers”, i.e. where actions are actually handled; also the singleton-ness is unintuitive). In any case, I think Ember needs more in-depth guides that explain how the different concepts fit together. The individual pieces are very well described, but it’s not so easy to figure out best practices (this is compounded by the fact that everyone seems to be thinking about Ember 2.0 already).
Anyway, even though it’s (still) a MVC framework, the MVC-ness is actually the part about Ember that I find to care about the least. What I really like is the object model, data binding and especially computed properties. Seriously, computed properties are the best thing since sliced bread, and the only downside is having to remember to always use ‘set’, ‘get’, ‘pushObject’, etc. Computed properties allow for a much more declarative way of specifying application state which is much more maintainable in the long run. At least that’s my impression for now. 
I really also like all the methods on Ember.computed.
Just my opinion after working with Ember for a couple of weeks.
edit: Just to reiterate why I don’t care so much about the whole MVC aspects - having done a lot of Rails I’ve come to realize that you can’t really shoehorn every problem into some kind of “MVC thinking”, especially when the concepts are so loosely defined anyway. I prefer to have a thin “web layer” that deals with the boundaries (the client, basically) and then delegate the real logic to dedicated subsystems that does not need to know about the web or anything. I’m not there yet with Ember, but I’m doing this more and more with Rails.
Oh, and also, I really like Ember data. It cleanly separates models and persistence and it is actually not too hard to customize an adapter (although it might be nice if there were a couple more hooks, at some points I just had to copy the method over and change some minor detail).
I’m currently an Angular developer trying to find a better framework to make my life better, and I want to like Ember, but I agree with you - it seems too chaotic to jump in. I was looking forward to just using angle-bracket components, which would greatly simplify the mental model, but that’s been delayed and it looks like both methods of components will now stick around side-by-side throughout 2.x.
What’s worse, Ember 1.13 was released two weeks ago, but still has no guides.
1 Like
Actually I might argue the opposite I think. Simple apps are pretty easy in Ember because you get so much for free. Just the other day I wrapped up a small little side project at work. It was 1 route (application), 4 components and a service object. No persistence, and a simple “READ ONLY” python API that serves GET requests.
The whole thing was remarkably easy to build and deploy with Ember CLI, and didn’t take that long.
And I agree with you about restraints and consistency being good for business. This is why I actually think Ember will play well in Enterprise environments long term.
Anyway good points all around, thanks for the thoughtful post @fredguth
1 Like
I agree that Ember scales very well from small to ambitious applications. But small apps are not where Ember’s added value lies compared to other frameworks. For a newcomer, is Ember worth the steep learning curve? If all you’re making is small apps, then I’d argue a framework like React will yield results faster.
To be honest, I’ve been recommending coworkers to wait to at least until v2.0 before jumping into Ember. The transition to routeable components and one-way data binding by default is too significant a change. The current docs and all blog posting and stackoverflow questions out there are still focused on the old, controller-based approach, so there’s a good chance that newcomers are learning a method that is no longer considered best practice.
No doubt about it that there is a steep learning curve. And a lot is changing. From my vantage point the 2.0 release is about making things simpler, consistent and more intuitive. So I can see the logic in advising new comers for 2.0 jump.
As for whether the learning curve is worth it to new comers. That is an interesting question. It probably depends on what one’s perspective is. The paradox is that the more you learn the better and faster you will be able to deliver results over the longer term. But that is true for any craft.
Nothing precludes using other tools if they are indeed faster to reach a specific goal. In fact I would always encourage new comers to try out a lot of different systems and tools. Figure out what feels right and is a good match for their aptitude and desired use cases. And I guess it always depends on scope and the definition of “small project”. Right tool for the job as they say.
But in many cases there does come a point where there is a need to level up and and scale with the tooling.
Certainly there are a lot of details in ember that are difficult to learn. But I think the framework strives to hide a lot of those details. And you can actually do quite a lot without actually understanding how things work. True it can be really difficult when something goes wrong. And that is the paradox about “best practices”. I think they are often proposed as a way of sheltering novice to intermediate users from running into the dark corners. This is the collective wisdom of all the others who came before you. But at the same time there is real value is learning how to debug or troubleshoot when things go wrong. This skill above all others will serve someone very well over their programming life. And it seems like that is a hard won skill, with few shortcuts.
I need to correct what i wrote before in this thread. Ember-cli is REALLY making my development easier and faster. Best framework for huge apps, really last changes and 2.0 makes Ember number one for big projects. Even while it’s so opinionated, you can do everything you want with it because it’s really flexible too. If you are doing small simple apps then you could go with react or angular too, but if you are developing medium-big sized app then Ember is really the only smart choice.
3 Likes
Ember needs better docs. There are a lot of beginners that will be coming to Ember and will give up because Ember is hard anyways to pick up. Some of the docs need to be updated badly. Especially wi th all the deprecations getting ready to drop with 2.0. We should have a contest thread sponsored by a startup or the forum of best tutorial. Written or recorded all tutorials will be entered for a chance to win something cool in the dev community. Like an ember swag pack from devswag. Just my two cents. Oh and a guid for setting up a project to digest an api that is not implemented with Rails.
3 Likes
I’m unfortunately not using Ember or Angular (the main app I work on is built on Backbone, Chaplin and Ractive.js), but I don’t understand why so many feel the learning curve of Ember is steep. For me, coming from Rails (a server-side MVC), Ember makes complete sense. It’s MVC on the client side, and has sensible naming conventions like Rails does. I don’t imagine things are that different with MVC in other language web frameworks? Admittedly I haven’t done anything complex with Ember yet, but my initial impressions are great. It’s functionally similar to the Backbone + [some controller library like Chaplin] + [some two way binding library like Ractive, Knockout or one the several hundred out there!] setup but where everything fits together nicely.
Angular has this strange syntax and terminology from day one - for example, the dependency injection where ‘$scope’, ‘$foo’ etc. are passed to the controller, services (I like them, but be nice not to be forced to use them), ng- everywhere in templates, directives etc. I’m sure it’s a great framework once you get over that hump, but it seems to me the hump of Ember is actually smaller than Angular… maybe you could push that - it’s just MVC (plus more if you want it) - to get more people interested in the beginning?
I don’t usually like to comment this early in the learning curve as I’m sure to look stupid somewhere down the line, but I wanted to say that I found the initial learning phase of Ember easier than Angular, which seems uncommon from what I see online.
Bear in mind though that Ember’s concept of MVC is significantly different from that of Rails. In particular controllers.
Not an Angular dev myself, used it for a few widgets on a side project. Got myself comfortable in a couple of evenings and built the widgets without too much trouble. Now I spent nearly a week just to get back on track with current state of Ember. And that’s despite having built 3 small to mid size Ember apps in the past. Things I struggled with:
- There are no examples of working code in official documentation
- JSON API is the preferred way to work with Ember Data. Good luck with nested objects! I ended up downgrading Ember Data so that I can use Ember Data Model Fragments with RESTAdapter.
- Unclear what the JSON should look like working with REST adapter/serializer. Had to dig deep into api docs & source code.
- Super hard to find any up to date examples and once you find something you’re not certain if that’s the Ember way of doing things.
- Ember CLI is super slow. Why would it rewrite the files in /dist if all I touched was some .css file?
I’m lucky to be in a position where I have worked with Ember in the past and know most of the concepts but I can clearly see how hard it can get for a newcomer. Once you’re up to speed Ember is a pleasure to work with but I think it’s the most patient that get to this stage.
2 Likes
IMO this is all on the community to manage - I’m as guilty as anyone but we should all be blogging more. And when we do blog we need to be careful to update the examples when there are relevant updates.
3 Likes
So I see this comment all over the place in the Ember discussions, and I am not trying to disagree with it, but the comment itself doesn’t do anything to help people make a decision.
I am trying to help my organization decide between Angular and Ember for our preferred UI JS MVC work, and I can find this same comment made in every forum about every JS MVC framework. What’s not listed here is why you think that it will be so much faster for me and my org after we get past the learning curve. To me, the opinionated nature of Ember is actually a downside as my org (like most I suspect) is not doing greenfield development, but instead trying to hook a new UI to a set of legacy backends (some Ruby, some Perl, some others). The Opinionated nature of Ember (and it’s co-hort Ember-Data) is what we have spent the most time hacking around, simply as it’s easier to bend the front end than to try to bend a back-end that is in production and has 10 years of cruft on it.
To me thats where Angular beats Ember, in that it doesn’t do as much to dictate how I use it, which gives me flexibility to work around my existing headaches on the back-end.
An example is the internal hack-a-thon we just went through as an org about Rails and Ember. But we have a legacy DB littered with fields using underscores in their names. Ruby doesn’t really care about those and will serialize them fine, but Ember-data throws a fit when trying to read underscored fields.
Opinionated techs at the top of the stack tend to force everyone below them to share their opinions. That’s really dangerous for places that have legacy stuff behind it.
1 Like
The serialisers have simple methods for this that are meant to be overridden in your application serialisers, e.g.:
http://emberjs.com/api/data/classes/DS.RESTSerializer.html#method_keyForAttribute http://emberjs.com/api/data/classes/DS.RESTSerializer.html#method_keyForRelationship
import Ember from 'ember';
import DS from 'ember-data';
var underscore = Ember.String.underscore;
export default DS.RESTSerializer.extend({
keyForAttribute: function(attr) {
return underscore(attr);
},
keyForRelationship: function(key) {
return underscore(key);
}
});
I wasn’t implying that it couldn’t be configured ( as we implemented that exact same change) but that the opinionated nature of the language makes these things happen and that often it is these small opinions that don’t get properly documented and end up causing the most pain.
It was simply a tangible example of an opinion that Ember holds that must be addressed if the existing lower stacks don’t natively hold the same opinion.
Forgive the typing, sent from my iPhone