Monday Feb 04, 2008

On the Inelegance of Current JavaScript Paradigms

As cool as unobtrusive JavaScript is for building the behavioral layer, it's nevertheless based on some pretty kludgy foundations, especially when contrasted with CSS's rather elegant method of declaratively building the presentation layer.

Kludge #1: Waiting for DOM load.

It seems unavoidable. If you want to be unobtrusive, there will be a delay before your functionality is available. Furthermore, DOMContentLoaded and friends don't truly solve the problem. Interestingly, a parallel problem exists in the CSS world: the FOUC (Flash Of Unstyled Content). FOUC is generally not a problem in modern web clients. I wish I could say the same for the "flash of behaviorless content" problem.

Kludge #2: Procedural DOM traversal and event attachment.

Why do I have to seek out the elements that interest me and add behavior, element by element? What a pain. On sufficiently complex pages this means walking the entire tree. If you add new elements as you walk the tree, hall-of-mirrors-style infinite loops and other pitfalls plague you. If innerHTML gets added during the course of the page's life, you have to go back and re-walk those parts of the DOM, re-attaching events as needed. Once again, contrast this with CSS, where the user agent abstracts away the traversal and the attachment of styles, allowing you to declare once--up front--which elements get which styles. Pity we can't do it this way for the behavior layer too.

So what?

Of course these are well known problems. Such is the hand we've been dealt, and tools and techniques exist that make these problems less painful, so why the fuss? In my mind anyway, leaky abstractions on top of kludges aren't an ideal state of affairs, and so I rant. But I also wanted to establish a little background for a future post where I'll describe some tools we're about to deploy on that, in certain instances, avoid these problems altogether.

[Update]: I've posted a followup with a bit of information about how our new library works.

Sunday Jan 27, 2008

Pre-compile and cache yer dang regular expressions

We have a function called hasClassName(el, cls) that checks whether a given DOM element has a given class. More and more, we're relying heavily on this function, and on certain pages it can run thousands of times. In these situations a little performance tuning can go a long way, as demonstrated here:

function hasClassName(el, cls){
  var exp = new RegExp("(\^|\\\\s)"+cls+"($|\\\\s)");
  return (el.className && exp.test(el.className))?true:false;
  var c={};//cache regexps for performance
  window.hasClassName=function(el, cls){
    if(!c[cls]){c[cls]=new RegExp("(\^|\\\\s)"+cls+"($|\\\\s)");}
    return el.className && c[cls].test(el.className);

This simple change cut the function's average runtime in half and reduced the page's overall onload setup time by over 25%! (According to Firebug.) All because it caches regular expressions.

Edit: removed unnecessary ?: operator per Nate's comment.

Monday Jan 21, 2008

Python Musings and Farkle Babies

Python is my spare time language. I wish I had opportunity to use it during my day job, but alas, JavaScript is my day job language. Not that there's anything so terrible about JavaScript, but I get wistful sometimes switching back and forth between being able to use list comprehensions and not being able to use list comprehensions.

So anyway, I wrote a breeder program in Python that breeds little Farkle-playing babies and sets them all off playing each other. The ones that win the most games survive to the next round and get to have little Farkle-playing babies, passing on their Farkle-playing genes with various mutations. The ones that don't win, sadly, become the victims of the garbage-collector. After a few hundred generations or so they got pretty good at Farkle, starting at about 20 rounds per game on average and working their way to about 16 rounds per game on average. (The idea is to get to 10000 in as few turns as possible.) Because it's ultimately based on random numbers (rolls of the dice), Farkle is one of those games where skill level (good risk-tolerance sensibilities) only gives you a marginal advantage, so in retrospect it perhaps isn't the best candidate for an EA.

One thing that struck me about Python versus JavaScript is that with Python, my tendency is to sit and think for a long time, then write a few lines of code. Whereas with JavaScript, my tendency is to spew code prolifically, thinking as I type. I don't know if this speaks more about my skill level in the respective languages, or the nature of the languages themselves. It definitely feels like I burn more keytypes in JavaScript getting ready to do, whereas in Python I burn more keytypes simply doing. Maybe we web developers should push to have Python implemented in web clients as an alternative to JavaScript, if for no other reason than to save our hands from the strain of typing all day.

Wednesday Dec 19, 2007

Here Goes Nothin'

Woo. Leopard arrived yesterday. Gonna install that bad boy as soon as I get a chance.

[Read More]

IE8 Standards Compliance Mode?

Strange things are afoot in IE-land. Remember our old friends quirks mode and (almost) standards-compliance mode? There's reason to believe IE8 will introduce yet another rendering mode, and that developers will need to opt-in to this rendering mode if they want IE to break backwards compatibility with its long-entrenched bugs. The question is, how will the opt-in be triggered? A <meta> tag? A version number in the opening <html> tag? An HTTP response header? A conditional comment? The mind boggles.

[Update]: Chris Wilson of the IE team promises more details soon regarding this very thing.

[Update jan/25/08]: And we have a winner: A <meta> tag and/or an HTTP response header. I have no opinion. Too many people smarter than I have already weighed in, and it remains to be seen just exactly how this will all shake out.

Whoa Nelly: IE8 Passes Acid2!

What has the world come to?


My name is Greg Reimer and I'm a web technologist for the Sun.COM web design team.


« July 2016