Web Development

You Should Learn JavaScript

My Automattic colleague Beau Lebens says that JavaScript is the next (or first) programming language you should learn, and I couldn’t agree more. His reasons are great, but his conclusion resonated with me:

there’s never been a better time to get started with coding, and if you’re going to do it, I suggest starting with JavaScript. Start small, work your way up. View Source. Get on Github. Go nuts.

It’s the “never been a better time” part that really resonated with me. You could argue that I missed the boat on the early days of the web: I hacked together some web pages in the Netscape 1–3 era and gave up when this intimidating DHTML thing showed up. I didn’t understand the difference between JS the language and JS the interface to the utterly bewildering, buggy, non-standardized DOM.1 There were no resources, and definitely no browser compatibility, as the browser wars continued to escalate.2

Fast forward 17 years (!) later, a return to a love of building for the web, and now JS is the most interesting thing to me, the very thing that drove me away from web development initially. It started with jQuery and its simplification of the DOM, but that just proved the gateway into eventually diving deeper into JavaScript proper, and beginning to understand that there was even a difference between DOM and JS (much as WordPress did with PHP for me). If you’re reading this on a modern desktop browser, you have everything you need to start playing around with JavaScript. There’s loads of resources out there (like Khan Academy) to get you on your way.


  1. Ditto for basically everyone else for at least another decade. 
  2. “Best viewed in ___” anyone? 
Standard
Web Development

Internet Explorer 6

Although I slung some HTML back in the early Netscape 1 days1, I really got going as a web designer/developer2 back in 2005. These were the heady days of early web standards, with Doug Bowman and Co.’s spiffy Blogger redesign and new, standards-based templates pushing forward the state of web design.

In 2005, Internet Explorer 6 was already four years old. To put that into perspective, Chrome has only existed for just over five years, and Mobile Safari for nearly seven. And today, IE6 is finally dead, at least in terms of being supported by Microsoft. I was longing for this day nine years ago, little would I have ever guessed that it would still be hanging on in some parts of the world.3

In 2005, IE6 was the bane of my existence. People today sometimes joke that Firefox is the new IE, but they probably weren’t around for the old IE.4 The funny thing is that IE6 was a really good browser when it was released, but Microsoft abandoned it after crushing all other browsers, finally releasing the only-marginally-better IE7 a staggering seven years after IE6 was released and an entire generation had been scarred by IE6’s quirks, bugs, and outright non-support.5

So, pouring one out for IE6. It defined a few generations of web design, from great initial release, to domination and stagnation, to its refusal to just go away. Probably nothing else has ever united the web design community like a hatred of IE6, and let's just hope we never have something with that kind of a stranglehold on the web's progress again.


  1. Thankfully archive.org doesn’t have any of my Smashing Pumpkins fan pages with twinkling starry background gifs. 
  2. Do we still not have a good word for people who do some of each? 
  3. Mostly in China, where a staggering 22.4% are still using it. 
  4. Besides, everyone knows that Android < 4 is the new IE. 
  5. Quick, name the thing that bothered you most! No alpha PNGs was mine. 
Standard
Web Development, WordPress

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime – your top requested feature. We’re bringing one of the most popular web programming languages to App Engine so that you can run open source apps like WordPress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

This could be a big deal, especially if they build tools to make it easy to install WordPress on App Engine.

Google App Engine adds the PHP runtime

Quote
Web Development

JavaScript Context Confusion

Or: how I learned to stop crossing my fingers about this.

The mutability of this is one of the hardest things to understand when writing JavaScript (the other is prototypal inheritance). Callbacks make this especially confusing and easy to lose track of.

Here’s a fairly common (and over-simplified) pattern:

var module = {
  init: function() {
    // alias "this"
    var self = this;
    // attach event handlers
    $("#foo").on( 'click', function( event ) {
      // this.takeAction() would throw a TypeError since jQuery
      // makes "this" a DOM Element rather than "module"
      self.takeAction( event );
    });
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

module.init();

The problem modular code runs into is that jQuery assigns this to be the DOM Element that was clicked on in the above example. This is good for writing typical jQuery spaghetti code, but not when we want more modular code. So we alias this to something like self or that to be used inside a nested function’s scope. ECMAScript 5 solves this problem with Function.prototype.bind, ensuring that a function is always called in a specified context:

var module = {
  init: function() {
    // attach event handlers
    $("#foo").on( 'click', this.takeAction.bind( this ) );
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

// helpful here too!
$( document ).ready( module.init.bind( module ) );

Now, if you find yourself in a situation where you need contextual information from both the DOM Element and the this context bound via Function.prototype.bind, you’re probably doing it wrong. (And anyway, you can still grab it from event.target.)

It would be great if we could just code like this today, but Function.prototype.bind is only supported in IE >= 9. But this is a common problem, and most frameworks solve this in some manner.

// jQuery.proxy
var module = {
  init: function() {
    // attach event handlers
    $("#foo").on( 'click', $.proxy( this.takeAction, this ) );
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

// _.bind
var module = {
  init: function() {
    // attach event handlers
    $("#foo").on( 'click', _.bind( this.takeAction, this ) );
  },
  takeAction: function( event ) {
    // I need to have (this === module) to work properly
  }
}

I would recommend, whenever possible, to use Underscore’s _.bind over jQuery.proxy, since the latter can create some oddness (see docs) when unbinding event handlers. Plus Underscore is awesome.

And now I have some old code to go cringe at.

Standard
Web Development

Better Google Fonts Rewrite

I built Better Google Fonts about a 1.5 years ago to allow quick and easy browsing of Google Fonts with at least two variants, on the theory that there would be fewer fonts of dubious quality once the one-offs were filtered out. Right now that means showing 165 of the 613 available fonts, or about 1/4 of them. Not bad.

I’ve also wanted to add some filtering (need a font with a 300 weight? A minimum of 6 variants?) for some time, but the page was written as typical jQuery spaghetti. But, after signing up for Code School this past week and working through their excellent Anatomy of Backbone.js course, I knew that I had just the project to tackle: I would rewrite BGF with Backbone.js.

That’s been done, laying the foundation for future filtering. But one other thing that had bugged me was performance: as the quantity of Google Fonts grows, the page was taking forever to download: it currently loads 555 fonts, which translated to a whopping 15.53 MB payload on the page.

Then I remembered that Google had introduced a text subset option for their fonts, meaning that I could make a request for only the the few characters rendered for each font. This dropped the payload to 2.96 MB, or an 81% payload decrease. Not bad! This translated into total rendering time decrease from 21.68s to 7.29s, a 66% decrease (taken from a mean of 7 page loads, dropping the max and min).

Old New
1 25.76 s 10.23 s
2 31.56 s 9.26 s
3 19.23 s 6.95 s
4 24.25 s 6.46 s
5 22.51 s 6.79 s
6 12.72 s 6.37 s
7 16.65 s 6.83 s
Mean 21.68 s 7.29 s
Payload 15.53 MB 2.96 MB

More important, though, is that the page feels way snappier. The page would previously lock up while it was rendering all those fonts, but now only lags slightly as it starts to render.

I look forward to working with Backbone more on this project and elsewhere in the future!

Standard