Will JavaScript containers outperform Linux containers? The Node.js creator believes that JavaScript containers can simplify writing web services

Ryan Dahl, creator of Node.js and Deno (like ‘Node’, but vice versa), recently said that he believes the majority of web services can be simplified by using JavaScript containers, rather than Linux containers. Specifically, the developers of Deno, the new runtime environment for JavaScript and TypeScript, are exploring the possibility of using JavaScript containers as a high-level alternative to Linux containers. Dahl sees the concept as promising, but some fear it will introduce other security issues to container infrastructure.

In a blog post published in early May, Ryan Dahl, who led the development of the JavaScript Deno (2018) and Node.js (2009) runtime engines, explained why he thought JavaScript containers might be a better alternative to Linux containers. In fact, the majority of server software is Linux software. It consists of a file system, some executable files, and possibly some shared libraries, which interact with system programs such as systemd where nsswitch. For Dahl, the use of Linux containers was mainly popularized by Docker.

Docker offers operating system level virtualization which provides a great mechanism for distributing server software. Each container image is a ready-to-run, dependency-free software package. According to Dahl, because server software often relies on many system resources and configurations, it has been difficult to deploy in the past. Linux containers solve this problem. However, Dahl believes that a similar tight environment can be found in a JavaScript browser, albeit at a higher level of abstraction.

The more we can remove unnecessary abstractions, the closer we will be to the concept of “the network is the computer”. He explained that Deno Deploy is a new implementation of this idea (on the GCP network). In his blog, Dahl called JavaScript a “universal scripting language” and speculated how JavaScript containers would evolve over the next two years. For him, scripting languages ​​are very useful in solving many server side problems. The majority of the code written is not about computation, but rather about productivity.

That is, the speed at which it can be written and the financial cost to the developers. Scripting languages ​​allow you to write business logic faster and cheaper. Scripting languages ​​(Python, Ruby, Lua, Shell, Perl, Smalltalk, and JavaScript) are quite similar. There are differences in the syntax and APIs, but there is not much to argue against them. Anyone who has spent time in Rust or C understands how scripting languages ​​feel. In short, scripting languages ​​are useful, but they all look the same, and JavaScript is by far the most widely used and developed, Dahl said.

He added that it makes sense to think of JavaScript as a universal scripting language. According to the creator of Node.js, a JavaScript container is not intended to handle the same amount of problems as Linux containers. Its appearance is the result of its simplicity. Dahl thinks it reduces the standard script for web services business logic. It shares concepts with the browser and reduces the concepts a programmer needs to know. (Example: When writing a web service, it is very likely that any systemd configuration is just an unnecessary standard code.)

Every web engineer already knows JavaScript browser APIs. Since the JavaScript container abstraction is built on the same browser APIs, the total experience an engineer needs is reduced. The universality of JavaScript reduces complexity. Shell is the interpreted scripting language used to invoke Unix programs. It can make conditional, loops, has variables, but unfortunately it is limited and difficult to program. Dahl said the real job is in the executables. In this new server abstraction layer, JavaScript replaces the shell.

It is more suitable for scripting than Bash or Zsh. Instead of calling Linux executables, as the shell does, the JavaScript sandbox can call Wasm. If you need to do heavy math, like resizing an image, it’s better to use Wasm instead of writing it in JavaScript. Dahl wrote, just as you wouldn’t write image resizing code in Bash, you would make the image appear. Finally, he admitted there were some bugs in Node.js, something he’s now trying to fix with Deno.

The future of scripting languages ​​is the JavaScript browser. js was deviating from the browser as new APIs were standardized, by inventing many things. In 2010 we didn’t have any ES modules, but once they were standardized it was meant to be integrated into Node. The same can be said about promiseAnd asynchronous / waitingAnd BringAnd streams, etc. , He said. Non-standard items such as package.jsonAnd node_modules And NPM eventually will either be standardized and added to the browser or replaced with web-compatible alternatives, he said.

Essentially, Deno’s Node.js creator believes that the universality of JavaScript promotes the emergence of a new container-like abstraction. Linux containers don’t go away, but thinking about JavaScript containers can simplify many web services. Dahl said he expects JavaScript container technology to grow over the next two years. Deno is exploring this idea, particularly in its product Deno Deploy, and is currently recruiting engineers to develop it.

Source: Ryan Dahl

And you?

What do you think about it?
What do you think of the concept of a JavaScript container?
What do you think of Dahl’s predictions for the future of JavaScript containers?
What do you think about using JavaScript containers instead of Linux containers?

See also

Podman: A cheat-free open source container engine designed to develop, manage and run containers on Linux, an alternative to Docker?

Red Hat research found that developers’ attractiveness to containers and Kubernetes is primarily driven by career advancement

51% of 4 million Docker images analyzed had critical vulnerabilities, some of which could be considered malicious, according to a study by Prevasio

Container security and compliance remain a major challenge as container adoption accelerates, with 89% of DevOps professionals deploying active deployments, according to NeuVector.

Leave a Comment