Archive for the 'Javascript' Category

Minification

In case anyone noticed, we’ve done a bit of client-side optimization. Namely:

  • Javascript and CSS files are now ‘minified’ (I prefer ’squished’) as part of our build process, using the handy YUI compressor - this shaves a good 40% of bloat off our Javascript and 20% off our CSS, and makes them ever so slightly quicker to parse at the other end too
  • Common Javascript and CSS includes are now packaged up into combined packages, which saves a lot of HTTP requests
  • Javascript includes have moved to the bottom of the page, meaning they won’t delay page rendering

Some stuff we were already doing:

  • Far-ahead Expires headers on all static resources, meaning they’ll be filled from the browser’s cache without any HTTP request where possible
  • Gzipping static files with lighttpd - this shaves a good 76% off our Javascript for example (and still 74% off the minified javascript). It also shaves 82% off CSS, and interestingly manages to shave even more (83%) off minified CSS - indicating that stripping syntactically-irrelevant information actually makes the remaining data more amenable to compression in this case.

Some more still to do

  • Convert PNG24s to PNG8s with alpha. Yes PNG8s with more-than-just-1-bit alpha do exist! and are considerably less bulky than PNG24s. Sadly neither Photoshop nor imageMagick can export them, but Fireworks, or the PNGNQ utility can. They don’t work too well in IE6, but then what does…)
  • Consider using CSS sprites and background-position hackery for some of our icons, where possible, to cut down on requests
  • Serve up static files from assets1.playlouder.com and assets2.playlouder.com, to increase the number of concurrent requests browsers make (they typically limit to 2 per hostname)
  • Optimize our javascript to improve page initialization times - browser-native getElementsByClassName may help here, as may selectively delaying some DOM lookups until they’re needed, and using more bubbled-up event handling to avoid the need for more specific DOM lookups
  • Optimize the crap out of the server-side (another topic for another day…)

Multiple inheritance in Javascript

Javascript’s prototype-based OO would be so much better if objects could have multiple prototypes. One could then build arbitrary Directed Acyclic Graphs of object delegation, and build pretty much any kind of desired object-oriented semantics, any kind of inheritance scheme or method resolution order in the world ontop of that. Raw Power.

Currently all the approaches to building class-based inheritance in javascript either rely on copying attributes (which rather defeats the point of prototype-based OO semantics in my mind), or are limited to a single superclass (no mixins or multiple superclasses).

I think this is the main weakness in the argument that prototype-based OO is better than class-based. Yes - but only if you can spare me multiple prototypes. In my opinion I think the ECMAScript standards should evolve more in this direction, and less in the direction of hacking class-based inheritance into the language. Just add multiple prototypes and provide class-based inheritance as a library.

‘Hijax’ - aren’t buzzwords great

Turns out, unbeknown to me, someone had already invented a buzzword for my “optional ajax navigation” technique.

Hijax” - because it Hijacks clicks on anchor tags and form submissions, and takes them over with Ajax.

I wonder if his code deals with all the same tricky corner cases that mine does, though.

Turns out someone’s made a dynamic history library for jQuery too. It looks a lot more modern and less verbose than the dhtmlHistory code we’re using at the moment - any kindly souls fancy porting it to work with prototype.js ?