I agree. I think this is what made the success of very popular libraries (such as Jquery), but also protocols like email and the web.
I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks.
Part of the problem, I believe, is the way I learn. I usually read a quick tutorial, hack a little bit, read a bit more, hack more, read the full documentation, hack a real project (and getting into the wire of the API at this point). It's a bit oversimplified, but I believe you get the picture.
However, with Ember, it seems to me like it's hard to get started and running without having a full understanding of the full system and how everything fits together.
So yeah, in the end, maybe if you know every part of Ember and how it intrinsically work, then that's an awesome framework to work with. But for the others, like me, who learn in a more spiral-ish way, I think Ember makes it very hard to get shit done and appreciate the value of the framework.
And please, don't get me wrong, I admire programmers who can read the full documentation first.. A good analogy might be the manual (man) on Linux. I know people say RTFM all the time. But for me, it's really more about googling non-stop to get a feeling on the quickest solution for my problem.
I guess it's just a different way to learn and approaches solutions to problem. I know a couple excellent programmers who would just go reading the man and figure everything by themselves.
That being said, not sure why you're being so aggressive in your statements.. I feel you had very valid arguments but these are totally buried under this arrogance.
Funny, I felt the same way about AngularJS. I had been working for a few months with Ember. I was building a new internal tool and wanted to learn Angular but I found a lot of the concepts poorly explained in the documentation.
And I forgot that language like that simply was not accepted on this website unfortunately. However, I believe that the aggressiveness was warranted because there are quite a large number of organizations losing a lot of money on the basis of a poorly informed engineering decision.
Next time I will hopefully remember to be more political and use acceptable language when I feel so strongly about something.
Thank you for your honest comment.
I would ask that you consider, for a moment, that it is possible for someone to hold simultaneous opposing views. I also would ask for you to go back and re-read Brooks' essay about accidental and essential complexity. I believe that the choice of framework and the difficulties associated with a specific framework fall into the accidental complexity category. If after reading the essay you believe the same, then you would conclude that both choices in this thread have similar inherent merits. Such an opinion wouldn't be wishy-washy or a cop-out, but, perhaps, closer to a deeper understanding of our craft.
Every MVC framework I've used in production (Catalyst, ASP MVC, Cake, Spring, Rails, Rails with Spine, this batch of JavaScript frameworks) has had warts and frustrating moments just as all of the web languages have frustrations (Perl with maintainability, PHP with amateur hour inconsistencies, Python with tab/spaces that different IDEs will autocorrect, Rails with too much 'magic' that leads to serious bugs, Java with too much verbosity, Spring with too much XML, C# with too expensive support, Django with too many required add-on libraries, Rust with too few libraries, Go with too new, etc, etc).
Ember was not any harder than Angular to get going (ever try to untangle the service/factory/module/controller mess?). And I have no shame in admitting that I took at least three full workdays to learn each. At the end of the day the two frameworks were just different, in the same way that writing an app using JavaScript MVC is just different than how I used to write ASP MVC apps. The reason I use the newer stuff is because the newer stuff is more fun, I can be more responsive, and (in some cases) I can host an entire webapp on s3 (managing servers can be a headache). Despite some clear advantages, none of these different frameworks is inherently better. They all have tradeoffs. If Microsoft were to come to me and (with a large check) demand that I use ASP MVC, I would do so.
My first response reading your comment is that you have less experience than I do with software engineering. That may be untrue and unfair, but rash responses are correlated with inexperience from my career. I would ask you to consider your strong, aggressive reaction as unhealthy for merit-based engineering decisions. Learning and respecting that most decisions in software are about tradeoffs and not black-and-write-strictly-better-or-worse I believe will help you in your career. Furthermore, I hope you eventually come to point where you realize many of these different languages and frameworks all look the same after a while :) It's not until we can tell a computer what we what and it figures out how that our productivity will massively improve.
I am pretty sure you prefer Angular but are just too pussy to say it.
Maybe you think people will think less of you for preferring the framework that is less complex.
I assumed 'not even close' would mean this guy would be siding with AngularJS.
Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better.
What I think is that deep down people are afraid that others will think they weren't smart enough to figure out the more complex and difficult to use thing.
What I am sure of is that a system that is less complex and easier to use is better engineering.