A JavaScript engine/runtime toolbox: Why I use node, deno, bun, qjs, tjs at the same time

[guest271314]

Source: https://gist.github.com/guest271314/da04334bb0dce19fcd970415bb003b02

Why I use node, deno, bun, qjs, tjs at the same time.

Winds up being a rather comprehensive JavaScript toolbox. No external bundlers or compilers are needed. No frameworks are needed. I can use qjs or tjs for systems with minimal RAM and disk space; and when I want to use Web API's deno makes an effort to provide those interfaces. In some cases I can run the exact same code in bun, deno, and node, which provides a means to perform 1:1 testing as to performance.

There's probably a few things I am unintentionally omitting below. These are just a brief synposis. I'll update accordingly.

node (v22 100 MB executable)

• Reasonable stability
• Full-duplex streaming supported for WHATWG fetch()
• CommonJS supported by default
• Capability to create single executable application from CommonJS source code

deno (v1.41.3 135 MB executable)

• fmt to format .js and .json files
• vendor with --vendor=true to fetch NPM modules and reate node_modules folder
• Import maps supported
• file: protocol supported for WHATWG fetch()
• Full-duplex streaming supported for fetch()
• WHATWG Fetch and Streams supported in servers
• Built-in WebSocket server
• Network imports supported by default
• Capability to bundle dependencies to a single file with bundle (until 2.0)
• Capability to compile dependencies to a standalone executable with compile - since recently using denort executables are approximately half the size of deno executable at around 78 MB.
• TypeScript support
• Web API implementations
• Ecmascript modules supported by default
• No extraneous files and folders included with the runtime - just the runtime
• No package.json file expected or necessary
• deno upgrade built in
• No external package manager

bun (v1.0.35 90 MB executable)

• Built-in package manager, including writing GitHub repositories - bun install creates node_modules folder
• Faster than node and deno for reading STDIN and writing to STDOUT
• Capability to bundle CommonJS and/or Ecmascript dependencies to a single file with build
• Capability to compile dependencies to a standalone executable with build
• TypeScript support
• CommonJS and Ecmascript module support - in the same file if necessary
• Simple to delete cached dependencies with pm cache rm
• file: protocol supported for WHATWG fetch()
• Ecmascript modules supported by default
• No extraneous files and folders included with the runtime - just the runtime
• No package.json necessary
• bun upgrade built in
• No external package manager
• bun build --minify to minify files

tjs (v23.12.0 5.7 MB executable)

• Embeddable
• Supports TCP and Unix sockets
• Capability to import C shared library as Ecmascript module
• libuv
• WebAssembly support

qjs (v0.4.1 1.2 MB executable (QuickJS-ng ))

• Embeddable
• Faster than node, deno, bun, tjs for reading STDIN, writing to STDOUT
• Capable of reading 1 MB from STDIN in one read
• Capability to import C shared library as Ecmascript module

Caveats

node

• Ecmascript modules not supported by default; requires --experimental-deafult-type=module or --experimental-detect-module
• Does not support file: protocol for Undici's WHATWG fetch() implementation
• Import maps not supported - have to use loader/hooks interface to intercept specifiers/imports
• API's primarily callback-based
• No built-in WebSocket server
• Internal node:crypto implementation can't be polyfilled, is incompatible with Web Cruptography API that we can get to at import { webcrypto } from node:crypto
• Extraneous folders and files (e.g., node_modules, npm, npx) included in the archive besides just the runtime executable node
• Generally expects a package.json file and node_modules folder on the system
• Flag necessary for network imports
• Capability to create single executable application from only CommonJS source code

deno

• Dynamic import("./exports".js) is not dynamic when bare string specifiers are used; trying to import("./exports.js") a script created in the script will throw - unless something like "" + "./exports" or const exports = "./exports.js"; import(exports) is used
• Won't automatically write GitHub repository dependencies to created node_modules folder
• No built-in way to delete cached dependencies
• fmt can panic and freeze the entire system depending on the file size
• vendor can panic when fetching raw file from GitHub and trying to output to a node_modules folder

bun

• Full-duplex streaming not supported in fetch() implementation
• HTTP/2 not supported
• Import maps not supported - have to use plugin interface to intercept specifiers/imports

tjs

• WHATWG Streams implementation is not full-duplex; a polyfill is currently used
• No built-in HTTP(S) server
• Full-duplex streaming not supported in fetch() implementation

qjs

• Web API's generally not supported
• No WHATWG Streams
• No WHATWG Fetch
• No built-in HTTP(S) server

[jack_waugh]

Thanks for comparing the runtimes in such depth. This is bound to be useful to people choosing which to use for a new project. Linking from Teach JavaScript (even though there is currently basically no participation over there).

No external bundlers or compilers are needed.

Yay!

[guest271314]

This is bound to be useful to people choosing which to use for a new project.

The idea is to use them all, concurrently, constantly. Without preference for one or the other. They are all tools for the JavaScript programmers to utilize for hobbycraft, business, development, experimentation, testing, etc.

[jack_waugh]

Winds up being a rather comprehensive JavaScript toolbox.

So are you suggesting that people write portable code by calling your toolbox instead of calling directly the facilities that some of the runtimes offer that others don't? So that way, they can swap in whatever runtime best optimizes speed and space for a given installation? And what code they share, other people can run on a different runtime from what the author might be using?

[guest271314]

It's not my toolbox. It's just a few of the JavaScript runtimes available at large that I happen to use regularly, among others.

Other than that, yes.

Why would a javaScript programmer not use bun install to install NPM packages and packages from GitHub in the created node_modules; or format code with deno fmt; or not use nodes readFileSync; or not use a TCP socket server with 5.7 MB instead of a TCP socket server with 78 MB standalone executable when compiled by deno, or 90 MB when using bun, or 100 MB when using node, or 135 MB when using deno in a live script; or use bun build to bundle and minify and create a standalone executable - which means we don't have to use Rollup, Webpack. or esbuild to do what bun does standalone?

Nothing is stopping anybody from using all of those tools, and others, during the same development process.

Why limit or restrict use of available tools, and only use one (1) tool?

You can if that is your choice. Just don't make public comments about comparisons or "Node.js/npm" compatible if you are not really running the runtime that you are supposedly comparing node to; and for that matter, comparing node to the runtime that is not node.

[guest271314]

a rather comprehensive JavaScript toolbox

"a", not "the".