<aside> 📌

The following content only includes Node.js, Deno, and Bun.

</aside>

Intro

It’s now 2024, and there’s a bunch of JS runtime. The history of JS runtime can actually be traced back quite a long time, in 1995.

This evolution isn't just about technical specifications; it represents a shift in how developers approach backend JavaScript development. From Node.js's extensive ecosystem to Deno's focus on security and Bun's emphasis on performance, each runtime offers a unique perspective on what server-side JavaScript can achieve.

As we delve into these runtimes, we'll explore how they're shaping the future of JavaScript beyond the browser, offering developers more choices and capabilities than ever. Whether you're a seasoned developer or new to the field, understanding these runtimes provides insight into the dynamic nature of JavaScript's server-side capabilities.

Why do we need a runtime?

JavaScript (or, more formally, ECMAScript) is just a specification for a programming language. Anyone can write a JavaScript engine that ingests a valid JavaScript program and executes it. Today's two most popular engines are V8 (developed by Google) and JavaScriptCore (developed by Apple). Both are open source.

But most JavaScript programs don't run in a vacuum. They need a way to access the outside world to perform valuable tasks. This is where runtimes come in. They implement additional APIs that are then made available to the JavaScript programs they execute.

Runtime vs Engine ??

Engine

A JavaScript engine is a program that executes JavaScript code. Its primary responsibilities include:

• Parsing JavaScript code
• Compiling the code to machine instructions (often using Just-In-Time compilation)
• Executing the code
• Managing memory allocation (including garbage collection)

Examples of JavaScript engines:

• V8 (used in Chrome and Node.js)
• JavaScriptCore (used in Safari)
• SpiderMonkey (used in Firefox)
• Chakra (previously used in Edge)