At the core of any web application is a mapping between urls and application logic; a mapping between what is in the browser’s address bar and what should be displayed on the screen. Rails has routes.rb, Django has URLconf, Backbone.js has controllersBackbone.Router, and Sammy.js has Sammy.js.

We also aren’t talking about arbitrary URLs here. Modern well-designed applications use clean, semantic, and probably RESTful urls. These are urls which are human-readable, have a natural hierarchy to them, and intuitively reflect the underlying data to which they relate.

So, what’s the problem?

Problem: Routers Are Designed for Stateless Servers

Historically, url routing systems are designed for web servers which maintain little to no state about the client which is making the request¹. A typical request/response lifecycle would look something like the following:

1. A url is requested.
2. The server loads all resources corresponding to the url.
3. A response is rendered and sent back to the client.
4. All server-side resources are released.

By not maintaining state, the server is able to drastically reduce its memory-footprint. With this scheme in mind, it makes sense for routing systems to be nothing more than a mapping from url patterns to actions, an example of which is represented in the diagram below:

Here there are four different actions: index, show, edit, and comments, with corresponding url patterns. When a url for one of these actions is requested, the application must load the resource or collection, ensure that the current user has the required permissions to view the page, and render one or more templates.

These days, however, many applications are moving away from the server and into the realm of the client-side single page javascript application. Views are no longer being rendered on the server, pages are no longer being refreshed on each request, and urls are being manipulated through hashes and HTML5’s pushState method. Javascript MVC frameworks such as Backbone and Ember have also arrisen to make these types of applications more pallatable to develop.

State is Ridiculously Cheap on the Client

Most client-side javascript applications probably have access to more memory than the virtual machines that serve them. Much like programming for the desktop, one of the great benefits of single-page javascript apps is that you can freely maintain as much state as you want.

Despite this, javascript routing system are still beholden to the same approach used by stateless servers. Routes are still nothing more than a primitive map from patterns to functions, and the above diagram still applies. This is barbaric. In the context of a client-side application, the url-triggered actions of loading models, checking permissions, and rendering shared layout have become extremely redundant.

Solution: Stateful Routes

A solution for this is to incorporate a more stateful approach to routing. Common state between actions can be extracted into additional states. Consider the following re-factorization:

The above diagram still captures that same url structure as the first diagram, but an intermediate state has been created which encapsulates some common logic. The show, edit, and comments actions all share a parent item state. The item state has some common concerns inside of it that are shared by all its children. Namely, the loading of the resource corresponding to the id, checking read permissions, and loading a common layout.

The idea here is that each leaf state corresponds to a route and as a route is loaded, each state along its path from the root is entered. Edges between states correspond to optional url fragments. Thus, when the url is changed to items/1, both the item and the show states are loaded. Similary, when the url is changed to items/1/comments, the item and comments states are loaded.

So far you might be relatively unimpressed. Sure this is a nice declarative approach to moving some cross-cutting concerns into a better location, but it could be argued that something like controller inheritance could accomplish the same thing. Bear with me.

Stateful Transitions Are Awesome

This becomes really cool when you take into account transitioning from one state to another. For instance, consider the transition on the client from the url items/1 to items/1/edit. This corresponds to a transition from the show state to the edit state. This is captured in the diagram below:

Since both the show and edit states share a common parent state, there is no need for it to be re-entered. All of the concerns inside the item state have already been addressed and it is trivial for the client to know to just change the view.

Transitions between states can also be dicated by more than url fragments. States can be defined by whether a user is logged in, if a post has been published, if the user is an admin, etc. This makes it extremely easy to turn off or provide alternate behavior for entire groups of routes based on application state. Just for fun, here is a diagram for such a case:

Here, there are different routing trees depending on whether the user is logged in or not.

Ember.js RouteManager Plug

This is the part of the blog post where I shamelessly plug a project, Ember RouteManager, which is routing system for Ember.js built with the design I have given in this post. I’m not going to include any code samples here, but I recommend you check it out!

Having used Ember.js for a few months now, I have compiled a list of gotchas that I have encountered. Many of these will change/be fixed as Ember matures, but until then I hope these will serve as pre-emptive time savers for other developers.

1. Computed Properties and .cacheable()

This one has actually been fixed in the lastest build of Ember, but I’m putting it here since it is still present in the latest 0.9.5 release. Consider the following object:

1
2
3
4
5

var object = Ember.Object.create({
  tags: function() {
    return [];
  }.property()
});

It turns out that if you try and bind to the tags property of the above object, you will encounter an infinite run loop. Any computed property which does not return a primitive value will suffer from this, the underlying cause being due to failing equivalence tests. This fix is to add a call to cacheable() to the end of the computed property:

1
2
3
4
5

var object = Ember.Object.create({
  tags: function() {
    return [];
  }.property().cacheable()
});

Even though the infinite loop issue has been fixed, making computed properties cacheable is generally a good idea and will be more the rule than the exception.

2. firstObject and lastObject

These properties of enumerables are not bindable. Although this was intentional for performance reasons, this is quite unexpected and I hope this to be fixed in the future. For now, you can create a custom computed property as a substitute:

1
2
3
4
5
6

var myController = Ember.ArrayController.create({
  ...
  firstItem: function() {
    return this.getPath('content.firstObject');
  }.property('content.@each').cacheable()
});

3. Combining Static and Dynamic CSS Class Names

It will often be the case that you want an element inside a handlebars template to have both a static css class name as well as class name that is the result of binding to a property. In order to do this in version 0.9.5, use the code below:

1

<div {{bindAttr class="myProperty:dynamicClass alwaysTrue:staticClass"}}></div>

This code will add the dynamicClass class to the div when myProperty is true. The alwaysTrue property is a property you define that always evaluates to true; this will ensure that the div always has the staticClass class.

In the latest build of ember, a shorthand has been created for this:

1

<div {{bindAttr class="myProperty:dynamicClass :staticClass"}}></div>

Specifying just :staticClass (without the alwaysTrue property) will have this same effect.

4. Bound Handlebars Helpers

As it currently stands, handlebars helpers inside of Ember are just normal helpers. They do not have any of the secret sauce which makes them automatically update when the properties they depend on change. In order to make helpers bound to properties, you must add the magic in yourself.

Fortunately, I have created a gist which packages this functionality up into a convenient syntax that is similar to computed properties:

To define a bound helper this way, do something like the following:

1
2
3
4

Ember.registerBoundHelper('currency', function(value, options) {
  if(!value) return ""
  return "$" + value.toString().replace(/(\d)(?=(\d\d\d)+(?!\d))/g, "$1,")
});

Now you can use this inside of any of your handlebars templates:

1

<span>{{currency myProperty}}</span>

The helper output will auto-magically update when the value of myProperty changes.

5. Each Blocks, Indices, and Metamorph

This one can be very inconvenient at times. Ember’s {{#each}} helper does not provide access to an index property. This can make things such as styling cumbersome. The situation is also compounded by the fact that the DOM-binding library that Ember uses, Metamorph, also adds html metadata (in the form of script tags) to the dom that can break certain CSS selectors.

Consider the following handlebars template:

1
2
3
4
5

<ul>
{{#each myArray}}
  <li>{{this}}</li>
{{/#each}}
</ul>

This template loops over the enumerable myArray and outputs its contents into list item elements. One would intuitively expect to be able to use the :first-child CSS pseudo-selector to give the first element in the list a particular style, but this is not the case. Upon inspecting the DOM, it will be noticed that there is a <script> tag before the first element. In order to work around this, use the nth-of-type pseudo selector.

In some cases, however, using a CSS workaround will not be sufficient and having access to the item array indices will be required. Ultimately, I hope an eachWithIndex helper makes it into Ember’s core, but for now the underlying data must be altered to contain the indices. One easy way of doing this is to create a computed property to this end:

1
2
3
4
5

  myArrayWithIndices: function() {
    return myArray.map(function(i, idx) {
      return {item: i, index: idx};
    });
  }.property('myArray.@each')

The above template could now be rewritten to include indices:

1
2
3
4
5

<ul>
{{#each myArrayWithIndices}}
  <li>{{this.index}}. {{this.item}}</li>
{{/#each}}
</ul>

6. Object Default Value Initialization

The way default values for properties work in Ember is somewhat different from many other languages/frameworks. This will be especially unintuitive for people coming from more traditional object oriented languages such as Java.

Consider the following snippet:

1
2
3
4
5
6
7
8
9
10

var Category = Ember.Object.extend({
  tags: []
});

var animals = Category.create();
var reptiles = Category.create();

animals.get('tags').pushObject('warm-blooded');

console.log(reptiles.get('tags')); // unexpectedly outputs ['warm-blooded']

In the above example both animals and reptiles share the same tags array. In Ember, object property initialization only runs once per class definition. To get around this, you must either move default value initialization into the init method or just re-define the entire array for each instance:

Fix #1:

1
2
3
4
5
6
7
8
9
10
11
12
13

var Category = Ember.Object.extend({
  init: function() {
    this._super();
    this.set('tags', []);
  }
});

var animals = Category.create();
var reptiles = Category.create();

animals.get('tags').pushObject('warm-blooded');

console.log(reptiles.get('tags')); // outputs []

Fix #2:

1
2
3
4
5
6
7
8
9
10
11

var Category = Ember.Object.extend({
});

var animals = Category.create({
  tags: ['warm-blooded']
});
var reptiles = Category.create({
  tags: []
});

console.log(reptiles.get('tags')); // outputs []

Everything I just said also applies to any non-primitive property, such as objects.

7. Metamorph Metadata

Ember plays nicely with other frameworks. For the most part. Sometimes Metamorph gets in the way. For instance, any framework which reliess on cloning DOM elements will probably have some issues (such as jQuery UI’s draggable).

A workaround for this is to clone the element with all of the Metamorph metadata removed. Fortunately, once again I have a gist for this:

8. Run Loop Debugging With Chrome

This one is somewhat more obscure and particular only to Chrome. Ember has the concept of a run loop which batches bindings and does some other neat stuff. Generally speaking, you won’t have to know much about it, except when you do.

When inside the run loop, Ember wraps everything in a try/finally statement (with no catch). In theory this should not affect anything, but Chrome has a particularly nasty bug where the console will swallow uncaught exceptions if they go through a finally (and will also not call window.onerror).

The easy workaround for this is to set Chrome to automatically break on uncaught exceptions, but worth mentioning since there is nothing worse than having to discover exceptions through side effects.

If you’ve been following the Javascript MVC landscape lately, you might have noticed a growing tension between Backbone.js and Ember.js. Being championed by Jeremy Ashkenas and Yehuda Katz respectively, both frameworks reside in decidely different camps. Ember.js favors deep abstraction and sensible defaults, whereas Backbone.js embraces the micro-framework mentality of providing a minimalist set of features whilst encouraging integration with a wide variety of other frameworks.

The most recent evolution of the debate, however, has resided around performance. An animation benchmark comparing the two frameworks was posted on Hacker News yesterday. Despite being a contrived example, the results of the benchmark are undisputable: Backbone.js is significantly faster than Ember.js - and by a visible margin. The reason for this is the computational overhead incurred by Ember’s view binding system. A core feature of Ember is a rich, bindable and composable view system which has been designed to simplify common programming tasks. Simply put: Ember.js has been built to make development easier.

Of course Ember.js could be optimized and the gap in the benchmark could be narrowed, but that is moot. What is really happening here is the age old dispute of developer productivity versus application performance. New technologies are constantly being introduced which make the lives of developers easier and encumbent technologies will always defend their trenches. The easiest thing for existing technologies to point at is performance - as grander abstractions naturally incur larger overheads. These might be a little more stark than the Ember vs. Backbone debate, but here are some examples that immediately come to mind:

1. Assemby vs. C: When I was younger, our family computer had a great operating system installed called GEOS). It was a really nice piece of software. Only later in life did I learn that it was written almost entirely in 8086 assembly language. Despite being written in the ultimate low-level language, it ultimately became a slower product than its competitors and part of its demise was due to system complexity.

2. Java vs. C++: When Java was first introduced, it was ridiculed for being extremely slow. Over time, especially in the post-JIT era, it has gained the opposite reputation. In today’s landscape, the JVM is considered one of the faster platform choices, even exceeding C++ in some benchmarks.

3. Static vs Dynamic: Among other things, dynamic language skeptics have always pointed a finger at performance. Even today, lanuages like Ruby and Python are still an order of magnitude slower than some of their static counterparts. Despite this, frameworks like ROR and Django are industry norms. Javascript itself has also defied people’s beliefs and expectations as projects like V8 have taken it to the next level.

There are two things going on here:

The first is summarized succintly by Steve Yegge: “Global optimizations always trump benchmarks.” Even if a framework/language is slower at a granular level, a system with an overall reduced complexity will still run faster. I would much rather live a world where I can do more faster while at the same time benefitting from global optimizations introduced transparently by the framework itself than one where I consciously chose to sacrifice convenience for performance.

Second, slow is relative. It is important to know when performance matters and when it doesn’t. Databases, real-time systems, and heavily trafficked servers clearly benefit from saved cycles. Apparently it makes sense for CouchDB to move to C/C++ from Erlang, but there are also a lot of situations where performance just simply doesn’t matter that much.

The realm of client-side development is a perfect example of this. Where else do you have essentially unbounded access to a modern CPU in order to scale an application to all of a single user? If anything, in most cases there is a glut of CPU resources that are under-utilized. In the case where you absolutely need to ensure a complex animation runs smoothly, any good framework will allow you to break away from its shackles and apply some manual optimization (you should probably be exploring something like WebGL in this case anyways). There are very few reasons to prematurely optimize for performance in client-side web developement.

In all fairness, Ember.js still does have work do to in the performance area and is actively being developed. Backbone.js is also a great framework and a good choice for a number of applications. At the end of the day, however, to fundamentally criticize a javascript framework for being slow is really to suggest that we have reached the limits of front-end web development. I sincerely hope that is not the case. We should all be striving as developers to make our lives as easy as possible. I personally hope that Ember is just the tip of an iceberg and that even more feature-rich, abstracted, and *gasp* possibly slower frameworks are on the horizon.

I am long on Ember.js. I previously wrote a brief comparison of some of the more popular javascript frameworks, and Ember came out on top. I am now in the process of incorporating it into GroupTalent in a big way.

Due to the recent origins of Ember, one of its biggest shortcomings is a serious lack of documentation. Its website and some related blog posts focus only on the basics and hello world type examples (read todo in the js mvc world). A major reason for this is that the patterns required for a complex application have not yet been added to the core Ember.js codebase. That is not to say, however, that complex Ember.js applications are not already being built.

With that in mind, I have decided to write a series of posts detailing some of the libraries and patterns I have been using for Ember development. In this post, I cover creating a multi-page application: all that is required to swap out different pages and sub-pages as well as tieing everything in to the browser location and the HTML5 history API. Specifically I discuss two libraries that I have written, Ember Layout and Ember RouteManager. You can also skip ahead and see an example application in action.

Meet The State Manager

A core construct inside of Ember is the notion of states managed by a state manager. This is used in many places inside the Ember.js codebase, including managing view render states. Thus, it is only natural for this construct to be used to manage the composition of views as well.

In fact, Ember already has primitive support for managing views inside it’s core. You can do the following:

1
2
3
4
5
6
7
8
9
10
11
12
13

App.stateManager = Ember.StateManager.create({

  rootElement: '#content',

  section1: Ember.ViewState.create({
    view: App.section1
  }),

  section2: Ember.ViewState.create({
    view: App.section2
  })

});

Setting the stateManager’s state to section1 will automatically append the App.section1 view to the element selected by #content. If the state is then set to section2 the old view will be removed and replaced by App.section2.

This is sufficient for extremely basic applications, but breaks down when the demands are more complex. This method is restricted to view hierarchies that are only a single level deep - most often not the case. The canonical example of this is a page with a primary navigation and a sub-page that has its own tabbing system. What is really needed here is a way to dynamically nest views arbitrarily deep.

Layouts

Ember Layout adds an intuitive layout mechanism on top of Ember.js. You can see it in action here. It adds the concept of a handlebars {{yield}} helper which can be used to indicate insertion points of dynamically replaceable content. This should be extremely familiar to anyone with a rails background, but with the added notion of being dynamically replaceable.

Here is a code snippet extracted from the example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

App.main = Em.LayoutView.create({
  templateName: 'main'
});

App.routeManager = Em.RouteManager.create({
  rootLayout: App.main,
  ...
  layoutNesting: App.NavState.create({
    ...
    viewClass: Em.LayoutView.extend({
      templateName: 'layout-nesting',
    }),
    section1: App.SubNavState.create({
      ...
      viewClass: Em.View.extend({
        title: 'Section 1',
        templateName: 'section'
      })
    }),
    ...
  })
});

And the corresponding template code:

1
2
3
4
5
6

<script type="text/x-handlebars" data-template-name="main">
  ...
  <div class="container">
    {{yield}}
  </div>
</script>

1
2
3
4
5
6

<script type="text/x-handlebars" data-template-name="layout-nesting">
  ...
  <div class="sub-container">
    {{yield}}
  </div>
</script>

When the routeManager (i.e. StateManager) goes to the layoutNesting.section1 state, a view instance specified by the viewClass property of the layoutNesting state is inserted into the {{yield}} location in the main template. This newly inserted view also has its own {{yield}} location, which is replaced by the view from the section1 state. Switching to a different state will then automatically reconstruct this view hierarchy.

Routing

At the crux of any single-page web application is a routing system. Although Ember doesn’t natively include/endorse any particular routing system, it plays well with almost anything out there. Options include SprouteCore Routing and Sammy.js.

Ideally, however, due to Ember’s proclivity towards states, a state-based routing solution seems like the most natural fit. This makes even more sense when taken in the context of the view composition system already being state-based.

Ember RouteManager is exactly that, a state-based routing solution. It introduces an extension of StateManager called RouteManager. Consider the following code (irrelevant parts snipped) from the example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

App.routeManager = Em.RouteManager.create({
  rootLayout: App.main,
  home: App.NavState.create({
    ...
  }),
  layoutNesting: App.NavState.create({
    path: 'layout-nesting',
    ...
    section1: App.SubNavState.create({
      path: 'section1',
      ...
    }),
    section2: App.SubNavState.create({
      path: 'section2',
      ...
    }),
    ...
  }),
  routeParameters: App.NavState.create({
    path: 'route-parameters',
    ...
    items: Em.LayoutState.create({
      ...
    }),
    item: Em.LayoutState.create({
      path: ':itemId', // specify the path to take a parameter
      ...
    })
  })
});

I’m not going to go into detail here, but suffice it to say that each possible route is captured as a leaf node in the state tree. State’s can have an optional path property which dictates how the routes map to states in the routeManager. Paths can consist of dynamic parameters (:parameterName), wildcards (*), regular expressions, and static paths. For example, from the above code: setting the browser location to #/routeParameters/5 would map to the routeParameters.item state with the :itemId parameter being populated by 5. Since these states are also layout states, this will also automatically update the view hierarchy as well.

The beauty of this approach is the de-coupling of application state from absolute routes. For some reason, many frameworks enforce a holistic view of the routing system, treating it as a list of mappings from routes to actions. With RouteManager’s approach, state definitions are agnostic to the parts of the route corresponding to their parent, and instead only focus on their local part.

Much of the code inside RouteManager is originally based on SproutCore routing. Thus, it can also use the HTML 5 history api by setting the wantsHistory property.

Caveat

The caveat here is that what I am describing is likely to change as Ember.js evolves. The libraries I have presented are still immature and more conceptual than fully formed. Ultimately Ember’s core will have a solution for this and I will update this post when that is the case.

Stay tuned for the next post in this series where I cover data persistence.

1. Static content should be served statically
2. Disqus rocks
3. Ruby
4. Google rewards fast loading times
5. Markdown
6. Flat files are awesome
7. Sass
8. Compass
9. HAML
10. GitHub Pages
11. This guy did it
12. Linode disk alerts are annoying
13. No more caching plugins
14. Hacker cred
15. Security
16. Octopress Classic is the new Kubrick
17. Built on top of Jekyll
18. Web interfaces suck at content creation
19. Easily preview locally
20. Version with GIT
21. Compose in VIM
22. Wordpress has customer service
23. Score 93/100 instead of 55/100 on PageSpeed
24. Happiness as a developer
25. This Graph:

In case it’s not obvious, I spent some time migrating this site over to Octopress.

UPDATE 1/14/2012: Added Batman.js and Angular.js due to popular demand and because they looked impressive.

Over the last several months I have been in a constant search for the perfect javascript MVC framework. Driven by a dire need for the right level of abstraction and features, I have tried out - some more cursorily than others - every framework I could get my hands on. Here lies a brief synopsis of each framework. Lastly, I share the framework which I ultimately decided on.

Specifically, the following four features are very important to me:

• UI Bindings - I’m not just talking about templates, I’m talking about a declarative approach to automatically updating the view layer when the underlying model changes. Once you have used a framework (such as Flex) that supports UI bindings, you can never go back.
• Composed Views - Like all software developers, I enjoy creating modular reusable code. For this reason, when programming UI, I would like to be able to compose views (preferably at the template layer). This should also entail the potential for a rich view component hierarchy. An example of this would be a reusable pagination widget.
• Web Presentation Layer - We are programming for the web here people, the last thing I want are native-style widgets. There is also no reason for a web framework to create it’s own layout manager. HTML and CSS are already the richest way to do style and layout in existence, and should be used as such. The framework should be centered around this concept.
• Plays Nicely With Others - Let’s face it, jQuery is pretty amazing. I don’t want a framework which comes bundled with a sub-par jQuery clone, I want a framework which recommends using jQuery itself.

The Contenders

Here is a table showing all of the frameworks support for the above features. Click through the title for more detail.

1. Backbone.js

Backbone.js is the web’s darling framework. You can’t go anywhere without hearing about it and they have an impressive list of brands using it. This was naturally one of the first frameworks I tried. I used it to build some of our internal administrative features at GroupTalent.

Pros: Strong community and lots of momentum. Underscore.js (which it uses heavily) is also a great framework.

Cons: Lacks strong abstractions and leaves something to be desired. The entire framework is surprisingly lightweight and results in lots of boilerplate. The larger an application becomes, the more this becomes apparent.

2. SproutCore 1.x

SproutCore is what Apple used on its iCloud initiative. Despite having a horrible name, it is actually an extremely well thought out framework. It is also one of the largest frameworks.

Pros: Bindings support. Solid community. Tons of features.

Cons: Overly prescriptive. Hard to decouple from unneeded features. Forces a native-like paradigm. I have a serious problem with any framework which discourages using html for layout.

3. Sammy.js

Sammy.js was a smaller framework that I stumbled upon. Due to its simplicity, it almost didn’t make this list. It’s core feature is a routing system to swap out areas of an application with AJAX.

Pros: Simple learning curve. Easier to integrate with an existing server side app.

Cons: Too simple. Not sufficient for larger applications.

4. Spine.js

Based on the name, Spine.js is obviously heavily influenced by backbone. Like backbone, it is very lightweight and follows a similar model.

Pros: Lightweight with good documentation.

Cons: Fundamentally flawed. A core concept of spine is “is asynchronous UIs. In a nutshell, this means that UIs should ideally never block”. Having built a serious non-blocking realtime application in the past, I can say this is entirely unrealistic unless the backend has something like operational transformation.

5. Cappuccino

Cappuccino is one of the more unique frameworks, coming with its own language Objective-J. Cappuccino tries to emulate Cocoa in the browser.

Pros: Large thought-out framework. Good community. Great inheritance model.

Cons: Out of all the languages you could emulate in javascript, Objective-C would be my last choice. This is coming from an iOS developer. I simply can’t get past the idea of programming Objective-J in the browser.

6. Knockout.js

Knockout.js is an MVVM framework that receives lots of praise from its supporters. It stresses declarative UI bindings and automatic UI refresh.

Pros: Binding support. Great documentation and amazing tutorial system.

Cons: Awkward binding syntax and lacks a solid view component hierarchy. I want to be able to reuse components easily. I also feel like identifying as an MVVM framework is deleterious. Hardly any of these frameworks are MVC, but are of the MV* variety (MVP, MVVM, etc).

7. Javascript MVC

Javascript MVC, in the interest of full disclosure, is a framework that I didn’t spend very much time evaluating.

Pros: Solid community and legacy.

Cons: Awkward inheritance model based on strings. Controllers are too intimate with views and lack bindings. The name is way too generic - the equivalent would be if RoR was called “Ruby Web Framework”.

8. Google Web Toolkit

GWT is a serious client-side toolkit that includes more than just a framework. It compiles Java to Javascript, supporting a subset of the standard java library. Google used it internally for Wave.

Pros: Comprehensive framework with great community. Solid Java-based component inheritance model. Great for behemoth client-side applications.

Cons: Despite what Google says, GWT is not going to stand the test of time. With initiatives like DART its clear that Java is not the future of the web. Furthermore, the abstraction of Java on the client is slightly awkward.

9. Google Closure

Google Closure is more of a toolkit than simply a javascript framework. It comes bundled with a compiler and optimizer.

Pros: Use by Google for many of their major apps. Nice component-based ui composition system.

Cons: Lack of UI-binding support.

10. Ember.js

Ember.js (formerly Amber.js SproutCore 2.0) is one of the newest contenders. It is an attempt to extricate the core features from SproutCore 2.0 into a more compact modular framework suited for the web.

Pros: Extremely rich templating system with composed views and UI bindings.

Cons: Relatively new. Documentation leaves lots to be desired.

11. Angular.js

Angular.js is a very nice framework I discovered after I originally posted this review. Developed by Googler’s, it has some very interesting design choices.

Pros: Very well thought out with respect to template scoping and controller design. Has a dependency injection system (I am a big fan of IOC). Supports a rich UI-Binding syntax to make things like filtering and transforming values a breeze.

Cons: Codebase appears to be fairly sprawling and not very modular. Views are not modular enough (will address this in more detail in the cons of Batman.js).

12. Batman.js

Batman.js, created by Shopify, is another framework in a similar vein to Knockout and Angular. Has a nice UI binding system based on html attributes. The only framework written in idiomatic coffeescript, it is also tightly integrated with Node.js and even goes to the extent of having its own (optional) Node.js server.

Pros: Very clean codebase. Has a nice simple approach to binding, persistence, and routing.

Cons: I very much dislike singletons, let alone the idea of enforcing singleton controllers. Suffers from the same ailments as Knockout and Angular with regards to nested components. I want to be able to declaratively reuse more than just templates. What Ember has over these frameworks is a way to declaratively re-use entire components that are backed by their own (possibly controller-level) logic.

The Winner

At the end of the day, Ember.js is the only framework which has everything I desire. I recently ported a relatively small Backbone.js application over to Ember.js and, despite some small performance issues, I am much happier with the resulting code base. Being championed by Yehuda Katz, the community around Ember.js is also amazing. This is definitely the framework to watch out for.

Of course this list is far from comprehensive. Almost all of these frameworks here were discovered by sheer notoriety, word of mouth, or by being mentioned on Hacker News. I am also not reviewing proprietary frameworks (or frameworks with disagreeable licenses - ExtJS anyone?).

What MVC framework do you use?

A while back I stumbled upon a great post by Jean-Baptiste Queru. It describes the incredible depth of the modern technology stack. Layers upon layers of complex science, hardware, and software, each layer creating a simpler abstraction around the previous. This ultimately enables our paltry human brains to create amazing things that would otherwise be impossible (or really difficult). This is, in my opinion, the lifeblood of modern software development.

For some reason, however, when it comes to front-end web development - meaning javascript - the stack is extremely shallow. Most websites are built on top of native browser functionality with a sprinkling of jQuery and little else. Moreover, this is true even to the extent that it is embedded in the developer culture itself. Javascript frameworks are lauded for their small sizes and even smaller feature sets. Sites exist exclusively to categorize and compile lists of these “micro-frameworks”, exacting requirements of less than five kilobytes.

This is not to say that significant value can’t be created by a framework with a small codebase. However, given the choice between two frameworks with equally well-written code, I would probably opt for the larger framework¹. Choosing a framework for its small size is a premature optimization. Taking this a step further, given a choice between tying together two unrelated “micro-frameworks” and one larger framework, I would definitely opt for the latter.

Tom Dale begins a similar post with the following:

Why does it take big teams, big budgets, and long timelines to deliver web apps that have functionality and UI that approaches that of an iPhone app put together by one or two people?

Although I’m not going to comment on the number of people required in either case, I completely agree with the implicit assertion that mobile development is more efficient. As a developer who has been building desktop, web, and mobile applications for years, I have always felt that, specific to web development, a larger amount of energy goes towards dealing with the frameworks involved, rather than the problem being solved. There is also an uncomfortable, almost nauseating, feeling that my code is not as modular and reusable as I would like and have come to expect from other development stacks.

The reason for this is that javascript frameworks are simply too small and unstructured. Client-side web developers are not building atop strong enough abstractions to bring their efficiency up to par. Even backbone.js, the web’s darling client side javascript framework, weighs in at a mere 4.6kb. Having built an application against backbone, I can attest to the fact that it more closely resembles a philosophy or set of guidelines to develop against rather than a full fledged UI framework.

Yes, I know larger javascript web frameworks exist. SproutCore, Cappuccino, and Google Web Toolkit come to mind. I hear good things about all of these frameworks. However, none of them have come to the level of ubiquity that one would hope. They all suffer from similar ailments: being constraining and forcing a particular native-like paradigm. For instance, there is no reason for a web framework to implement it’s own layout manager. HTML 5 is probably the richest layout system in existence and most modern heavily-designed web applications prefer direct access.

I am constantly searching for a modern client-side javascript framework that has the right level of abstraction. Today, I am extremely excited about Ember JS (formerly SproutCore 2.0). It adds some deep layers of functionality without the constraints and bloat of the original SproutCore. I think it will continue to evolve into an amazing framework. For the future, I am excited about initiatives such as DART. Despite receiving a lot of negative criticism, DART looks promising as a new language for the web (although I would have preferred a raw VM). Particularly, I feel that the awkwardness around implementing packages and re-usable code in Javascript is partly to blame for the current state.

In any case, as web applications continue to become increasingly complex, the emergence of larger and richer frameworks is inevitable - and it’s about time.

My first Android creation was a game called Vocabulary Builder. The gameplay is simple: match words with definitions and vice versa. It has multiple skill levels, tracks your progress, and has a built-in dictionary.

Today, it is the number one Google search result for Android Vocabulary Builder, has a 4/5 star rating, and has around 100k installs. It is monetized with ads and a 99 cent ad-free pro version. Being as this is Android, this translates into me having made roughly $100 dollars from it throughout its entire lifetime. No, seriously. Despite cleverly sneaking ads in between definitions, it’s CPM is practically nothing (an order of magnitude less than some of my iOS games) and of the 100k installs, a whopping 82 have converted to pro users.

But that is neither here nor there. What is interesting (and hopefully worth sharing), is the analytics data that has been collected. Using a free Google App Engine account, I have collected the anonymized result of every single question (within the free account quota). This equates to over a million data points. Ironically, due to the size of the data set, in order to bulk download all of this data in a timely fashion, I had to temporarily upgrade to a paid account. Here I share the toughest and the easiest vocabulary words.

The 25 Toughest Words

To qualify this data, the dictionary used in the game is based on a well known list of difficult GRE-style words. It is not based on the entire English dictionary.

Interestingly, most of these words are not that uncommon, but are clearly used in the context of their 2nd or 3rd definition.

The 25 Easiest Words

For contrast, here is the other end of the spectrum:

If you are reading this and you are interested in word games, check out some of my other titles: Beworded (Android Market, App Store) and Word Topple (App Store).

Today I am launching Misunderstood Pigs (iTunes Link). The gameplay is simple: place objects to save the pigs from an impending onslaught of projectiles.

I had been sitting on this game at 90% completion for at least 5 months, and decided to bite the bullet and spend a few days finishing the last 10%.

The game shares a lot of code from my previous release, Word Topple, including a level editor/framework which is tightly integrated with Adobe Fireworks (which I am debating open sourcing).

Enjoy!

HTML and CSS has always been filled with frustration when it comes to being able to intuitively create layouts and designs. Web developers have long since sacrificed ease of implementation for accessibility and semantic purity. Basic layouts and simple aesthetics frequently require very non-trivial implementations. This is especially apparent to developers who have tasted the forbidden fruit of other platforms such as Flex, Android, et al.

Until the near future. Two CSS 3 features in particular are finally solving this in a major way, making web design palatable to the code minimalist in all of us.

Flexible Box Layouts

The CSS 3 spec has introduced a new module which is supported by all major non-IE browsers as well as the IE 10 preview. This module is the Flexible Box Layout.

Gone are the days of forcing a layout into a float-based implementation. No more negative margins, excessive floating, and clear fixes. This also eliminates the added complexity of having to take into account margins, padding, and border when creating layout styling.

Anyone coming from a Flex or Android background will immediately see the value of this. In Flex and Android, vertical and horizontal box layouts are the backbone of any application. For layouts which aren’t flow based, this is much more intuitive.

For example, consider the following layout:

With the associated markup (styling and browser-specific markup removed):

1
2
3
4
5
6

<div style="display:box;">
  <div>Child One</div>
  <div style="box-flex: 1;">Child Two</div>
  <div>Child Three</div>
  <div>Child Four</div>
</div>

I’m not going to go into detail as to what the code for this layout would look like today, but suffice it to say that any web developer should be intimately acquainted with such code.

There are other new layout modules as well (such as Grid Layout), but none that will play as big of a role in the micro-layout of small items on any website as the flexible box layout.

Nine Grid Backgrounds

I had previously created a jQuery plugin which enables 9-grid scaling support for javascript/css. This plugin has been made obsolete by the border-image style that is finally gaining widespread browser support. Similarly, 9-grid backgrounds have also been supported by frameworks such as Flex and Android for years.

Consider the following image:

Using the border-image style, the following background can be created:

With the associated markup:

1
2
3
4

<div style="border-width: 25px; border-image: url('/old/uploads/2011/11/aqua_bg.png') 25 25 25 25 repeat;
  width: 500px;
  height: 100px;">
</div>

This allows for beautiful raster based backgrounds to be easily applied to fluid width elements. The one caveat here is that additional calculations will be required to take into account the additional border widths (which will be eventually mitigated by the border-image-outset property). In fact, the grid background (only visible on higher resolution screens) on the current theme for this blog is styled using border-image.

Game Changing

Having developed on platforms where these two features are standard, I can say that having these available as tools for web design will enable a new class of beautiful designs. Although nothing here was previously unrealizable with a lot of complex markup and styling, this will go a long way towards HTML becoming a much richer language for user interface.

Having lived through the era of table-based layouts, the era of accessibility driven div hell, and now the onset of CSS 3, I envy the next generation of programmers who take these types of tools for granted.