Ember, more strongly than any of the other solutions mentioned, pushes you to a browser application (or SPA) architecture. Usually developers who complain about bloat aren't thinking of web development in that context.
The number of challenges a framework should help a developer manage for a long-lived client-side JavaScript application is not trivial. It is absolutely true that Ember is heavier than other frameworks, but it has a specific style of development in mind. If someone chooses to build their app with an alternative, they often end up with a similar amount of code in other dependencies and application code.
And though we aren't there yet, we're working on ideas for modular loading of application code (via the pods patterns) and of Ember itself via tree shaking. This latter strategy leverages the fact that Ember's code and much app code is written in ES6, and thus we can identify and drop un-referenced code.
Oh look that object extends another class... apparently it uses Mixin to extend these classes maybe the apply function? If it's using prototype inheritance than looking up the prototype chain would be a performance hit IIRC.
I was doing Ember while during beta though. But during that time they were marketing Ember as smaller library and more performance than Angular.
The last bench mark I've seen, Ember library is much bigger and the performance was not that great compare to Angular...
I'm not certain if it's bloated, and if I was building a regular CRUD app I would probably have selected it over Angular. It just implemented some things I had the feeling I would do differently, i.e. I didn't want to pick a framework I would have to fight to get to work the way I wanted it to. Ember is being developed by some very smart guys so I would never dismiss it out of hand.
The number of challenges a framework should help a developer manage for a long-lived client-side JavaScript application is not trivial. It is absolutely true that Ember is heavier than other frameworks, but it has a specific style of development in mind. If someone chooses to build their app with an alternative, they often end up with a similar amount of code in other dependencies and application code.
And though we aren't there yet, we're working on ideas for modular loading of application code (via the pods patterns) and of Ember itself via tree shaking. This latter strategy leverages the fact that Ember's code and much app code is written in ES6, and thus we can identify and drop un-referenced code.