> I've rarely seen Ember be recommended to beginners.
I started a new job and went from 0 JS (other than some JQuery and knowing the syntax) to 100 with Ember. Ember is really really good for beginners, grandparent talks of having to know transpiling, broccoli/task runners and livereload but doesn't understand that you need to know none of that to get working with Ember.
Write your app by editing the files ember-cli produces. No transpiling, or add transpiling with a single 'ember install' command. Who cares about broccoli, I just edit my ember-cli-build.js file with some paths and it all works. Livereload is hardly difficult to understand, with Ember you just run "ember serve" and it also all just works.
I stand corrected -- clearly what I thought was what beginners would feel is not what they did.
My point though, was that after you build on all this complexity that you don't understand (and don't have to deal with), when something goes wrong, you're in for a world of hurt. But maybe that's not an issue
Abstractions aim to hide complexity until one requires them.
As a developer, one becomes productive when one realize when to put the blinders on, and when to take them off. As such I for one, love that I don't need knowledge of x86 assembler, chip design, or signal processing until the problem at hand actually requires them.
Ember-cli aspires to keep developers focused on features, not orthogonal tech. That is unless they need to peel back that layer of the onion, and dive in. Even then, the goal is for only a few community members to dive in, explore the problem space, and ultimately contribute the solution. Next release, all community members benefit, without also having to invest (until the point where they have a specific itch to scratch).
Abstractions hurt when they leak, as such we must aspire to provide the best abstractions we can (at each layer), and this is only possible in collaboration with an eager and enthusiastic community.
An symptom of a curated solution, is all aspects of the stack evolve to work together. Mitigate abstraction leaks at the various boundaries.
Yeah, Ember maybe shouldn't be recommended to beginners... I think it has some of the best documentation however (especially true in recent versions, if your codebase is pre-1.10, you're donezo though).
Also react's documentation is terribad. I'm in the middle of teaching someone who is completely new to JS how to use React, and the documentation has been horrendous (for newbies), reasons:
- JSX is super hard to properly understand if you only know HTML and JS and don't know they normally don't mix, and aren't actually mixing
- Requiring precompilation (no more JSXTransformer, no more babel-browser)
- The entire concept of components-all-the-way-down
- Documentation (Reference) section that does not differentiate between code blocks you can use and function signatures
- Hints on how to deal with routing
- No explanation of where to store data/state
I, as an experienced developer, can very easily understand React (I've used it on 2 projects now I think, and I like it), but there is so much for beginners to stumble on.
I started a new job and went from 0 JS (other than some JQuery and knowing the syntax) to 100 with Ember. Ember is really really good for beginners, grandparent talks of having to know transpiling, broccoli/task runners and livereload but doesn't understand that you need to know none of that to get working with Ember.
Write your app by editing the files ember-cli produces. No transpiling, or add transpiling with a single 'ember install' command. Who cares about broccoli, I just edit my ember-cli-build.js file with some paths and it all works. Livereload is hardly difficult to understand, with Ember you just run "ember serve" and it also all just works.