Earlier this year I was evaluating Ember.js along with several other frameworks/libraries for some projects at work. At the time, pre-1.0, I found Ember promising but frustrating due to its steep learning curve, frequent breaking changes and documentation that was inadequate and out-of-sync with the codebase. Still, I found much to admire in Ember's approach, as I noted in a previous post.
One thing that struck me almost immediately was a strong push back from the Ember principals against AMD. The most prominent example was Tom Dale's blog post 'AMD is Not the Answer', which drew some impassioned responses including this one and this one from RequireJS creator James Burke. Having incorporated AMD into my toolbox early on, I find the necessary boilerplate a very reasonable tradeoff in return for concise modules with explicitly stated dependencies, available in the browser.
You can imagine my surprise confusion amusement then, when I read the Ember 1.0 announcement the other day and found this gem:
Today, tools like require.js and module systems like AMD, Node, and ES6 Modules continue to gain traction. Increasingly, people are using named modules and module loaders rather than storing their code in globals.
To prepare for this future, all of the code lookup and naming conventions in Ember.js now go through a single Resolver. The default Resolver still looks for code under global namespaces, but Ember App Kit already provides an alternative resolver that looks for code in AMD modules.
This quote from the Ember official blog is actually a little misleading. A closer look at the Ember App Kit reveals that it supports ES6 module syntax, which is then "transpiled" to AMD syntax via the ES6 module transpiler. Still, this is a far cry from Tom's blog post and likely reflects the widespread adoption of AMD in the developer community around Ember.
With Ember reaching 1.0 status as of August 31, I'm taking another look to see if the stability, module support, and documentation have improved. I'll build out a demo app with the same Youtube emulator domain as other recent demos for side-by-side comparison of a fairly simple but non-trivial example application across frameworks/libraries. I'll post the source on github and link here when it's done.
