Is it as fun as it used to be?

Archive for the ‘Software’ Category

How To Destroy Page Rendering Performance Using Just Javascript and CSS

So. Did you know that a severe impact on browser rendering time can be caused by CSS and javascript not playing nicely together? Rendering on different browsers varies by a factor of about 20 times (or whatever factor you want). I sure didn’t know.

And I have a “solution.”

So what is the situation? Consider an actual page from a webapp I’m developing. In FireFox the page loads and renders in something around 0.6 seconds. Safari loads and renders the same page in 12 seconds. This is not a contrived example.

What’s involved on the page? It displays summary information about all of the users of the webapp. The test data has 119 users. It uses [Blueprint]( and the jQuery plugin [ListNav]( I recommend them both, very nice. [ListNav]( (check out the [demo pages]( allows for easy navigation through a long list. [Blueprint]( is a CSS framework for laying out a page using a grid (check it out, it has [demos]( too), handles typography, and generally helps you make a page look decent. Blueprint works with <div>s, and ListNav wraps them up in <ul>s. Each user is represented by five <div>s within a <ul>.

On Safari, by changing the number of <div>s for each user I get:

user < div>s render time
1 0.5
2 2
3 4.25
4 7.5
5 12
6 18
8 32

To cut it short, if I remove the link tag to the Blueprint screen.css file in the header, the page renders almost instantly, even with 8 divs — but it looks like crap. There are a lot of things that are not the problem (I was “busy”, let’s say), and I don’t really want to go into it.

A few moments of thinking… what if I delay the application of the BlueprintCSS file? A little googling and I found some code in a JavaScript Kit tutorial: [Dynamically loading an external JavaScript or CSS file](, which I simplified to:

function loadcssfile(filename){
  // thanks to
  var fileref=document.createElement("link");
  fileref.setAttribute("rel", "stylesheet");
  fileref.setAttribute("type", "text/css");
  fileref.setAttribute("href", filename);

$(document).ready(function() { var navOpts = { initLetter: 'a' };

                               loadcssfile("blueprint/screen.css") // use a real URL here

This is (obviously) in the jQuery document ready function.

And it worked! In Safari. Not so well in FireFox. Sigh. In FireFox, this caused a rendering effect: the unstyled content would flash on the screen before being being styled. So, back to the webapp, and check the user agent, and only do this trick for Safari. Well, hold on. It is actually any AppleWebKit based user agent — OmniWeb screws up too. There’s probably others. Anyway, about 0.3s in Safari, obviously no change in FireFox, and I’m happy enough for now.

It all came down to a single link element in the page’s header.


Written by hutch

December 30, 2008 at 1:24 pm

You Actually Have to Know Something Sometimes


Roy Fielding, Mr. REST himself, writes a nice article about REST APIs and how they must be hypertext driven. I thought this was a pretty good article, and that I’d use it in the future when trying to explain REST APIs.

Apparently, not everyone agrees. It sounds as though Roy had a little bit of grief which is outlined nicely in this followup article.

Understandably, Roy isn’t pleased.

As you may have noted, my last post seems to have hit a nerve in various communities, particularly with those who are convinced that REST means HTTP (because, well, that’s what they think it means) and that any attempt by me to describe REST with precision is just another elitist philosophical effort that won’t apply to those practical web developers who are just trying to get their javascript to work on more than one browser.

Apparently, I use words with too many syllables when comparing design trade-offs for network-based applications. I use too many general concepts, like hypertext, to describe REST instead of sticking to a concrete example, like HTML. I am supposed to tell them what they need to do, not how to think of the problem space. A few people even complained that my dissertation is too hard to read. Imagine that!

Oh dear.

In the very first comment Dorian Taylor says:

With all due respect, I think you’re continually going to encounter that contingent that is expecting the bullet list of instructions, or even lazier, the screencast of ultra-practical steps to make the baubles twirl on their displays. My only consolation is the notion that this is probably just a symptom of the industrial age’s death rattle, and it’s anomalous that this behaviour is even considered acceptable.

Well, I don’t know how “ultra-practical” this video is, but it *is* from Joe Gregorio. Nice to see what Joe looks like. Oh, and it’s quite informative too, of course.

UPDATE: REST is UnAmerican, David Ing I think.

It’s long been our belief that REST and Roy Fielding has been palling around with Hypermedia. He barely denies it. But, my friends, let me tell you that no washed up PhD dissertation will dictate our request/response. He says it, in his own words – he talks about ‘constraints’, he toys with the idea of a transfer of ‘state’. My friends, in these times of economic crisis we need less State involvement, not more. REST doesn’t understand. Let’s give state transition back to the hard working people of the USA. Enough with this hypermedia socialism.

Written by hutch

October 28, 2008 at 10:34 pm

Posted in Software, webapps

A Tempting Solution to Bothersome Browsers

Using this plugin, your MSIE users will see your website with a grayscale color
This plugin helps people moving away from Internet Explorer: it turns
the colors of your website to a grayscaled version.

You can get it here

UPDATE: This was an attempt at humour, even though this plugin is so tempting it hurts… Nah! I’m resolved! I’m going to use it somewhere!

Written by hutch

October 27, 2008 at 7:26 am

Toronto Lisp Meetup, 3 April 2008

This is the third Toronto Lisp Meetup (of the modern era). I am really going to have to make it out to this one. I missed the last two for various annoying reasons.

ALU Wiki: toronto: Toronto Lisp Meetup – 3 April 2008, after 6pm

Bloor St. Fox and Fiddle

Toronto Lisp Mailing List

All Common Lisp, Scheme and Smalltalk programmers are welcome! Haskell, Ruby, Python and even Java programmers are welcome too!

Look for the table with the Lisp flyer on it.

Located at 280 Bloor St, the Fox and Fiddle has free wireless Internet and, $3 cocktails and bar rails on Thursdays and Fridays.

There’s a ( event, if you’re into that kind of thing.

Written by hutch

March 13, 2008 at 9:49 pm

Posted in Lisp

Toronto Lisp Meetup

There’s going to be another attempt at a lisp user meetup in Toronto:

The Announcement

This has been tried at least once already, but it fizzled out.

The meetup is open to anybody interested in lisp, not just people using lisp. So if you’re curious…

Unfortunately for me, I won’t be able to make it this time (I’m supposed to be in Waterloo that evening, so at least now there’s an upside should there be a winter storm :-)

Written by hutch

December 13, 2007 at 7:40 am

Posted in Lisp, Ruby

A Little Unnecessary Smalltalk Envy

In A Little Head Trauma…: Returning None is Evil, Mark Derricutt provoked a brief moment of Smalltalk envy.

(self doSomethingThatMightReturnNil)
  ifNotNil: [val | val doSomethingWithNoHassle].

In addition to what Mark was actually responding to, it is an annoyance that I’ve had repeatedly in Ruby but never really considered fixing. Until now.

The annoying code:

tmp = doSomethingThatMightReturnNil
tmp.doSomethingWithNoHassle if tmp

Just look at those tmp variables.

This is the ‘cure’:

class Object
  def if_not_nil(&blk)
    yield(self) if blk

class NilClass
  def if_not_nil(&blk)

I like monkey patching.

And now I can write:

doSomethingThatMightReturnNil.if_not_nil { | v | v.doSomethingWithNoHassle }

Which is so much nicer [UPDATE: and nicer still after Sean prompted me to actually get Mark’s example right].

That really does look like Smalltalk, doesn’t it?

Written by hutch

November 22, 2007 at 11:58 pm

Posted in Ruby

Bad Unix Jokes

In csh:

hutch% got a light?
csh: got: No match.

A long time ago it used to say “Sorry. No Match.” — things are a little ruder these days.

Sorry about that. Some kind of flashback I think.

Written by hutch

September 11, 2007 at 11:22 am