A Guide to JavaScript Engines for Idiots

javascript_engines

For the record, I don’t think anyone involved in either writing or reading this article is an idiot. But sometimes a topic makes you feel like one, and the engines that power JavaScript code is one of those topics – at least for me.

Writing code for the web sometimes feels a little magical in that we write a sequence of characters and things happen in a browser. But understanding the tech behind the magic can help you better tune your craft as a programmer. At least you might feel slightly less idiotic when trying to explain what is going on behind the scenes in a JavaScript-powered web or mobile stack.

Many years ago when I was a graduate student instructor, I was whining to a professor about not grasping a particularly thorny point of French grammar well enough to teach it to my undergraduate class. I remember her words at the time: “Sometimes, the only way to learn something is to teach it.”

Faced with trying to explain to engineers how NativeScript works behind the scenes by using a JavaScript engine at runtime to bridge to native APIs, it’s easy to get lost in the weeds. Any JavaScript developer, in fact, might be curious about the engines that underlie this technology that we use on a daily basis. Let’s break down what a JavaScript engine does, why different platforms use different engines, how they have evolved over the years, and why we, as developers, should care.

confusing

First, a little terminology

A ‘JavaScript engine’ is often termed a type of virtual machine. A ‘virtual machine’ refers to the software-driven emulation of a given computer system. There are many types of virtual machines, and they are classified by how precisely they are able to emulate or substitute for actual physical machines.

A ‘system virtual machine’, for example, provides a complete emulation of a platform on which an operating system can be executed. Mac users are 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.

A JavaScript engine is a kind of process virtual machine that is designed specifically to interpret and execute JavaScript code.

Note: it’s important to differentiate between the layout engines that power a browser by laying out web pages, versus the lower-level JavaScript engine that interprets and executes code. A good explanation is found here.

So what, exactly, is a JavaScript engine, and what does it do?

The basic job of a JavaScript engine, when all is said and done, is to take the JavaScript code that a developer writes and convert it to fast, optimized code that can be interpreted by a browser or even embedded into an application. JavaScriptCore, in fact, calls itself an “optimizing virtual machine”.

More precisely, each JavaScript engine implements a version of ECMAScript, of which JavaScript is a dialect. As ECMAScript evolves, so do JavaScript engines. The reason there are so many different engines is each one is designed to work with a different web browser, headless browser, or runtime like Node.js.

You’re probably familiar with web browsers, but what’s a headless browser? It’s a web browser without a graphic user interface. They are useful for running automated tests against your web products. A good example is PhantomJS. And where does Node.js fit into this? Node.js is an asynchronous, event-driven framework that allows you to use JavaScript on the server-side. Since they are JavaScript-driven tools, they are powered by JavaScript engines.

Given the definition of a virtual machine above, it makes sense to term a JavaScript engine a process virtual machine, since its sole purpose is to read and compile JavaScript code. This doesn’t mean that it’s a simple engine. JavaScriptCore, for example, has six ‘building blocks’ that analyze, interpret, optimize, and garbage collect JavaScript code.

How does this work?

This depends, of course, on the engine. The two main engines of interest to us, because they are leveraged by NativeScript, are WebKit’s JavaScriptCore and Google’s V8 engine. These two engines handle processing code differently.

JavaScriptCore performs a series of steps to interpret and optimize a script:

  1. It performs a lexical analysis, breaking down the source into a series of tokens, or strings with an identified meaning.
  2. The tokens are then analyzed by the parser for syntax and built into a syntax tree.
  3. Four JIT (just in time) processes then kick in, analyzing and executing the bytecode produced by the parser.

Huh? In simple terms, this JavaScript engine takes your source code, breaks it up into strings (a.k.a. lexes it), takes those strings and converts them into bytecode that a compiler can understand, and then executes it.

Google’s V8 engine, written in C++, also compiles and executes JavaScript source code, handles memory allocation, and garbage collects leftovers. Its design consists of two compilers that compile source code directly into machine code:

  1. Full-codegen: a fast compiler that produces unoptimized code
  2. Crankshaft: a slower compiler that produces fast, optimized code.

If Crankshaft determines that the unoptimized code generated by Full-codegen is in need of optimization, it replaces it, a process known as ‘crankshafting’.

Fun fact: a crankshaft is an integral part of the internal combustion engines used in the automotive industry. A well-known engine of this type used in higher-performance vehicles is the 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 NativeScript.

What JavaScript engines are out there?

There is a dizzying variety of JavaScript engines available to analyze, parse and execute your client-side code. With every browser version release, the JavaScript engine might be changed or optimized to keep up with the state of the art in JavaScript code execution.

It’s useful to remember, before getting totally confused by the names given to these engines, that a lot of marketing push goes into these engines and the browsers they underlie. In this useful analysis of JavaScript compilation, the author notes wryly: “In case you didn’t know, compilers are approximately 37% composed of marketing, and rebranding is one of the few things you can do to a compiler, marketing-wise, hence the name train: SquirrelFish, Nitro, SFX…”

While keeping in mind the heavy marketing influence in naming and renaming these engines, it’s useful to note a few of the major events in the history of the JavaScript engine. I’ve compiled a handy chart for you:

Browser, Headless Browser, or Runtime JavaScript Engine
Mozilla Spidermonkey
Chrome V8
Safari** JavaScriptCore*
IE and Edge Chakra
PhantomJS JavaScriptCore
HTMLUnit Rhino
TrifleJS V8
Node.js*** V8
Io.js*** V8

*JavaScriptCore was rewritten as SquirrelFish, rebranded as SquirrelFish Extreme also called Nitro. It’s still a true statement however to call JavaScriptCore the JavaScript engine that underlies WebKit implementations (such as Safari).

**iOS developers should be aware that Mobile Safari leverages Nitro, but UIWebView does not include JIT compilation, so the experience is slower. With iOS8, however, developers can use WKWebView which includes access to Nitro, speeding up the experience considerably. Hybrid mobile app developers should be able to breathe a little easier.

***One of the factors in the decision to split io.js from Node.js had to do with the version of V8 that would be supported by the project. This continues to be a challenge, as outlined here.

Why should we care?

The goal of a JavaScript engine’s code parsing and execution process is to generate the most optimized code in the shortest possible time.

Bottom line, the evolution of these engines parallels our quest to evolve the web and mobile spheres 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. It’s interesting, for example, to compare Chrome’s performance when powered by V8 versus a non-Crankshafted engine.

arewefastyet

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?

Mobile developers, similarly, especially those who write hybrid mobile apps using a webview to display their content, or those using a runtime like NativeScript, will want to know what engines are interpreting their JavaScript code. Mobile web developers should understand the limitations inherent to and possibilities offered by the various browsers on their small devices. Keeping up with the changes in JavaScript engines will really pay off as you evolve as a web, mobile, or app developer.

Header image courtesy of Charlie Day

NativeScript

Comments

  • Alan Spencer

    There are more ECMAScript engines, some of them can even fit embedded systems.

  • Pingback: Dew Drop – September 22, 2015 (#2095) | Morning Dew()

  • Super offensive title. I’d strongly consider changing it.

    • burkeholland

      I approved this one myself based on the popular book series. It’s not meant to be taken literally and I do think the first paragraph does an excellent job of clarifying.

      • so I guess we are all idiots reading this article, cool

    • remotesynth

      As the editor of this site, I am honestly surprised that you took offense to this. I think, just like the For Dummies and For Idiots series of books, of which I’d be shocked if you are unaware, the context is clear that it isn’t seriously calling each reader an idiot (which is a ridiculous presumption to make in the first place). Also, the article immediately clears that up – as if it even needed to. Nico, you and I know each other, but in this case (I’m going to be honest and not speak on behalf of my company) I think the only way you can be seriously offended by the title is if you are actively looking to be offended.

      • If you feel to explain someone is wrong, let me try to explain something.
        First of all – if you are intelligent enough to understand this title – great for you. But I also understand the title. Second most young people are often frustrated because of titles like this, it implies that they are idiots when reading. Third – please, how many people knows about Hyperbol in poetry? Anyways, do technical stuff should include a poetry style at all? Fourth – because of that someone wrote a series of book with stupid title, does not mean that it’s cool. It’s like – thousands flies can’t be wrong that shit is bad thing, right? πŸ™‚

    • The title isn’t offensive at all actually. Some people just need to take a chill pill and stop being so easily “offended” by everything out there – it’s ridiculous. I’m offended by how easily people are offended now days! πŸ™‚

      Great info in the post Jen!

      • Jen Looper

        Thanks, Dan πŸ™‚

      • Next time I will create article with title: “Javascript Secrets for Nazists”. I’m wondering what will happen…
        Titles like this makes me puke. Please read what Wikipedia has to say about Idiot definition, than think again about this title. I prefer creative titles than “controversial” because I don’t waste time on reading why author didn’t meant what he meant in whole paragraph (?) uhm…

        And it’s not about being fragile – it’s about rules.

    • Dale Anderson

      TROLL: Gee… You are easily offended. Like the rest of the Internet, I guess.

    • Jen Looper

      I’m sorry you’re offended, Nicolas. I think I explained the title and the rationale behind it in the first paragraphs.

  • TheMarchMyth

    Great article!
    I came because of a tweet that said the title was offensive but stayed for the amazing content.

    • Jen Looper

      Thanks!

  • Nice article!!! Though a question, what is the difference between these JS engines compared with ECMAScript version 6 / 7 / etc., Also, how do we solve the problem of slowness in one browser compared to other?

    • Jen Looper

      hi, these are kind of complicated questions. I think you are asking which engine supports which version of ECMAScript, in which case there’s a handy table here: https://en.wikipedia.org/wiki/ECMAScript. In terms of handling browser slowness…that’s where you want to take a multi-pronged approach. Simply understanding JS Engines is a start, but you need to understand layout engines, code optimization, caching, image optimization, site building strategies…that would be a book, not an article πŸ™‚

  • rob brown

    Two nitpicks:

    A crankshaft is on all internal combustion engines, whether V8, four cylinder, NASCAR, or econobox.

    With regard to “The reason there are so many different engines is each one is designed to work with a different technology”…not really. The one in node.js is the same one as the Chrome browser. And the ones in Safari and IE and Firefox are different because….browsers are in competition, not because they are “different technology.”

    • Jen Looper

      Thanks for noting the unclear statement about ‘different technologies.’ I’ve edited for clarity. And TIL a bit more about V8 engines! Thanks!

      • rob brown

        Nice! Keep up the good work

  • Mario Ruiz

    It was a great journey through the web evolution. Thanks!

    • Jen Looper

      Thank you!

  • OleksiiD

    Please, fix a broken link in the first blockquote:
    layout engines)
    should be
    layout engines

    • Jen Looper

      Thanks for noting!

  • Please change the headline, don’t be an idiot

    • Jen Looper

      I believe that I explained the rationale behind the title in the first few paragraphs, and it’s exactly for the reasons that you state. The ‘mistake’ you note is really a terminology issue – when I say ‘a different technology’ I mean a different browser. I’ve edited for clarity.

      • I have to say, my reply was a knee-jerk reaction to the title. I still think the article deserves a better title.
        Sorry to “bark” at you, I didn’t mean for my comment to come across so aggressively (now that I read it again), note to self, finish first cup of coffee before making comments in a public forum.

        • Jen Looper

          Coffee helps all the things πŸ™‚

  • Matt Smith

    I love the article, Jen!

    I posted it a few days back on LinkedIn and it’s been well-received. Sadly, there are 2-3 people complaining about the title and it being offensive and detracting from the discussion, so those individuals are unable to get past their issues and to the meat of all this great JS engine stuff. Nevertheless, I got a ton of information out of it.

    • Jen Looper

      Thanks, Matt, hopefully folks will read on if they are interested.

  • Deepak

    awesome article πŸ™‚

    • Jen Looper

      Thanks, Deepak!

  • sumeet batheja

    Great article!

    • Jen Looper

      Thanks, Sumeet!

  • Note that today’s V8 also include TurboFan with the aim of augmenting/replacing Crankshaft: http://ariya.ofilabs.com/2014/08/javascript-and-v8-turbofan.html.

    • Jen Looper

      Thanks for noting this, I love the way they name the parts πŸ™‚

  • Pingback: Daily links 2015-10-09 | Marcin Kossowski()

  • Pingback: Weekly links 2015-10-11 | Marcin Kossowski()

  • Navin Krishnan

    Great article. Keep up the Good work !

  • Very clear & very informative, thanks for sharing.

    • Jen Looper

      Merci πŸ™‚

  • Pingback: Defining a New Breed of Cross-Platform Mobile Apps -Telerik Developer Network()

  • Pingback: What is a WebView? -Telerik Developer Network()

  • Tom de Groot

    Great article, thank you Jen!

  • Mehedi Hassan

    Nice article . I love to know how things work rather than how to make it work. And I loved it.

  • Pingback: An introduction to full-stack javascript web development (PART 1) | Harun Davood()

  • Pingback: Java Build Tools, JavaScript Package Managers and Task Runners (Part 3) - Ricston Ltd()

  • Pingback: Mobile Misfire: Chrome Mobile DevTools Put to the Test - Mobile1st()

  • munna

    Can any one help me out in this:
    Do all the developers of the different browsers available now for public use implement correctly ECMAScript?