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.
May be you should read some of this books :
Hope it help !
Ember aims for productivity and developer friendliness. it focuses on the app less so the hard problems developers have to make.
Just spend 10000 hours and your are an expert
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.
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