Google Chrome JavaScript Is Powered with a V8 Engine

When JavaScript was first invented, I don't think anybody imagined just what we would be doing with it today. In fact, a lot of people today might not realize how much it's being used behind the scenes of all the modern Web 2.0 applications.

Right now, JavaScript is virtually the only language that can be used in a client-side browser-based application. Sure, there's always VBScript if you want to limit which browsers can run your application. And there are many other languages if you want to require visitors of your Web site to download an add-on to provide support for that language. But if you want to write an application for the most browsers with the least amount of headache for your users, you're pretty much stuck with JavaScript on the client end. (The server end is wide open in terms of language and platform choices, of course.)

Originally, JavaScript was just used to add fancy little animations (like graphics falling down the screen like rain) and other such annoyances to Web pages. But today JavaScript is being used for serious work. For example, on Facebook you can send an e-mail message within a single DIV element that opens up, allowing you to type in the message, send it and update the thread of messages on the page, all without leaving the page. And that's all done through JavaScript.

But the problem Web developers are hitting is that JavaScript is a slow, interpreted language. While today's computers are able to move along pretty quickly and the sites do function reasonably well, we are nevertheless limited as to how our sites can perform. And soon we're going to hit a brick wall if something isn't done to help make JavaScript run better.

There are several solutions to this problem. One approach that has worked well with scripting languages in the past is JIT (Just-in-Time) compilation. Here, code is compiled to native machine code as needed. This approach only works well with routines that are called over and over. If you're calling a routine just once—one that doesn't have many for loops—it's often faster to just interpret it rather than first compile it and then run it. The compilation can take longer than just running the interpreted form. But if you have a routine that's called over and over, compiling it the first time and then running the compiled form can make a big difference.

Language developers have taken the JIT concept and mixed it with other concepts such as various types of optimization to significantly speed up languages. The newest Firefox version that is still in development, for example, includes a JIT and optimization compiler for JavaScript, allowing it to run much more quickly. That is certainly good news. (And, interestingly, the original designer of JavaScript, Brendan Eich, is the CTO of Mozilla, which makes Firefox. So, needless to say, I suspect we will see some serious advances from Firefox in the JavaScript world.)

Google, however, has taken a slightly different approach to making JavaScript run faster. Google does indeed compile it, but the approach is different from a typical JIT solution. Let's see what Google is doing.