Pain and Glory from the Trenches of the IT World

Ricardo Herrmann just left an excellent comment to an article I had written about the general inadequacy of JavaScript-based Web applications. In his comment, he points out the Brickslayer game. It’s essentially a JavaScript-based Breakout clone. And like Ricardo pointed out, Breakout ran quite well on an Atari 2600. Keep in mind that the Atari 2600 is, well, rather under-powered compared to typical desktop computers today.

What’s special about this game is that it shows perfectly well what a bad idea JavaScript-based web applications are. Now, I don’t know if the problems I am about to describe are due to the implementation of the game, due to the JavaScript interpreters of the browsers I tried, or due to some other factor(s). But in the end, the why doesn’t matter. What matters is the horrible experience. For the record, the events described below took place on a 2800 MHz Pentium 4 system (note that the Atari 2600 has a 1.19 MHz 6507 CPU).

I first tried the game using Mozilla Seamonkey 1.1.2. It actually starts out fine. You can move the paddle back and forth quite smoothly. But then you launch the ball, and the game nearly grinds to a halt. This would appear to be because it starts consuming 100% of the CPU. Beyond that, the game flickers quite badly. I have to say, it’s rather pathetic.

Now, I didn’t want to blame the game for what might just be a problem with Seamonkey’s JavaScript implementation, so I decided to try it with Opera 9.20. As soon I press the Enter key to start the game, the paddle floats away, right off of the bottom of the browser viewport. So I scrolled down, and noticed that it had stopped. Pressing the left or right arrow keys causes it to resume its downward movement. It should also be noted that the CPU consumption is at 100% whenever the paddle is moving.

Thinking I might have just been the victim of two poor JavaScript implementations, I decided to try the game in Konqueror 3.5.6. It exhibits essentially the same behaviour as Opera. The paddle floats downwards, eventually stopping. Any movement of the paddle resumes its descent. At least the KJS JavaScript implementation is well-written enough to not consume 100% of the CPU, as Seamonkey and Opera did. It only consumed around 30% to 40%.

I don’t have access to a Mac or a Windows system at the moment, so I can’t try Safari or Internet Explorer. I would imagine that Safari would behave similar to Konqueror. I’m not sure how IE would behave.

Like I stated before, I don’t know why I encountered those problems, even when using three different JavaScript implementations. On one hand, I would suspect it’s a problem with the game. Both Konqueror and Opera exhibited very similar behaviour. Knowing that they’re both high-quality browsers, and often the most standards-compliant, I would tend to believe that they’re behaving correctly. But then Seamonkey behaved differently, but in a far more functional manner. As was stated earlier, none of this really matters. What matters is that the experience was a terrible one.

All so often we hear JavaScript advocates talking about how great of a platform it and the Web browser is for serious application development. But then we look at a real-world example, and find that it can’t even duplicate a game that ran well on a system with a 1 MHz CPU, nearly 30 years ago! That’s a pretty serious regression, and clearly not the way we should be heading as we move into the future.

This entry was posted on Tuesday, July 24th, 2007 at 12:27 am and is filed under Development, Internet Explorer, JavaScript, Konqueror, Opera, Software, Web Development, Web Sites. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.