I think this is probably the case. The experienced devs all say “well, you can do anything”, while the newbies (to the framework, not necessarily to development) often throw their hands up in frustration. Assuming the experienced devs are not all liars or blind, this must mean that there is a lot of stuff to Ember that is really, really hard to understand properly. So, the more that can be done to improve documentation (including conceptual documentation, complete tutorials, etc.) the better.
Also keep in mind that many people’s experience with Javascript is “I manage all event handlers myself”. This leads to a lot of trouble when e.g. integrating external plugins etc. It is very important to understand how to let Ember deal with all this stuff properly.
I think it is. There’s still tons of in my opinion important open issues that haven’t been fixed yet. There’s still things missing in the ecosystem. I don’t mean this as a criticism, but to me it is obvious now that if you want something like:
- SSH deployment
- correct resolution of dynamic assets
- finding out which parts of your app contribute the most to the build size
- etc.
you have to invest a significant amount of your own work. Now, I understand we are using open source software, so I have obviously no right to expect people to do XY. And I don’t. I’m just saying that, when I chose to use Ember, I wasn’t aware of the many pieces that are still missing.
Also, a very bad side effect is that sometimes “fixes” for open issues only get released in the current Ember branch, so whenever you don’t have the latest Ember it is possible that you still have bugs / problems that would be fixed otherwise. Obviously, SemVer doesn’t cover something like that. (For an example, see this bug with Mixin / super, where a fix hasn’t been backported to older Ember versions).
I don’t know what the situation is with AngularJS. I only hear “this is so easy in AngularJS” all the time.
The context in which I wrote that was that @jasonmit wrote “you have to disconnect Ember from Ember Data” (i.e. “if you criticise Ember Data, you are not criticising Ember itself”). To which I replied that this obviously is disingeneous if Ember Data is advertised all over the place.
Also keep in mind where the criticism is coming from. It comes from people saying things like “this is super easy in AngularJS, it’s just POJOs everywhere”. And that is, I think, where we need a very open discussion about:
- why we have Ember Data at all
- what problems it tries to solve
- why you might want to opt out in particular cases (highly non-standard API, incredibly simple project with only two endpoints, or something like that)
etc. If people understand that there is a reason why ED is so incredibly complex, I think this would go a long way.