Why Are There So Many JavaScript Runtimes?

TL;DR

JavaScript has many runtimes because different environments impose different constraints, so one implementation cannot fit every task. Traditional serverless platforms can reuse warm instances, while globally distributed edge systems frequently initialize code near users and therefore prioritize tiny bundles, fast cold starts, low resource use, and APIs designed specifically for that execution model.

Transcript

There's a lot of JavaScript runtimes, like a lot of them. Porfer, V8, Node, Dino, Bun, and many, many more. I'm not even talking about the weird platform specific stuff like workerd just yet, but we're going to get into all of that and more. Why though? Why are there so many runtimes? Why are we not all just using one? What's so special about one r... Read More

Key Insights

• JavaScript runtime diversity is a consequence of the language spreading across servers, cloud platforms, edge networks, smart TVs, mobile devices, and microcontrollers. Each context has distinct limits and goals, so no single runtime or engine is equally suitable for every use case.
• An engine and a runtime are related but distinct concepts, as illustrated by JavaScriptCore being described as the engine underlying Bun. The transcript also identifies systems such as Node.js, Deno, Bun, workerd, QuickJS, Hermes, Porffor, V8, and LLRT within the broader ecosystem.
• Server-side JavaScript became practical with Node in 2009, and AWS Lambda brought Node into a serverless context in 2014. Lambda@Edge entered preview in December 2016 and was released in March 2017, extending JavaScript execution toward edge locations.
• Cloudflare Workers arrived six months after Lambda@Edge and used a purpose-built minimal runtime centered on the service worker API. Its design reflected Cloudflare's effort to create a market for compute and storage by directly productizing a JavaScript runtime.
• Edge computing reduces user-to-server distance by placing execution closer to users, which can shorten network round trips. The benefit becomes more significant when a request requires several exchanges, since every additional trip increases the time before the user receives a response.
• A centralized database can limit the latency gains of edge execution because moving application code closer to users may simply relocate the long-distance communication. Edge processing works better when requests need little database interaction or when it can immediately return content and route traffic intelligently.
• Traditional Lambda instances can remain available after startup, allowing later requests to reach warmed code. With hundreds of distributed edge locations, users often hit different servers, making cold initialization more common and changing the runtime requirements substantially.
• Edge runtimes prioritize fast cold starts, small bundles, and efficient operation on limited compute. The transcript estimates an edge server may have about one-fifth the CPU power of a base-tier Lambda, so complex rendering can take longer despite the server's proximity to users.

Questions & Answers

Q: Why are there so many JavaScript runtimes?

There are many JavaScript runtimes because JavaScript now runs in environments with very different operating constraints. Servers, serverless functions, globally distributed edge workers, mobile devices, smart TVs, and microcontrollers do not share the same startup, compute, memory, or API requirements. Runtime implementations therefore specialize for particular contexts instead of relying on one design for every possible workload.

Q: What is the difference between a JavaScript engine and a runtime?

A JavaScript engine is presented as a component that executes JavaScript, while a runtime is the broader environment in which code operates. The transcript uses JavaScriptCore as an example of an engine underlying Bun, while acknowledging that the categories can overlap or become unclear. Hermes is similarly described as involving compilation and just-in-time behavior while still qualifying as a JavaScript runtime.

Q: How did JavaScript reach serverless and edge computing?

JavaScript became useful as a server-side language when Node emerged in 2009. Node then entered a serverless setting through AWS Lambda in 2014. Lambda@Edge followed in preview during December 2016 and was released in March 2017. Six months later, Cloudflare Workers introduced a minimal, purpose-built runtime organized around the service worker API.

Q: How does edge computing reduce application latency?

Edge computing places code closer to users, reducing the physical and network distance that requests and responses must travel. This matters especially when an interaction requires multiple round trips, since each exchange adds waiting time. An edge server can also return static content quickly or determine which regional server should handle a request based on proximity or data location.

Q: Why can a centralized database weaken the benefits of edge computing?

A centralized database remains distant even when application code moves close to the user. If the edge code repeatedly communicates with that database, the long network path still exists and the latency has merely shifted to another connection. Edge execution is more effective when it needs little database communication, can return useful content immediately, or primarily routes requests to suitable infrastructure.

Q: Why are cold starts more important for edge runtimes?

Edge platforms may distribute code across hundreds of locations, and users can reach different locations on separate requests. That makes an already warm instance less likely than in a regional serverless deployment. Because edge code may be instantiated and removed for individual requests, the runtime must start rapidly, load small bundles, and operate efficiently on machines with limited computing capacity.

Q: How does the Lambda execution model differ from edge workers?

A traditional Lambda deployment runs code in one region and starts an instance when no suitable instance is already available. After handling a request, that instance can remain active in case more requests arrive, allowing many later requests to use warmed code. Edge workers are spread across many locations, so requests more frequently initialize isolated code near individual users.

Q: Why might complex rendering be slower on an edge server?

Proximity to users does not guarantee greater computing performance. The transcript states that an edge server can provide about one-fifth of the CPU power available from a base-tier Lambda. A complex page may therefore take longer to render on Cloudflare than on platforms described as providing stronger CPUs and more dedicated resources, despite the edge server's shorter network distance.

Summary & Key Takeaways

• JavaScript expanded beyond browsers into servers, serverless platforms, edge infrastructure, smart TVs, mobile devices, and microcontrollers. That spread created environments with sharply different requirements. Engines and runtimes therefore evolved around particular workloads instead of converging on one universal implementation that would perform equally well in every context.

• Edge computing places execution closer to users to reduce request distance and potentially deliver content sooner. Moving application code alone does not eliminate latency, however, because centralized databases may remain far away. Edge logic is most useful when it can respond without repeated database communication or efficiently route traffic to appropriate infrastructure.

• Traditional Lambda deployments and distributed edge workers have different lifecycle patterns. A regional Lambda instance may remain warm after serving requests, while traffic across hundreds of edge locations is less likely to encounter an existing instance. Edge runtimes consequently emphasize rapid initialization, compact code, low compute requirements, and per-request isolation.