Ember is the first front-end framework I’ve used. The learning curve has definitely been steep, but I do enjoy using it and can see how it’ll make me a more productive programmer.
My concern is whether using Ember (or any other framework) will help me become a better programmer, i.e., how much of what I learn translates to plain old Javascript?
Hi,
May be you should read some of this books :
Hope it help !
Ember does a lot for you. So all the hard work is abstracted. What you can do is still do Ember to create apps, but do plain JavaScript + jquery/Lo dash/underscore to see why Ember exist. Asking your own apps with minimal tools helps you think critically.
Ember aims for productivity and developer friendliness. it focuses on the app less so the hard problems developers have to make.
Working with Ember you will end up doing so much “plain Javascript” (in any of the logic that you implement, and with any other libraries you use) that it won’t be a problem.
You could slowly start peeking at the internals and learning how the framework does its job.
I’d say don’t worry and keep at Ember, with a curious eye.
I feel like I’ve learned a lot just by using Ember.js. The framework and, more so, its community guided me to make my application architectures and patterns more robust, and become overall a better programmer I would say.
Very little. For instance, instead of using modern JS classes, you will be forced to use the antiquated Ember.Object approach. You will learn to write this.set('x', 1), which would normally be just this.x = 1;. Instead of learning how to organize your code and import and export things from where you want, you will be forced to put things in special locations which Ember will find for you automatically. And so on.
Very little. For instance, instead of using modern JS classes, you will be forced to use the antiquated Ember.Object approach.
It’s not antiquated, but it will be phased out for ES2015 classes once the current proposals for props and decorators mature.
You will learn to write this.set(‘x’, 1), which would normally be just this.x = 1;.
You will also in the process learn what setters are, default setters are, anonymous setters are, and many of the concepts behind push based FRP.
Instead of learning how to organize your code and import and export things from where you want
Ember teaches you how to organize architectural concepts well.
you will be forced to put things in special locations which Ember will find for you automatically.
If everyone were so opposed to convention, it’s a wonder any software has ever been built.
I suspect the larger point you were trying to make is that explicit imports are better than implicit imports via some of the occasionally mysterious resolutions Ember provides, however this glosses over lazy instantiation, containers/owners, dependency injection and the like. Ember has trended towards more explicit lookups instead of resolutions over time, but there are very good reasons for why everything isn’t static, and very good reasons for why not everything should be.
I really think you’re really providing unfair critiques without providing background or perspective.
Yes in the very modern web world things like this.set('x', 1) and Ember.Object can look a little proprietary and antiquated, but if you rewind the clock 4-5 years you’ll remember that IE8 was generally supported, Babel did not exist, and most people were using global vars on the window. In that world, the only way to have a KVO system was techniques like this. Having the foundational framework layer that wraps up native primitive (such as Ember.Array and friends) was the only option to achieve this. And Ember was not unique in this.
Fast forward to now, Ember has continued to move the needle forward towards web standards (which have also evolved along the way), working to shed itself of cruft without disenfranchising its existing user base. But this can’t happen overnight. Just like with application development, you have people using your tools and you have to move things in the right direction at a steady pace while working to ensure there is a migration path for a majority of your user base. For contrast, if you look at Angular 2, there really isn’t a migration path for Angular 1 users. Angular 2 was able to shed a lot of the cruft from their framework by also shedding their user base. Some may say that was a good thing, there is probably an argument to be made there. As someone who has had a production Ember app for over 4 years, I’m happy this was not the case for Ember.
Anyways, this is just my $0.02. Feel free to disagree.
Hi, I was responding to the OP’s question. I have no issue with the
decisions that were made 4-5 years ago, nor could I second-guess them. But
do we really want to be debugging this.get('mispeledPropety') in 2016?
“Steady” is relative. For some people, it means “slow”. I’d love Ember to adopt ES6 classes, and TypeScript. I assume thinking about doing this is underway, but I don’t see schedules or roadmaps for this; instead, I see RFCs for yet another pod system.
Part of the problem is the sheer scale of Ember. Because they chose to encompass so much of the application framework problem, and manage and take control of so many aspects, and as a result have written so much code, refactoring is that much more complex and time-consuming. They’re in a race against time, which I hope they don’t lose.
Bob
With more tsc support I hope we can forget about the custom object model and custom array methods.
This is an interesting question because it partially depends on what you mean by “programmer”.
Admittedly, Ember has been behind on providing a happy path for some programming technologies such as ES6 Classes and TypeScript – so you’ll probably want to dabble into other things in order to master those.
However, in terms of knowing how to build applications – being able to model data; being able to reason about proper data flow; being able to separate concerns regarding how that data flow should shape your route, component, template, and service architecture; being able to write maintainable tests in the context of unit, integration, and acceptance testing – I’d say that Ember, with a community that’s so passionate about best practices and shared solutions, has benefitted me greatly as a programmer who cares deeply about all of these things and more.
Add being able to use async/await and almost never having to worry about build systems for a number of years into the mix, and I’d say we do all right 
