I've had Google's new invention installed on my computer for a couple of weeks now, and I still can't believe it. When they launched Chrome at the beginning of the month, I thought: "Okay, another browser to fight CSS with." We already had enough of a war trying to get websites to fit in Firefox, the uncombustible Opera, and the insufferable Internet Explorer (blessed IE6 that still refuses to die in companies). But after trying a couple of dashboards loaded with AJAX scripts, I realized that something different was going on here. The interface didn't hang. There wasn't that annoying lag when scrolling on heavy pages. Chrome runs like a missile, and the culprit has a first and last name: the V8 engine.

From pure interpretation to JIT compilation

Until now, the way browsers executed JavaScript was, to understand each other, quite rudimentary. They were classic interpreters: they read the code, parse it, and execute it on the fly. That's fine for validating a registration form or making a simple dropdown menu, but at this point, we ask much more of the web. Just look at GMail or Google Maps demonstrating what can be built.

What the Google engineers (or rather, the Danish team they hired) have done with V8 is break the mold: they've put in a Just-In-Time (JIT) compiler. Instead of interpreting the code every time, V8 compiles it directly to native machine code (x86 or ARM) at runtime. It's fascinating to think that we now have an engine under the hood applying techniques that until recently we saw exclusively in virtual machines for heavy languages like Java.

The hidden classes trick

JavaScript is a dynamic language; we don't define whether a variable is an integer or a pointer, and we can add properties to an object whenever we feel like it. This drove engines crazy when it came to finding things in memory. V8 solves this by using what they call "hidden classes".

If we create objects with the same structure, V8 internally generates a C++ class and speeds up memory access by skipping the typical property dictionary lookup. Look at this snippet of code that we could write in any project:

function Usuario(nombre, edad) {
  this.nombre = nombre;
  this.edad = edad;
}

var admin = new Usuario("Pepe", 35);
var invitado = new Usuario("Juan", 28);

In Firefox or IE, the engine saves those objects as a simple dictionary of keys and values (a hash map). Every time you access admin.edad, it has to calculate the hash and look up the key. V8, underneath, realizes that admin and invitado share the exact same structure. It creates a hidden class for them and knows at what memory offset the age is. The access goes from being a slow lookup to a lightning-fast read instruction at the processor level.

And that's not all. They have a very aggressive generational Garbage Collector that pauses execution in fractions of a millisecond, so you no longer suffer those sudden screen freezes when the browser decides to clean up RAM (something I already talked about regarding our flight from Internet Explorer, but taken to another level).

The future is in the browser

The web is mutating fast. We no longer build simple pages with links; we are making complete applications that live inside a tab. And if we are going to program rich interfaces on the client, we need raw power.

I think what Google has done with Chrome and V8 isn't just releasing a prettier or more minimalist browser; it's laying down the gauntlet to Mozilla and Microsoft. They have shown us that JavaScript is not a slow language by nature, but that the interpreters we were using were mediocre. If this performance escalation continues at this rate, who knows, maybe in a couple of years we'll be running extremely heavy logic or complex calculations directly in the browser, without depending on closed plugins like Flash to gain agility.

For now, at a development level, Chrome has already earned a permanent spot on my taskbar, even if it's only to test how fast my scripts can run.