![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh57-dLh9praezxkRllkGQ4VGxH2cZL5znl741HHEOQ9XdqH_JdFB2-L1FVmPvrbwHaBGd8OhKoyw8pSi7w9BSPc4VJI9QaPAVuBarN2HbmIaw9VAmd6YfbIQtqlRNSitlF3hOa5FLIw/s320/IMG_5987_sm.jpg)
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2qXpBcCj_g3IE2Ahltf4itdEJcmM7zq_MRajhBSIHy8CxQwxbiMeJg3f4CO9Ilx9NHbFs2gw0618M5ho2LCNHxY8pfrOORywufR5pFTEjK4PX6PH_MRhgWdcJBWTEz2-1gTjeWLLNJQ/s320/IMG_5985_sm.jpg)
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.
So I finally bit the bullet and bought a tablet. After hanging back looking at various offerings I decided to get the new Nexus 7 from Google/Asus, mainly for its combination of low price point and excellent reviews/features.
I bought it mainly for fun/casual use but want to tinker a little also, so I paired the Nexus 7 with a Microsoft Wedge bluetooth keyboard and mouse, and installed the kWS Android web server and DroidEdit so I can do bare-bones web development right on the tablet.
I've only had the device for a few days and am still finding my way around, but so far I'm pretty happy. I'll try to post a detailed review soon.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them."