Hey guys, please take a look at the following app: <a href="http://editgrid.com/untitled" rel="nofollow">http://editgrid.com/untitled</a><p>It's the coolest web-based spreadsheets application built 6 years ago using no library, no framework. I'm a fan of it. It was looking just like this current version 6 years ago and was pretty fast at even IE6. And its 6 years old JavaScript code follows the rules of coding good JavaScript code way more than Ember itself.<p>Here is another story: I was working for a competitor of EditGrid and built a Microsoft Excel clone with dozens of features in 6 months, using no framework, no library, 5 years ago. We were two guys at frontend and two other guys in at backend. And our source code was almost pure object orient, mixable, reusable and relying on MVC, event-driven programming.<p>I've been shipping rich web apps for more than 6 years and recently had the chance of working with both Backbone and Ember. Here is my feedback:<p>The size of Ember library is bigger than total source code (including an AI library) of the last multiplayer game I built.<p>And both of them solve no problem, simplify nothing. They just force beginners to not code crappy code and that's all. Good JavaScript code should benefit of functional programming very well, like some NodeJS apps and libraries. They got no understanding of FP. Especially Ember relies on a horrible idea that increases the cost of development very huge. Very ironically, ember code is not reusable, not mixable with other web apps. It's not even unobtrusive, pollutes Object prototypes. When you finish your app, you got a huge garbage that has not even one piece of reusable code.<p>To summarize, there is nothing Ember does right. It tries to solve already solved problems in a very absurd way and is very irrelevant with the new problems JavaScript community tries to solve (such as code-reuse with NodeJS apps, it's partly solved)<p>It's the new, communist North Korea of JavaScript world.