Writing code for the web sometimes feels a little magical in that we write a sequence of characters in a file, open that file in a browser, and watch it come to life. But understanding the tech behind the magic can help you better hone your craft as a programmer.
First, a little terminology
A ‘system virtual machine’, for example, provides a complete emulation of a platform on which an operating system can be executed. Mac users might be familiar with Parallels, a system virtual machine that allows you to run Windows on your Mac.
A ‘process virtual machine’, on the other hand, is less fully-functional and can run one program or process. Wine is a process virtual machine that allows you to run Windows applications on a Linux machine, but does not provide an entire Windows OS on a Linux box.
How does this work?
- It performs a lexical analysis, breaking down the source into a series of tokens, or strings with an identified meaning.
- The tokens are then analyzed by the parser for syntax and built into a syntax tree.
- Four JIT (just in time) processes then kick in, analyzing and executing the bytecode produced by the parser.
- Ignition, the interpreter that generates bytecode
- TurboFan, an optimizing compiler that compiles that bytecode into machine code
- SparkPlug, a compiler that supplements TurboFan
If you're interested in history, this new pipeline replaced the older Full-codegen and Crankshaft double-compiler design used previously by V8.
Once machine code is produced by the compilation process, the engine exposes all the data types, operators, objects, and functions specified in the ECMA standard to the browser, or any runtime that needs to use them, like Node.js, Deno, or Electron (which is used by Visual Studio Code).
A little detour: runtimes
Runtimes, overall, address perceived gaps in the performance of standard browser architecture and the engines that power them. As the engines evolve, so, surely, will these runtimes.
|Edge**||Blink and V8|
Why should we care?
Bottom line, the evolution of these engines parallels our quest to evolve the web and mobile environments to make them as performant as possible. To track this evolution, you can see how various engines perform in benchmarking graphs such as those produced on arewefastyet.com.
Any web developer needs to be aware of the differences inherent in the browsers that display the code that we work so hard to produce, debug, and maintain. Why do certain scripts work slowly on one browser, but more quickly on another?
This article originally appeared in 2015 on the Telerik Developer Network, and has since been revised and updated for 2022.