The JavaScript Arms Race

Published on July 10, 2009

It seems like every web browser these days is spending an enormous amount of time and development effort on JavaScript performance. Whether it’s the new TraceMonkey engine in Firefox 3.5, the V8 engine in Google Chrome, or the upcoming SquirrelFish engine in WebKit browsers, everyone claims (to some degree) superiority in this arms race. All of this raises two questions in my mind.

1. How important is JavaScript performance?
Are JavaScript applications really that slow? I’ll admit that the new Firefox 3.5 browser feels snappier on sites like GMail and Netflix, but said sites never felt that slow before. Why are developers spending so much time optimizing something that not everyone uses? Admittedly, JavaScript usage is going up (especially with the Web 2.0 craze), but how much latency does JavaScript computing really account for in today’s world? I’m much more concerned about data transfer; that’s the bottleneck I see. Broadband speeds here in the United States are ridiculously slow, compared to other parts of the world. Shouldn’t we all focus on ways to improve that? Yes, I know software developers have little control over that kind of infrastructure, but perhaps there are better protocols out there to get data to the end user in a more efficient manner.

2. Won’t improved JavaScript performance lead to poorer JavaScript programming?
As computers have gotten faster over the past two decades, and as memory sizes have increased, applications have become more bloated and (arguably) slower than before. I’m convinced that if programmers had retained the “every byte matters” mentality from the 1970s, 80s, and early 90s, applications would be leaner and meaner than they are today (especially in the realm of operating systems). Can’t the same thing be said for JavaScript programming? As JavaScript engines get faster, serious performance considerations during an application’s design phase might become less and less frequent. I’m of the opinion that high performance hardware can lead to sloppy programming. “Well, the application is good enough” is what the pointy-haired bosses of the world would say. Shouldn’t the application be the best it can be? Can’t one argue that “good enough” isn’t necessarily good enough?

I’ll be interested to see where this arms race takes us. What do you think?

3 Comments

kip

I hear this “easy programming leads to lazy programming, and lazy==bad” argument, and I can’t say I fully agree. A garbage collector (i.e. Java, C#) is slower than manually-managed memory (i.e. C/C++), but man do you spend a lot of time fixing memory leak bugs. There are times when that kind of performance is critical, which is why games and CAD programs and operating systems are all written in C/C++. But modern javascript makes a lot of stuff possible that would have required flash five years ago, and would have been unthinkable ten years ago (yes, I realize javascript has been around longer than that, but it wasn’t really until Google Maps showed everyone just what it was capable of really doing that the more modern ajax stuff came about).

Have you looked into jQuery very much? It transforms javascript to such a degree that it feels like a completely separate language. It almost entirely frees the developer from having to care what browser the user is using, and lets you manipulate object in jQuery in the same manner that you manipulate them in CSS, and it becomes intuitive after very little use. If you use it much, you’ll see why the web world is headed that way, and you’d be hard pressed to argue that plain-old-javascript is in anyway preferrable to jQuery. Some of those manipulations are slow (for example, selecting an object by class is much slower than selecting by ID), but they are enormously convenient for development. Speeding up javascript to allow faster and faster ajaxy stuff is really one of the most significant improvements left in today’s web browsers (at least, as far as inside-the-box thinking goes). And as you said, speeding up broadband speeds is something tackled by an altogether different group of people than those making web browsers.

Jonah

You are right, some of the JavaScript frameworks make things much easier. I personally use the Dojo framework. It, too, has the CSS selector mechanisms for walking the DOM (an elegant solution). And it does make writing JavaScript code much simpler for the programmer.

I’m not sure I would say that lazy programming == bad (and maybe my post doesn’t make that clear). But I wonder where we might be if programmers had kept that mindset that said performance and strict memory management were vitally important. For example, applications like Firefox or Chrome might have never come about, simply because the old web browsers could have been light and agile. One major reason Firefox and Chrome came around was because the alternatives were bloated and slow (and, ironically, Firefox is moving in that direction).

billy

The way i see it, the computing world is moving toward an everyone-a-programmer situation, with all the latest tools/IDEs fueling this trend. The end result is not pretty: people who would have had no business writing code 5-10 years ago are now churning out web pages, coding up business apps, that are so messy that it takes far more time to fix bugs than rolling out the initial app.

This made me think why the same trend is not happening in other professions, like electrical engineering, or healthcare? (the number of people trying to become a doctor are orders of magnitude less than the number who are trying to produce the the next killer web app). And the reason is quite obvious: lack of entry barrier. You don’t need any formal certification to write programs but have to go thru years of hard study to become a open a medical practice.

On second thoughts, this difference makes a lot of sense. If a doctor made an incorrect diagosis, it could cost someone his/her life, but if a web page has a few chars displayed in the wrong font, who cares?

Being a programmer doesn’t really carry much glamor, except everyone have the “potential” to produce the next killer app that “might” generate billions in return, but for 99.999% of programmers, this is just a pipe dream. Most of the 12-year-olds who claims to be a whiz programmer just think they will become the next billgates or sergio, but the sad fact is that they are far more likely to end up writing boring business apps when they enter the work force.

Comments are closed.

Copyright © 2004-2018 Jonah Bishop. Hosted by DreamHost.