Intro to Browser Engines: A Peak Under the Hood of JavaScript
As of April 2021 JavaScript will be 26 years old. As a language originally meant for little else besides making your Netscape Navigator web apps more responsive, it’s safe to say JS has had a very impressive boon in popularity over the last several years.
I could spout off an opinionated rant, brainstorming why JS was the language web and software developers championed here as opposed to say, C# or Java, but they would all fall short of being in as good of a position as JS was (and still is) in the mid 2010’s and beyond. Anyway, that article might come sometime later down the road.
For now, I want to talk about what drives JavaScript in today’s development environment. What kinds of dependencies does the average JS project need to leverage in order to package a dope looking app together for your browser? I also want to dig into what these engines enable and where your nifty apps would be if it weren’t for what’s under the hood.
The first thing I’ll touch on is what an engine is and what role it plays in delivering content to your browser. As with many other programming languages, there are more than a couple different ways to run JS. Furthermore, some of these methods, such as Node.js and Deno which are called Runtime Environments. While the engines utilize massive sets of instructions to make code readable by other programs (such as browsers), Runtime environments parse raw JS code into something workable. Like raw x86 machine code. Engines are translators, and JavaScript’s translators have evolved from simply parsing entire pages at a time, resulting in longer, less efficient load times, to parsing precisely what is needed when it is needed.
Most of JavaScript’s engines use what is known as Just-In-Time (or JIT) compilation to bring two traditional methods of Ahead-of-Time (AOT) and interpretation rendering together, combining some of the advantages and drawbacks of both. JIT says we don’t need to wait ten minutes to load the entirety of our Facebook or Instagram feeds as soon as the app starts up. Rather, we can load them asynchronously and render them as needed. Just in time. This way of compiling our code after sending precisely what we’re requesting up to be interpreted at a low level first, allows JS, a programming language at a much higher level, to operate much faster and use much less resources.
Much of the inspiration behind crafting the browser different engines on the market deal with companies leveraging new compression algorithms to translate data at faster and faster speeds over the years. The first engine designed to run JS locally in a browser was for the aforementioned, and ill-fated, Netscape Navigator back when JS was conceived in 1995. Over time this engine became what is known as the SpiderMonkey engine, which is used in Mozilla’s Firefox browser today. More notably V8 engine, developed by Google for Chrome in 2008, was the first modern browser to take advantaged of JIT programming and unlock most of JavaScript’s true potential in the world of web development. V8’s level of depth and performance blew everything else out of the water then, and continues to outperform many other browsers to this day.
While Google has bragging rights for possessing the most used engine for JS development, other companies have raised bars of their own to remain competitive. WebKit was another engine developed a short time after V8 from within Apple. Originally intended for Apple’s Safari application, WebKit is a heavily optimized browser engine for not only JS, but a number of other languages and protocols such as C++. WebKit, an open-source engine has since gone through multiple iterations and has even been forked by Google to produce the current Chrome browser engine known as Blink.
Microsoft has also thrown a hat in the ring and forked a version of WebKit to be used with it’s Edge browser engine. This platform works exclusively on Windows x86-based devices currently and renders with Edge HTML. While not an excitingly open or popular platform, it has made some strides to bring faster load times and improve the overall end-user experience.
As technology improves at breakneck speed across the globe, don’t be surprised to see more browser engines emerging to claim the throne. Algorithms wax and wane in and out of fashion in the rather circuitously and can bring with them updates to the engines of these older models.
Getting familiar with just a couple of these engines has already helped me to sort of mentally trace where some of this data is going. For a newbie like me it’s still a little hard to fathom where a single bit of data takes off to become a whole program.
I am eager to see what the future of the relationship between interpretation and compilation holds. Even now, the two aren’t necessarily mutually exclusive. Most interpretive systems also perform a compilation duty during runtime, but this is not to say any steps have been skipped or deemed unnecessary. As programming libraries reach higher and higher above languages like C or even Assembly, more solutions to these industry standards continue being invented. For now, this is all I’ll need to get from point A to point B.
