JS, ECMAscript and Runtime

At this point, I assume you have some basic ideas of how to write your own Javascript files and utilize the different functions. For starters, you have built-in methods for manipulating strings, arrays and objects, then you have those special functions such as setTimeout and setInterval which on the surface does not seem possible in a synchronously executed language. (Javascript is NOT an asynchronous language!!!) You also have access to local storage, cookies, history, fetch, geolocation and many more functionalities that are non-existent in "barebone" Javascript.

Javascript and ECMAscript

So what actually is Javacsript? Time for a little history lesson. Back in 1994, the team at Netscape wanted to add functionalities to their Netscape Navigator browser to support websites with dynamic behaviours. They had a couple options but eventually they went with devising a new language that have a syntax similar to that of Java. In 1995, Javascript was born and it soon gained lots of popularity and traction.

While all of that is happening, a browser that you have definitely heard of just got debuted: Internet Explorer. Just like Netscape, Microsoft also wanted to support dynamic websites and went its own way to develop another language called JScript in 1996. Writing in JScript vs writing in Javascript had noticeable differences and it made developers had a hard time learning both languages.

Later towards the end of 1996, to make Javascript into a standard that other browsers can conform to, Netscape submitted Javacript to Ecma international, which is an organization that develop and documents computer system standards, and the first version of ECMAscript was born in 1997. After that in every new version of ECMAscript released, it specifies what methods and new features that Javascript should have. For example, functions such as .map() that we use everyday was introduced in ECMAscript5 (2009) or ES5. (For a more detailed list of what is introduced in each version, check out this Medium article.)

So ECMAscript is the blueprint and Javascript is the physical language implementing it. It is like a class and object in OOP. The class defines what properties and functions and the object is a physical instance of the class.

Javascript Engines and Host Environments

But why do we always hear stuff like "This function is not yet implemented/not supported in Internet Explorer (IE). You should consider using polyfills or fallback to ES5 syntax" if there is only one standard? Well, as you already know, Javascript is not confined to running in a browser. You can run it in Node JS, Deno and Bun as well, just to name a few. So the question is what actually is translating the codes you write to machine codes that can be executed?

In browsers, Node, Deno, ..., they all have a Javascript engine that is capable of parsing codes and running them. In Chrome and Node, the Javascript engine used is called V8 (not to be confused with the car engine V8, tho the naming is based on it). Firefox uses Spidermonkey and Bun uses JavascriptCore.

Each of these engines have their own unique inner workings and features. If you strip browsers and Node, Deno, ... down to only the engine and nothing else, you don't have those magic setTimeout, setInterval functions anymore. Javascript at its core is a high-level language that is single-threaded and synchronous. You can still define variables and classes and invoke functions but that is about it. All other magical stuff comes from interacting with the host environment or runtime, which is all of the Chrome, Firefox, Node and Deno that I have mentioned.

Here is a glimpse of what extra stuff a browser such as chrome provides.

Don't worry, I will get to how each elements work and how they interact with each other in the next chapter. The diagram would be different in Node and other runtime since Node has a different inner working and supports additional features like file systems. As such, different runtime can have different sets of features and you should not expect that writing code in one runtime will 100% work in another runtime.

The takeaway is that each host environment will have a Javascript engine used. And that very engine needs to implement the specs defined in the ECMAscript (with the help from the additional features the host provide), meaning it needs to be able to parse codes that use the new functions and syntaxes. This is the reason why some newer methods might not be available in some browsers and runtime and why there is a whole website dedicated to documenting browser supports.