The Top 10 Javascript MVC Frameworks Reviewed

by Gordon. 197 Comments

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.

Framework UI Bindings Composed Views Web Presentation Layer Plays Nicely With Others
SproutCore 1.x
Javascript MVC
Google Web Toolkit
Google Closure

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?

Javascript Frameworks Are Too Small

by Gordon. 5 Comments

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

1. It is important to clarify this choice with respect to size and horizontal bloat. Here I am using the term larger to denote a framework which has a stronger abstraction/more utility for what I am actually using it for (as opposed to a bunch of unnecessary features).

The 25 Toughest Vocabulary Words Based On 1,000,000 Answers

by Gordon. 2 Comments

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.

Rank Word Definition Correct Ratio
1 transport strong emotion; rapture 0.1078838174
2 husband use sparingly; conserve; save 0.1198156682
3 career rush wildly; go at full speed 0.1380952381
4 disport amuse 0.1697247706
5 nicety precision; accuracy; minute distinction or difference 0.1991150442
6 cupidity greed (for wealth) 0.2042553191
7 cow terrorize; intimidate 0.2044444444
8 dint means; effort 0.2064220183
9 affected artificial; pretended 0.2127659574
10 exceptionable objectionable; likely to cause dislike; offensive 0.224137931
11 base contemptible; morally bad; inferior in value or quality 0.2282157676
12 brook tolerate; endure 0.2307692308
13 qualified limited; restricted 0.2322274882
14 guy cable or chain attached to something that needs to be braced or steadied 0.2339449541
15 gloss brief explanation note or translation of a difficult expression 0.2355769231
16 enjoin command; order; forbid 0.2358974359
17 mountebank charlatan; boastful pretender 0.2380952381
18 pluck courage 0.2476190476
19 bearing deportment; connection 0.2511210762
20 flag droop; grow feeble; decline in vigor or strength 0.2525252525
21 wont (the stated person's) habit or custom; habitual procedure 0.2525773196
22 pan criticize harshly 0.2526315789
23 waffle speak equivocally about an issue 0.2565445026
24 ferment agitation; commotion(noisy and excited activity); unrest (of a political kind) 0.2566371681
25 mettle courage (to continue bravely in spite of difficulties); spirit 0.2581967213

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:

Rank Word Definition Correct Ratio
1 psychiatrist doctor who treats mental diseases 0.9957264957
2 healthy possessing good health; healthful 0.9911894273
3 vaporize turn into vapor (steam, gas, fog, etc.) 0.9868421053
4 sibling brother or sister 0.9855769231
5 optician maker and seller of eyeglasses 0.9821428571
6 judiciary judicial branch of government 0.981981982
7 plumber one who installs and repairs pipes and plumbing(pipes) 0.9815668203
8 exhale breathe out 0.9814814815
9 renovate restore to good condition; renew 0.981042654
10 lubricate apply a lubricant to 0.9807692308
11 replicate reproduce; duplicate 0.9787234043
12 reminiscent suggestive of something (in the past); of reminiscence 0.9782608696
13 artery blood-vessel 0.9779735683
14 morgue mortuary; place where bodies are kept before burial or cremation 0.9779735683
15 negligence neglect; failure to take reasonable care 0.9777777778
16 nauseous causing nausea; feeling nausea 0.9774774775
17 cardiologist doctor specializing in ailments of the heart 0.9771689498
18 mentor counselor; teacher 0.9770642202
19 oversee watch over and direct; supervise 0.9768518519
20 nectar drink of the gods; sweet liquid collected by bees 0.976744186
21 amphibian able to live both on land and in water 0.9764150943
22 dermatologist one who studies the skin and its diseases 0.9763033175
23 kneel go down on one's knee(s) 0.9759615385
24 toxic poisonous 0.9758454106
25 hibernate sleep throughout the winter 0.9757281553

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

Introducing Misunderstood Pigs

by Gordon. 6 Comments

Miunderstood Pigs Gameplay

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


Two Game Changing CSS 3 Features

by Gordon. 1 Comment

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:

Child One
Child Two
Child Three
Child Four

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

<div style="display:box;">
  <div>Child One</div>
  <div style="box-flex: 1;">Child Two</div>
  <div>Child Three</div>
  <div>Child Four</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:

Aqua Background

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

With the associated markup:

<div style="border-width: 25px; border-image: url('/wp-content/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.

Design Tools Are Broken

by Gordon. 13 Comments

Spending lots of time both coding and designing has given me an acute awareness of how poor design tools are. Design itself has come a long way, but the design process has not. As a disclaimer, most of what is about to be said applies to user interface and graphic design, as opposed to illustration and the creative process.

The culture around design is primarily focused on the end product and not the process behind it. Photoshop, the industry standard for user interface design, is pixel-centric (limited vector support being a later addition). Trivial things such as rounding corners or changing resolutions are often non-trivial to accomplish. Re-usable assets, such as those found on Smashing Magazine, often consist of static images, hopefully in multiple resolutions. Cascading stylesheets, the lifeblood of web design, are exceedingly repetitive and usually degrade into an unmaintainable soup.

For comparison, the culture of software development largely evolves around getting things done cleanly, efficiently, and maintainably. Entire programming frameworks and communities arise around the idea of making the process of doing something developers are already able to do (e.g build websites) simpler. Existing bodies of code are re-factored entirely to be cleaner, despite having less features. New languages emerge with the goal of making software easier to develop. Re-usable libraries exist for almost every language and programming task imaginable.

The stereotypical developer is horrible at graphic design, but much of this is due to an impedance mismatch between software development and design practices. From the perspective of a good developer, many of the techniques that are required to create good design are appalling and contrary to their core philosophy.

Massive Violation of DRY

From Wikipedia:

Don’t Repeat Yourself (DRY) or Duplication is Evil (DIE) is a principle of software development aimed at reducing repetition of information of all kinds…

A rule of thumb for this is if you find yourself doing the same thing often, there is probably/should be a better way to do it. Whether I am writing CSS or creating layouts and graphics in Fireworks or Photoshop, I repeat myself all the time. As a response to this for CSS, developers have created tools such as SASS and LESS. The elephant in the room, however, is graphic design. Accomplishing commonplace visual effects such as curved drop shadows and glossy buttons usually requires following multi-step rote processes every time they are needed.

Poor Extensibility and Reusability

Perhaps causally related with the violation of DRY principles is the lack of ways to extend graphics design tools and reuse existing graphical designs.

In the case of software development, common design patterns and features can easily be modularized and re-used in various projects and components. Existing frameworks are also designed with plugin architecture’s in mind. The prevalence of rails extensions, for example, has made creating web applications with Ruby on Rails amazingly easy, far beyond what the original framework intended.

Graphic design tools are quite the opposite. One could imagine things like glossy buttons, advanced shadows, and other effects being easily scripted or packaged into custom filters, but it’s not so in reality. Despite having limited scripting support, the really useful plugins for tools like Photoshop and Fireworks were all built years ago in native code. These tools are used by thousands of programmers and designers, but the ecosystem around extending and contributing to these products is almost non-existant. I have personally put immense amounts of effort towards scripting Adobe Fireworks, but this has simply made the limitations more apparent.

CSS3 has actually made great strides in this area, but it will never be a complete substitute for graphics design. I can imagine a future ecosystem consisting of a robust open source graphics editing program(s) accompanied by a plethora of plugins, filters and assets freely distributed and written in a modern scripting language.


Finished designs are often immutable and hard to change (and this has nothing to do with the good type of immutability). Source .psd files often consist of layers of flattened pixels, the exact combination of actions which created the layer lost forever. In many cases, this starkly contrasts with the underlying software being designed, which is in a constant state of flux and improvement.

The software equivalent of this would be software development tools which produce raw binaries without source code, the only possibility of change through a finite number of parameters. The natural solution would be to have graphics software which preserves the entire process by which an image was created. For this reason, I personally tend towards Adobe Fireworks, which is slightly better at this, dealing with items at the object level rather than the layer level.

Another solution would be to have the underlying format for the source of an image be an imperative graphics description language, e.g. Degrafa. SVG is theoretically nice, but is poorly implemented and monolithic, but still might ultimately be the answer.

Lack of Version Control

Binary source files don’t mesh well with version control. Merging conflicts is near impossible. Viewing and understanding the history of a file is not easy. I have seen workflows where all the design assets are passed around in shared folders with no version control at all. In the developer world, this would be almost unheard of. This also translates to the web, where design assets are clumsily distributed and the techniques used to create the asset are usually lost.

Reliance on Proprietary Tools

Almost no one would argue with the fact that Adobe Photoshop is the industry standard for graphic design, supplemented by Illustrator and sometimes Fireworks. Other open source tools such as GIMP and Inkscape are slightly sub par and suffer from the same lack of innovation. This state of affairs has been relatively the same for the last decade or more.

Not only does this restrict innovation, but it also restricts the platforms able to do graphics design. This prevents many developers and designers from using operating systems like Ubuntu as their primary OS. Moreover, I would argue that this has contributed to poor design in many OSS applications. Witnessing open-source software transforming the landscape of software development, one can only hope that the same will eventually happen to design.

Living Untethered

by Gordon. 2 Comments

For roughly two and a half months I have been without a mobile phone of any kind. Two months might not sound like much, but this is coming from a software developer who is entrenched in technology and has even built multiple Android and iOS apps. Before this, I always carried a phone and was in a constant state of sync. The event which prompted this experiment was the loss of my Nexus One during a trip to Las Vegas–the exact details of which aren’t important, but suffice it to say the trip was a success.

My hope throughout this was that I might be able to come to some insight or achieve a revelation about the significance of always being connected. Perhaps by depriving myself of something I had grown to take for granted, having a powerful computer in my pocket, could inspire me as a (mobile) developer. Unfortunately, the best I could come up with is this: having a phone doesn’t really fucking matter. For people who work in front of computers, in this day and age, your phone is a luxury device, and not having one is no big deal.

Sure, I definitely did miss out on a few candid photos of my friends, some of my amazing lunches went undocumented, and I definitely could have benefited from Google Maps from time to time, but fundamentally nothing about my life changed for the better or for the worse. I am still wired to a computer majority of the day, my brain is still synced to my GMail inbox, and aside from short periods of commute, the internet is still readily accessible if needed.

I was also hoping that I could write about how not having a phone could reduce stress. The physical constraint of not being able to check your email several hours a day does relax your attitude, but I still felt no perceptible difference in my stress level. Instead, for the rest of this post I will share some random tidbits I gained from this experience:

Google Voice is the Shit

For $0.00 dollars a month I have the same mobile phone number I had before as well as unlimited calls and domestic texts. This is all done through Google Voice after porting my phone number. From the perspective of all of my contacts, I still have a phone and nothing has changed. Of course, I need access to a computer to return calls, but this is not a problem for me, especially with a MacBook Air slung over my shoulder for most of the day. It really is only a matter of time before mobile VOIP clients usurp voice and text plans entirely.

Moreover, using Google Voice for calls and texts is actually a lot better than the traditional phone counterparts. Voicemail transcription definitely helped screen recruiters. I am also doing myself a favor by typing out texts in an instant message-like interface rather than constantly using a touch keyboard. In retrospect, it is actually slightly amusing to think of myself responding to texts on my phone while sitting in front of a full keyboard, as I often did. The same goes for email. Even if you have a phone, it is worthwhile to go through the cumbersome porting process, effectively making your phone and computer interchangeable.

Touch Interfaces Are Sexy and Easily Forgotten

While not having a phone, there wasn’t a single app that I longed to use over it’s desktop equivalent. Desktop apps aren’t quite as sexy, but they definitely work. I might be singing a different tune if I were really into the mobile gaming scene or consuming certain types of content as thats where I feel most of the innovation is taking place (even though Angry Birds is now in the browser).

Phones and computers are converging, and phones are starting to feel like shitty computers. (Although, I really hope I eat these words when NFC becomes prevalent). This is especially apparent when my Macbook Air is sitting next to my iPad 2 on my coffee table. It is only slightly larger, an order of magnitude more useful, and usually the first to be picked up when someone wants to browse the web. That said, just to be clear, I still do believe that a properly done native iOS or Android app focused on consuming content can still rival anything out there and can appeal to a wide(r) audience.

I Just Bought a Phone

I’m sure I slipped throughout this post and referred to my not having a phone in past tense. That is because yesterday I finally bought myself a replacement phone, an HTC Sensation, not because I needed it, but because I wanted it. I’m looking forward to being able to tether my air again.

Retroactively Open-Sourced Project #1: Paperblocks

by Gordon. 2 Comments

This is the first of several personal project’s that I plan to open source in the coming months. As I’ve slowly begun the process of migrating all of my personal projects from a private gitosis installation to github to a new server, I’ve realized that most of my 43 private repositories will amount to nothing in my hands alone. I’m also a big fan of free software without restrictions. With that in mind, I am licensing these projects under the MIT license.

Paperblocks is a flash 3d tetris game I made in my spare time years ago. I previously made a short blurb about it here. It is built with Flex and Papervision3D with a small php high scores backend. The original inspiration for the game was from Blockout, which was one of my favorites growing up.

Play the game or check out the source code. Cheers!

Windows 8 Isn’t That Bad

by Gordon. 8 Comments

There seems to be a large amount of backlash directed towards Windows 8 due to the fact that it’s new UI exists alongside the old Windows desktop. I must confess that I was slightly shocked myself to witness the context switch take place on the video, but I was shocked in a good way. Ironically, the reason why I think it’s good to have a Windows desktop alongside a touch UI is based on the same reasoning as why I switched from Windows to OS X in the first place.

I am typing this right now on my latest generation MacBook Air. The reason why I switched to OS X was because it was the best of both worlds. I could have a Unix shell, Adobe products, as well be able to use XCode to develop iOS applications (which you can’t do on Windows, but that is a separate issue). I could do everything Windows could and more. Analogously, choosing between Windows 8 and iOS for a casual user is very similar.

I also have an iPad 2 and an iPad before that. People, mostly family, are always very attracted to my iPad and frequently ask me if they should buy one to replace their existing aging laptop. My answer is always a resounding no. Were that to happen, they would inevitably call me and ask how to open Office documents, view flash websites, and do all the other countless things that an iPad is not suited for.

Windows 8 solves this problem. Sure, there will be an initial period where some apps will only be available in desktop form. But, at least there will be a less elegant way to do things that otherwise couldn’t be done. Additionally, this will only result in low hanging fruit for developers. If the metro tiling interface takes off, consumers will prefer a metro based application and developers will build one. Similarly, Android’s additional OS-level features (at the sake of battery life, some might say) are one of the reasons why I prefer it over iOS.

Another argument against Windows 8 is that of market and developer confusion. There is no market and developer confusion. Apple has already set the precedent. Consumers and developers both know what they want and what to build respectively. The capability is there and the developer who builds what the consumer wants will win.

Based on WP7′s market performance, who knows what will happen. My argument here is not to say Windows 8 is a winner. It is simply to say that the the arguments against it are misguided. I, for one, would prefer to be able to do more than less. One thing that is certain, however, is that having more competitors and innovation in the mobile/touch landscape is a good thing.

What It’s Like to be Recruited

by Gordon. 21 Comments

252 Recruiter Emails

Roughly three months ago (in the beginning of March), for a variety of reasons, I decided to put my resume out there on the interwebs. Here I chronicle my experience being a software developer on some of the most popular and widely used job channels.


For some context, I was doing research on an idea I had (now GroupTalent) and was also willing to entertain the idea of flexible interesting mobile projects. My resume included the following:

  1. B.S. in CS and Math
  2. SDE at Microsoft
  3. YC Founder (Team Apart S’08, now defunct)
  4. Misc. consulting
  5. Independent app development (iOS and Android)

My objective read:

Seeking freelance or short term contract iPhone and Android development positions.

I posted this resume on Monster and CareerBuilder. I had also previously created a profile on StackOverflow careers and GitHub jobs. Additionally, and importantly, I had indicated that I would be willing to relocate.


To relate my experience, I will begin with some numbers and then move into a more anecdotal portrayal.

Over the course of the roughly three month period after posting my resume, I diligently labeled all incoming emails from recruiters in GMail. Thankfully, I also use Google voice, and was easily able to identify and count calls and voicemails from recruiters. The numbers I am about to give exclude the numerous automatic emails sent from these sites; they all represent contact from actual people (or at least present themselves as so). The screenshot at the beginning of this post would suggest that I had received 252 emails, but this number is from when I began drafting this post roughly a week ago.

As I write this, all in all I have received: 266 emails and 96 voicemails. This roughly equates to 12.7 emails and 4.3 voicemails per workday. There were also some additional calls that I actually answered or that didn’t result in a voicemail. My profile was viewed 261 times and “saved” 37 times. My profile showed up in 343 searches (presumably by employers), and was viewed 31 times. My profile on StackOverflow careers was viewed by employers a whopping 1 time and had 3 search hits. GitHub jobs doesn’t appear to reveal any data of this kind.

The emails varied immensely in personalization and adherence to what I was actually looking for. My CV’s objective of short term Android and iPhone projects functioned as a mere leitmotif or not at all. My overall impression was that many recruiters simply do blanket keyword searches for terms such as “java”. Interestingly enough, many recruiters reached out to me on the premise that they found my resume on other sites such as Dice that I had never even created a profile on. It turns out that most recruiters do not even interface with the job sites directly, but instead use 3rd party software which crawls all the job boards for them.

Employers ranged from small startups to large corporations, the average being somewhere in between. The companies also included the likes of desirable A-Companies such as Amazon and Zynga. The split of jobs that were local and those which required relocation was about half and half with perhaps a few more on the relocation side.

Most recruiters were either head hunters or part of 3rd party staffing companies, but many were internal recruiters as well. For the first week, I actually answered all incoming calls, but this eventually became unmanageable. I used the opportunity to hear them out and also sometimes give them a reverse pitch on GroupTalent for feedback. Some recruiters were actually extremely savy people who wanted to build a relationship with you. Others were pretty abrasive. My favorite conversation was with the recruiter who actually suggested that I take a job at a mega corp while I still could since everything was going to be outsourced in the near future anyways.


According to Joel Spolsky, most good developers will never even be exposed to this situation since they will never be on the market. Combine this with the fact that everyone sucks at hiring and you have an industry that is basically a crap shoot. I also wonder if companies realize that many of their candidates are acquired through pseudo-spam.

In the interest of full disclosure, I actually have used Monster a few years ago and did wind up with an excellent consulting gig that was very flexible, but my experience was similarly noisy. I consider myself at least a decent developer and believe that good developers are on the market or are at least willing to entertain new opportunities. I predict that in the coming years the demand for top talent will be even higher and companies will need to resort to new ways to find and incentivize developers. While the experience I have presented here can vary, especially for new grads and developers travelling through reputation or word of mouth, my goal here was simply to give some perspective.

What is your experience being recruited?