JavaScript Containers - The Future of Server Abstractions

Docker changed everything. By packaging applications with their dependencies into portable containers, it solved the age-old "works on my machine" problem and made deploying complex server software almost trivial. Linux containers became the standard unit of deployment.

But what if we're still working at too low a level?

Most server programs consist of a file system, executables, shared libraries, and integration with system software like systemd or nsswitch. Linux containers elegantly encapsulate all of this—but for many web services, much of that complexity is unnecessary boilerplate.

There's a simpler abstraction emerging: JavaScript containers. Not containers running JavaScript, but JavaScript itself as the container.

This idea isn't new. Back in 2018, Zack Bloom at Cloudflare proposed that JavaScript sandboxes could provide a new type of self-contained server environment. Browser JavaScript already offers a hermetic, secure execution environment—just at a higher level of abstraction than Linux containers.

The vision is compelling: The more unnecessary abstractions we remove, the closer we get to "The Network Is the Computer." Cloudflare Workers pioneered this concept on the Cloudflare network. Deno Deploy is now implementing it on Google Cloud Platform.

Let's explore why JavaScript containers represent the future of server abstractions—and how this technology will evolve over the coming years.

Predicting technology trends is notoriously difficult, but here's a safe bet: the World Wide Web will still be here in 10 years. Every day, more human infrastructure moves online—the web truly is eating the world. And if the web will be here, so will its foundational standards: HTTP, HTML, CSS, and JavaScript.

JavaScript isn't just another scripting language. It's the language of the web—the fundamental medium of human information in the digital age. Unlike Python, Ruby, or Perl, JavaScript is inextricably woven into the fabric of the internet itself.

For most server-side problems, the bottleneck isn't computation—it's productivity. How quickly can you write the code? How much do the developers cost? Scripting languages excel here, allowing business logic to be written faster and more economically than compiled languages.

Yes, Python, Ruby, Lua, Perl, and JavaScript are all fairly similar. They share comparable syntax patterns and programming paradigms. Anyone who's worked in Rust or C understands the distinct "feel" of scripting languages—they trade raw performance for developer ergonomics.

But here's the key insight: among all scripting languages, JavaScript is by far the most widely used and future-proof. It's not going anywhere. This makes JavaScript the de facto universal scripting language for the foreseeable future.

The JavaScript sandbox itself is emerging as a higher-level container for server software. This isn't meant to replace Linux containers entirely—rather, it addresses a specific, common use case with dramatically less complexity.

Reduced cognitive load: Every web engineer already knows JavaScript browser APIs. When the server-side container uses those same APIs, the total knowledge required shrinks. You're not context-switching between browser JavaScript and a completely different server environment.

Less boilerplate: For typical web services, systemd configuration files are just ceremony. You don't need them. JavaScript containers eliminate this unnecessary complexity.

Familiar patterns: The universality of JavaScript reduces conceptual overhead. One language, one set of APIs, from browser to server.

Think about how shell scripts work. Shell (Bash, Zsh) is the interpreted glue language that orchestrates Unix programs. It has conditionals, loops, and variables—but it's limited and awkward to program in. For real computational work, you invoke executables: imagemagick for image processing, ffmpeg for video, compiled programs for heavy lifting.

JavaScript containers follow the same pattern, but at a higher level:

• JavaScript is the orchestration layer (much better than shell for actual programming)
• WebAssembly is the compiled executable layer (for performance-critical operations)

Need to resize images? Write that in Rust, compile to Wasm, and invoke it from JavaScript. Just like you wouldn't write image processing in Bash—you'd shell out to imagemagick—you wouldn't write it in JavaScript either. You'd use Wasm.

The result is a clean separation of concerns with familiar mental models.

The future of server-side scripting is convergence with browser JavaScript. The fundamental mistake of Node.js was diverging from browser standards as they evolved.

When Node.js launched in 2009, many modern JavaScript features didn't exist yet. ES modules weren't standardized. Promises were a third-party library. async/await was years away. Node had to invent its own solutions.

But once these features were standardized, Node should have adopted them. Instead, it maintained its own parallel ecosystem:

• CommonJS require() instead of ES modules
• package.json and node_modules instead of web-standard module resolution
• Custom APIs instead of fetch, Web Streams, and other standardized APIs
• Global objects like process that don't exist in browsers

These antiquated, non-standard patterns created friction. Developers had to learn two different JavaScript environments. Code wasn't portable between browser and server.

Eventually, these Node-isms will either be standardized and brought into browsers (unlikely) or replaced by web-aligned alternatives (already happening with Deno).

JavaScript containers aren't fully standardized yet. We're still figuring out the ideal APIs. For now, Cloudflare Workers and Deno Deploy use the browser-standard FetchEvent API:

addEventListener("fetch", (event) => {
  event.respondWith(new Response("Hello world"));
});

This is elegant—it's literally the same API that service workers use in browsers. But it might not be the final answer. Better interfaces may yet emerge as the ecosystem matures.

Let's be clear: Linux containers aren't going away. They serve a critical purpose and will always be necessary for certain types of infrastructure. But for the vast majority of web service business logic, they're overkill.

When you're building a typical web application, do you really need to configure systemd? Manage file system permissions? Debug library dependencies? Usually not. That's all boilerplate—necessary complexity imposed by the abstraction level, not by your actual problem domain.

JavaScript containers offer a radically simpler alternative for web services:

✅ Same APIs browser to server - No context switching
✅ Zero configuration - No systemd, no Docker files
✅ Built-in security - Sandboxed by default
✅ Instant cold starts - No container orchestration overhead
✅ Standards-based - Future-proof with web platform evolution

JavaScript's universality enables a new container-like abstraction that simplifies server deployment. Perhaps the majority of web services—APIs, static sites, serverless functions, web apps—can be reimagined as JavaScript containers rather than Linux containers.

This doesn't diminish the importance of Docker and Kubernetes. It just means there's a higher-level, more productive abstraction available for a large class of common problems.

At Deno, we're actively exploring these ideas, working to radically simplify the server abstraction. The goal isn't to replace existing tools—it's to provide a better default for the most common use cases.

If this vision resonates with you, we'd love to have you join us. We're hiring.

Essay by Ryan Dahl, creator of Node.js and Deno

Photo by James Wiseman on Unsplash