Is Node.js Dying?
geekyhacker.com
geekyhacker.com
io.js was separate from Node for a while, had a few core passionate fans, but didn't really see widespread adoption. It inspired node.js maintainers to do better though and eventually the two projects merged together and Node became better for it.
JS itself has been around for 24 years now and has gradually evolved over the years with new keywords and functionalities to keep up with the times. Node has done the same, and can easily adopt many of the things that Deno has.
Perhaps some of the solutions in Deno can be ported to node, but others certainly can't. For example, there's so much dependency on node-gyp that it's unlikely it will ever go away.
By porting Deno's features to node you will be introducing so many backward compatibility issues and friction that it will be the same as porting your libraries and applications to Deno.
What percentage of nodejs packages run on both node and the browser and do you expect that number to go up or down over time?
If it goes up -- the percentage of node packages that run on deno also goes up.
Code that runs in the browser is very valuable because it is an incredibly widely deployed user eyeball platform ... the browser _is_ the center of the javascript ecosystem -- and so there is already built-in pressure to migrate from node to deno -- especially if/when deno's browser matching api implementations become part of the compatibility testing matrix for a major browser vendor (like chrome or firefox) ...
Deno will surf uphill on the ever rising value of browser compatibility until projects are actively weeding out any dependencies which "run only on node".
Even given the huge dependency graphs of node applications -- you don't really have to replace that many high level dependencies before you've migrated yourself to deno ... -- and you will experience incremental benefit for partial steps along the way as you do ...
In a world with Docker, encapsulating a node process to a limited file system seems like an acceptable enough of a solution today (note: I am not a DevOps person, there likely is more nuance here)-- it's challenging to assess if the benefits of Deno outweigh the pain of migration.
Regardless of the outcome, all efforts to improve the server-side JavaScript space are appreciated.
GraalJS can run all NPM modules on top of the JVM, in fact it supports both "pure" running JS on top of the JVM and also provides a mode in which it replaces V8 in the original Node binary, for extra compatibility with e.g. native extensions.
This gives you at least three major tech wins:
1. Interop with the entire Java ecosystem and also as other Graal languages improve, with them too (e.g. Graal's Ruby support is pretty great, Python is maturing)
2. Extremely efficient and scalable pauseless garbage collectors.
3. Ability to do shared-memory multi-threading by sharing Java objects between workers.
And soon via Project Loom there'll be very light weight fibers too i.e. you can write your code in a fully blocking style, no promises or async/await, but it'll be just as efficient as Node.
It can load sources from URLs too (see https://github.com/graalvm/graaljs/blob/master/docs/user/Jav...)
It feels like Deno has focused on adding JS-specific features, and sandboxing is an admirable goal. Obviously GraalVM can do that too as long as you're in pure JVM mode, and aren't installing native/C++ Node extensions. So it may well be that Deno is more attractive to pure-JS hackers. But for people who need or want to bridge ecosystems, or scale a single JS program up to much larger heaps and higher performance programs, GraalJS is a serious competitor. Probably Node people don't take it too seriously because it's sort of outside their social circles.