Alex MacCaw

JavaScript programmer, O'Reilly author.

Page 3

Time to first tweet

At Twitter, one of our key metrics for success was ‘time to first tweet’, the time taken between someone navigating to, and seeing the first Tweet in the page. I’ve always thought it a useful metric, as initial interaction speed is vitally important; take too long, and users lose focus and leave.

There seems to be a lot of fear, uncertainty and doubt (FUD) in the programming community around the speed of JS web apps, especially with the initial page load. Server-side generated HTML is making a come-back, indeed Twitter eventually moved back to that away from a stateful client. It seems the single-page-app approach has many vocal opponents.

I’m here to put some of that FUD to rest, and show you that it’s perfectly possible to make JS web apps that load extremely fast. I’m going to show you some of the techniques I used to make so fast.

First, a little...

Continue reading →

Regulation and Innovation

Paradoxically, regulation can sometimes result in innovation. Within highly regulated industries, you often get entrenched businesses and monopolies ripe for disruption. While regulation and red tape may strangle fledgling startups, if they can struggle through and overcome it they have a distinct advantage – less competition.

What’s more, regulation is often ‘hackable’. Look hard, and you’ll see lots of startups out there flirting with grey areas and testing the boundaries. Often it requires a startup environment to think outside the box when it comes to interpreting and applying regulations. Most don’t like to talk about it for obvious reasons.

The are three industries that are great examples of this phenomena at work: drones, bio-tech and payments.


Commercial drones and quadcopters are an exciting area, and the use cases for them are endless. I went round a startup called...

Continue reading →

Memory Management in JS Web Apps

Memory management is a fairly crucial part to building JavaScript web applications, and just because the language has a garbage collector it doesn’t absolve you from all duties.

Take your classic controller (or view in Backbone land). In its constructor it may bind to some model events, perhaps re-rendering itself when a record changes. You’ll need to clean up these events listeners at some stage, especially if you’re constantly instantiating and removing the controller.

Backbone and Spine have a ‘remove’ method which, behind the scenes, will remove the controller from the DOM via jQuery. Backbone will even cleanup any event handlers using it’s Event.fn.listenTo feature. However, calling this manually whenever we want to remove a controller is a bit onerous, and means we can’t use features like jQuery.fn.html() to remove controllers. We somehow need to detect when the controller’s...

Continue reading →

Queuing Ajax Requests in JS Web Apps

Queueing Ajax requests in JavaScript Web Apps can be important, especially if the interface doesn’t always represent database state.

In both Backbone and Spine, the default behavior is to update the user-interface before sending requests to the server, i.e. an asynchronous user-interface. However, this can cause race conditions. For example:

  1. User creates a record, say a page
  2. Interface is updated and an POST request is sent
  3. User immediately deletes page
  4. DELETE request is sent to the server
  5. The server responds to the DELETE request before the POST request to create the page has finished.
  6. Server 404s because it can’t find the referenced page by ID

The solution to this race condition is to queue Ajax requests, particularly destructive ones (POST, PUT, DELETE). I’ve written a very simple jQuery 1.9 plugin to do just this. All you need to do is pass a queue flag when creating Ajax...

Continue reading →

Speed up Heroku deploys

While building Monocle, I noticed that deploys to Heroku were taking absolutely ages; specifically the asset pre-compilation stage. I tried a variety of things, including removing a bunch of CoffeeScript files, but deploys were still taking in the order of several minutes.

After talking to Josh, it seems the solution is a simple one. Simply enable Memcache caching for sprockets during the pre-compilation stage. By doing this, I’ve reduced asset compilation from 100 seconds to between 4-9 seconds.

By default, each Heroku deploy is in a isolated environment. This means that Sprockets can’t take advantage of previous asset compilations, and has to compile everything from scratch. The solution is to have a shared cache between deploys.

If you’re using Heroku, the first step is enabling a Memcache addon. I’ve gone with the memcachier service, as they’ve got a generous free plan (which is...

Continue reading →


I’ve been working on a project called Monocle these past few weeks, and it’s time to show it to the world.

Monocle is an experiment in creating a friendly and intelligent community around sharing quality content with a focus on technology, startups and frankly anything that appeals to the inquisitive mind.

Screen Shot 2013-07-03 at 12.05.36 PM.png


Over the next few weeks I’m going to be writing about the more interesting aspects to Monocle, but for now I want to talk about the motivations behind it.

The motivation for developing Monocle was to create a friendly and safe place for ideas and feedback. Criticism is kept to the constructive variety, and social accountability is provided by linking your Twitter or GitHub accounts.

There can be too much negativity in the tech community. It seems the average response to someone out on a limb, showcasing their latest idea or startup, is one of snark and derision...

Continue reading →

How to travel around the world for a year

While my last post covered my previous year traveling, writing and programming, this article will go into the specifics of planning your own round the world trip, including flights, costs, activities and accommodation. I’ll show you how affordable traveling actually is, and how to plan your own adventure.

“Travel is fatal to prejudice, bigotry, and narrow-mindedness.” - Mark Twain

I think it’s especially important for people to get out of the Silicon Valley echo chamber, to travel and get some perspective. Traveling opens your eyes to some of the real problems people face, and gives you the opportunity to come up with solutions to tackle those, rather than some of the more trivial ideas closer to home. You can’t fail to come away from traveling inspired with a fresh perspective and new ideas.

Stuck in Customs

 Choosing where to go

Choosing where to go can be overwhelming at first, especially when...

Continue reading →

Traveling, Writing and Programming (2011)

In a nutshell, my year so far has consisted of:

  • Traveling for 10 months around the world through 17 countries covering Africa, South East Asia, Australasia and North, Central and South America. The trip was centered around surfing and photography

  • Presenting in Hong Kong, Japan, the US and London

  • Writing a book for O'Reilly as I went, titled JavaScript Web Applications

  • Writing another book on CoffeeScript, soon to be published by O'Reilly.

  • Doing a ton of open source libraries, such as Spine, Spine.Mobile, GFX, and Juggernaut.

  • Building a startup prototype

  • Presenting at FOWA

  • And finally, landing a job at Twitter

So, let me start a year ago, in September 2010. I had just left a startup I’d co-founded, and whilst the experience was useful, I was feeling bit burnt out from the incredibly long working hours involved. I was back in England and needed to make some decisions. A long held dream...

Continue reading →

Asynchronous UIs - the future of web user interfaces

It’s an interesting time to be working on the frontend now. We have new technologies such as HTML5, CSS3, Canvas and WebGL; all of which greatly increase the possibilities for web application development. The world is our oyster!

However, there’s also another trend I’ve noticed. Web developers are still stuck in the request/response mindset. I call it the ‘click and wait’ approach - where every UI interaction results in a delay before another interaction can be performed. That’s the process they’ve used their entire careers so it’s no wonder most developers are blinkered to the alternatives.

Speed matters; a lot. Or to be precise, perceived speed matters a lot. Speed is a critical and often neglected part of UI design, but it can make a huge difference to user experience, engagement and revenue.

  • Amazon: 100 ms of extra load time caused a 1% drop in sales (source: Greg Linden...

Continue reading →

Chrome’s requestAutocomplete()

Another Google I/O, and another raft of awesome products. One announced API that I’m particularly excited about is requestAutocomplete(), a feature which is landing in Chrome Canary for Windows and Mobile (with OSX support coming shortly). What this API does, in a nutshell, is give you programatic access to autocomplete (or autofill) data.

Autocomplete was originally designed to make it quicker to fill out forms, but what if we could remove the forms altogether! Back in June I proposed just such an API - a way to programmatically retrieve autofill data stored in the browser. The proposal has evolved, improved, and is now going to be baked into future versions of Chrome.


What does it look like? Essentially it involves calling requestAutocomplete() on a form element. The form doesn’t necessarily need to be shown to the user, but the browser uses it to detect which input types to...

Continue reading →