Wednesday, September 4, 2013

Ember 1.0

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.

Tuesday, September 3, 2013

Nexus 7

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.

Friday, August 16, 2013


Continuing with my theme of demo projects built on a common problem domain - a bare-bones YouTube emulator - I decided to dive into Aura.js Aura is a "clean and scalable architecture for complex JavaScript applications" that evolved from ideas put forth by Googler Addy Osmani and former Yahoo Nicholas Zakas . It provides a high-level component-based abstraction with focus on sandboxing and inter-component communication via publish/subscribe. Aura is framework-agnostic, so you can plug in popular tools like Backbone, Angular, Ember, etc. For the demo I plugged in the ever popular Backbone library.

View the demo here

View the source on github: - An Aura.js demo using Backbone.js and YouTube APIs

Friday, April 19, 2013

"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."

~Alan Kay

So my colleagues and I were having a discussion about object oriented programming (OOP) and exactly what it means today versus when the term was first coined by Alan Kay in the late 60’s. Specifically, whether prototype-based languages are truly object oriented as compared to class-based languages which are the mainstream. It’s very interesting to read Kay’s own take on the subject, and realize that what most of us consider to be OOP today resembles but little the original conception.


Tuesday, April 2, 2013

Backbone Boilerplate

I wrote a rough demo with Tim Branyen’s Backbone Boilerplate using YouTube data feeds. It’s a work in progress as I’m learning Backbone Boilerplate and its bundled LayoutManager.

Check out the demo here



Wednesday, March 13, 2013


I wrote a rough demo with Google’s AngularJS using YouTube data feeds. It’s a work in progress as I’m learning Angular.

Check out the demo here



Friday, March 8, 2013


I created a jQuery plugin wrapping Felix Gnass’ excellent spin.js. The plugin adds a background div with configurable color and transparency, and supports AMD. Check it out and let me know what you think.



Monday, March 4, 2013

Client Side JavaScript MV* With Ember.js

My team at work is evaluating the suitability of several tools for client-side application development. We’re looking at building out some non-trivial applications on the client and wanted to make the best collective, educated decision on the best tool(s) for the job.

The tools we’ve been looking at include:

  • Backbone

  • Knockout

  • Angular

  • Ember


I’ve already grown pretty familiar with Backbone, having spearheaded its adoption into our tools set a year or so ago. We’ve built out a few non-trivial applications with Backbone and admire it’s simplicity and elegance. Backbone is lean and non-prescriptive, it’s a minimalistic library that gives you the most basic structure and tools for event-based model management.