Inside Deno, Bun & edge runtimes

One language, different runtimes

JavaScript is the recipe. A runtime is the kitchen that runs that recipe and adds a timer, network access, files, modules, and a process model. Deno, Bun, Node, and edge platforms can all run JavaScript while making different choices around the language.

This lesson uses small web-style handlers because they make the shared part visible. It then names the extra layers accurately: Deno uses V8 and Rust with Tokio; Bun uses JavaScriptCore and native layers; many edge systems use V8 isolates. The details are not interchangeable.

The previous Node.js architecture lesson explains one V8-based server runtime. This lesson compares choices around it, and Embedding V8 explains the isolate vocabulary underneath.

Start with portable web APIs

A server handler often needs only a request URL and a response body. The example below works in a modern browser sandbox and Node because it uses the web-style Request, Response, and URL objects instead of a runtime-only namespace.

1async function handle(request) {2  const url = new URL(request.url);3  return new Response(`Hello from ${url.pathname}`);4}5 6(async () => {7  const response = await handle(new Request("https://shop.example/cart"));8  console.log(await response.text());9})();

Line 1 names the handler and receives one request. Line 2 creates a URL from request.url. Line 3 returns a response whose body includes the pathname. Lines 7 and 8 call it and print Hello from /cart.

1async function handle(request) {2  const url = new URL(request.url);3  return new Response(`Hello from ${url.pathname}`);4}5 6(async () => {7  const response = await handle(new Request("https://shop.example/cart"));Run8  console.log(await response.text());9})();

This does not mean every runtime has every browser API. It means small pieces of code can target a common shape first. Keep file access, database clients, and provider bindings behind a small adapter when they are not part of that shape.

Deno: V8, Rust, and Tokio

Deno's official architecture describes V8 as its JavaScript engine, Rust operations around the engine, and Tokio as the scheduler for asynchronous work. Its documentation also presents Deno as a JavaScript, TypeScript, and WebAssembly runtime with secure defaults.

A secure default is a host policy, not a new JavaScript syntax rule. Deno documentation says code has no file, network, or environment access until permission is granted. Your handler can still use ordinary JavaScript objects, promises, and web APIs.

1const path = "/cart";2console.log(new Response(`Saved ${path}`).status);

Line 1 stores a path. Line 2 creates a standard response and prints 200. The status is the normal default for a new response, so this tiny part does not need the Deno global.

Bun: JavaScriptCore and native layers

Bun's runtime documentation says Bun uses Apple's JavaScriptCore engine, the engine used by Safari. JavaScriptCore is a different engine from V8, yet both execute JavaScript and can expose web-style APIs such as fetch, Request, and Response.

The curriculum label mentions Zig because Bun was originally known for its Zig implementation. Current official Bun runtime documentation describes its transpiler and runtime as written in Rust. This lesson follows the current runtime documentation rather than freezing an old detail.

1const order = { item: "tea" };2console.log(order.item);

Line 1 creates an ordinary object. Line 2 prints tea. Engines differ in implementation, but this language behavior is the same JavaScript idea that portable application code should lean on.

Detect a runtime carefully

Portable code should not guess a runtime from an operating system name or a user agent. When you truly need a runtime-only capability, test for the specific global or API you plan to use, then keep that branch small.

1const runtime =2  typeof Deno !== "undefined" ? "deno" :3  typeof Bun !== "undefined" ? "bun" :4  globalThis.process?.versions?.node ? "node" :5  "unknown";6 7console.log(runtime);

Lines 1 through 5 choose a label in order: Deno, Bun, Node, then unknown. Under Node, the third condition reads the version field and the snippet prints node. The label is useful for diagnostics; capability detection is better for a real feature.

For example, do not branch merely because the answer is Bun. Test that the API you need exists, document its fallback, and leave the portable handler free of that branch. This makes later migrations less surprising.

V8 isolates at the edge

An isolate is a lightweight V8 execution context with its own memory and globals. Cloudflare documents that one Workers runtime instance can run many isolates, and that each isolate's memory is isolated from other code in that runtime.

That isolation is useful for running many pieces of untrusted or separate application code. It does not turn a module-level variable into durable storage. Cloudflare also documents that isolates can be evicted, and requests are not guaranteed to reach the same Worker instance.

1function createStation(name) {2  return { name, globals: { orders: 0 } };3}4 5function serve(station) {6  station.globals.orders += 1;7  return station.name + ": " + station.globals.orders;8}9 10const first = createStation("first");11const second = createStation("second");12console.log(serve(first));13console.log(serve(second));

Line 1 creates a model station with its own orders global. Line 5 increments that station only. Lines 9 and 10 create two stations, and lines 11 and 12 print first: 1 then second: 1. It is a teaching model, not a V8 implementation.

Read Embedding V8 for engine-level isolate and context terminology. Here the practical rule is simpler: pass state through requests or durable services, not through a hope that one isolate will remain alive.

Separate globals in a teaching model

The handler replay uses real lesson code and follows a request from URL to response. It does not pause Deno, Bun, Node, or an edge provider. Its purpose is to make the portable boundary visible before the runtime begins routing real traffic.

1async function handle(request) {2  const url = new URL(request.url);3  return new Response(`Hello from ${url.pathname}`);4}5 6(async () => {7  const response = await handle(new Request("https://shop.example/cart"));Run8  console.log(await response.text());9})();

Notice what the replay does not show: an engine heap, a provider scheduler, or a promise about reuse. Those are runtime and platform details. The portable contract remains the request in and response out.

WinterTC and common runtime APIs

WinterTC, also called Ecma TC55, is a standards committee for web-interoperable server runtimes. Its scope is a minimum common API: a curated base of web-standard interfaces that server environments can support together.

In daily code, think of the shared minimum as familiar building blocks: fetch, Request, Response, URL, TextEncoder, crypto.randomUUID, timers, and streams. A runtime still decides versions, limits, and additional APIs.

1const commonApis = [2  ["fetch", typeof fetch],3  ["Request", typeof Request],4  ["Response", typeof Response],5  ["URL", typeof URL],6  ["TextEncoder", typeof TextEncoder],7  ["crypto.randomUUID", typeof crypto.randomUUID],8];9 10console.log(commonApis.map(([name, type]) => name + ": " + type).join(", "));

Lines 1 through 8 list the portable names and inspect each one. Line 10 prints fetch: function, Request: function, Response: function, URL: function, TextEncoder: function, crypto.randomUUID: function when all six are available. This is a capability check, not a promise that every runtime has the same limits or extra APIs.

1const commonApis = {2  fetch,3  Request,4  Response,5  URL,6  TextEncoder,7  "crypto.randomUUID": crypto.randomUUID,8};9 10const missing = Object.entries(commonApis)11  .filter(([, value]) => typeof value !== "function")12  .map(([name]) => name);13 14console.log(missing.length === 0 ? "portable base available" : "missing: " + missing.join(", "));

Lines 1 through 8 gather the functions a handler wants. Lines 10 and 11 collect only missing names. Line 14 prints portable base available when all are present. In a real adapter, use that result to choose a fallback or state a deployment requirement.

Cold starts and warm reuse

A cold start is the work a platform performs before a fresh execution environment handles work. The exact work and timing depend on the provider, deployed code, engine, cache state, and platform policy. Do not turn a number from one benchmark into a universal rule.

Edge platforms often use isolates rather than a whole new container for every request. Cloudflare documents isolates as lightweight contexts created inside an existing environment. That explains the design goal, but it does not promise one timing for every edge platform or deployment.

1function countColdStarts(requestTimes, warmForMs) {2  let lastRequest = null;3  let coldStarts = 0;4  for (const time of requestTimes) {5    if (lastRequest === null || time - lastRequest > warmForMs) coldStarts += 1;6    lastRequest = time;7  }8  return coldStarts;9}10 11console.log(countColdStarts([0, 5, 10, 50], 20));

Lines 1 through 9 count a cold start for the first request or for a gap larger than a made-up warm window. Line 11 prints 2 for the invented request times. The number teaches the decision rule only; it is not a Deno, Bun, or edge benchmark.

1function countColdStarts(requestTimes, warmForMs) {2  let lastRequest = null;3  let coldStarts = 0;4  for (const time of requestTimes) {5    if (lastRequest === null || time - lastRequest > warmForMs) coldStarts += 1;6    lastRequest = time;7  }8  return coldStarts;9}10 11console.log(countColdStarts([0, 5, 10, 50], 20));Run

1function countColdStarts(requestTimes, warmForMs) {2  let lastRequest = null;3  let coldStarts = 0;4  for (const time of requestTimes) {5    if (lastRequest === null || time - lastRequest > warmForMs) coldStarts += 1;6    lastRequest = time;7  }8  return coldStarts;9}10 11console.log(countColdStarts([0, 5, 10, 50], 20));

Choose APIs for portability

Start a server feature with a standard handler shape when it fits: receive a request, parse a URL, fetch a service, and return a response. This lets you test most behavior without binding the whole application to one runtime on day one.

Then make runtime-specific code explicit. A Deno permission choice, a Bun namespace API, a Node built-in module, and an edge provider binding are all reasonable when needed. Place each behind a named adapter with a clear fallback or deployment requirement.

• Prefer Request, Response, URL, fetch, streams, and encoders for shared server code.
• Feature-detect the exact optional API before calling it.
• Keep durable data outside isolate globals.
• Measure cold-start behavior in the target deployment instead of quoting generic numbers.

Common runtime misconceptions

It is tempting to use short labels such as “V8 runtime” or “edge is fast” as complete explanations. They are not. An engine, runtime, and hosted deployment each own different parts of the behavior a developer sees.

• “JavaScript requires V8.” Bun demonstrates that JavaScript can run on JavaScriptCore.
• “An isolate is durable storage.” Isolates can be reused or evicted; durable state belongs in a durable service.
• “WinterTC removes all runtime differences.” It aims for a common base, while runtimes keep extras and policies.
• “Cold start has one published number.” It depends on the platform and deployment, so measure the actual target.

Practice exercises

async function handle(request) {
  return new Response(new URL(request.url).pathname);
}

(async () => {
  const response = await handle(new Request("https://shop.example/cart"));
  console.log(await response.text());
})();

const runtime = globalThis.process?.versions?.node ? "node" : "unknown";
console.log(runtime);

console.log(countColdStarts([0, 5, 10, 50], 20));

Check your understanding

Use the handler's code, the engine/runtime boundary, and the cold-start model to test each answer.

Key takeaways

• JavaScript is the language; engines execute it; runtimes add host APIs and deployment choices.
• Deno uses V8 with Rust and Tokio, while Bun uses JavaScriptCore with native runtime layers.
• Request, Response, URL, fetch, streams, and encoders make a useful portable server baseline.
• Edge isolates have separate memory and globals, but platform reuse and eviction mean globals are not durable storage.
• WinterTC / Ecma TC55 works toward a minimum common API for server runtimes.
• Cold-start numbers must be measured in the target platform; the lesson model only explains warm reuse.

Coming next: Small & embedded engines, where JavaScript engines trade memory, startup, and language completeness for different devices.