> But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy Ember.js is best

> But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy Ember.js is best technology that I've ever dropped, but let me assure you, the Tomster had nothing to do with my decision. Ember got into the spotlight when Atwood and Co. have launched the Discourse. Back then it looked super impressive - first open source forum software and arguably one of first open source apps following "JS fronted and API backend" architecture. And it was all done with Ember.js, js FW marketing itself as the modern way to build JS apps! A lot of people wanted to try it out (myself included), some moving from Angular, other from Backbone, and others coming from backend development. If Ember ever had the cool factor, it was that time. Ember.js was the next big thing, a framework for creating ambitious web applications, and all the people came to it to build their ambitious applications, looking up to Discourse as example of such application. And then those people have hit the roadblock. Ember.js's pitch was building applications, but it's documentation has never moved past explaining individual parts of technology, and into the field of how those should be put together in final application. Angular had millions of easily googleable tutorials like "this is best practice for setting page title when user enters the route" or "this is how you can configure framework to authenticate with your backend technology". I also clearly remember the "calling set on destroyed object" error that happened when you tried to update the state of object that was already destroyed that was impossible to debug, because the error was literally "Error: calling set on destroyed object" and it put world to stop. For comparision, in React.js that was "Warning: calling setState with X, Y and Z on unmounted component ComponentName". That one error was absolute productivity killer when debugging Ember.js apps from day one, and it was years before somebody from Ember.js core actually went to Ember's source code and changed "assert !obj._is_destroyed 'calling set on destroyed object'" to "assert !obj._is_destroyed 'calling set on destroyed object'". There was always bigger fish to fry for Ember.js core team, who were so bussy making blogpost after blogpost of new great features or API changes happening, while being oblivious to comments below those same blogposts asking "can I now do partial updates on models because they are super costful to update?" or "is calling set on destroyed object fixed yet?". And then guys from their ambassador product, Discourse, started writing blog posts following the pattern of "Here's how we've replaced Ember.js's feature with our one because framework's didnt work", and those involved things like `Ember-Data` or Ember views.