Add Deno APIs on top of Node.js, instead of Node.js APIs on top of Deno

[jaydenseric]

Has the Deno team considered starting with Node.js, then adding on top of it Deno APIs, instead of the current opposite way around?

It's clear that Deno team has completely pivoted from the original vision of building a clean ecosystem of universal JS pure ESM packages intended to be imported over HTTP using web standard APIs, to focusing on improving the experience for the larger market of Node.js/npm devs using the Node.js APIs and npm ecosystem of packages.

I think this new focus is a tragic mistake; but if we assume for a second that this something to solve the most elegant technical way possible then wouldn't it make sense to simply enhance Node.js and avoid all the complexity and bugs associated with trying to recreate it again and continually re-implement their ongoing changes and enhancements with a slight (or major!) lag.

The Deno CLI would be pretty easy to implement with some old fashioned Node.js code.

You could get HTTP imports going with Node.js import loaders. HTTP imports and import maps are literally the one reason I ever built on Deno; ideas like runtime permissions and slightly nicer web standard inspired server APIs are nice, but don't deliver a fundamental capability that allows you to build something not possible on Node.js. The buildless React web application framework Ruck was not possible in Node.js back in the day; but now maybe it is with Node.js import loaders.

Some things would be better for everyone to just contribute them in upstream in Node.js, regarding moving to more web standard based APIs. Node.js has slowly been making progress here, but it could be faster if the people passionate about this were not splitting their focus over two runtimes/ecosystems. I'll admit the threat of competition from a seperate Deno runtime has motivated bursts of productivity in Node.js; namely getting the fetch API into core Node.js.

You could wrap Node.js server APIs to get more web standard looking APIs like Deno has.

The Deno global could be added to the Node.js runtime via an import hook on the CLI, without even having to fork Node.js.

In theory, Deno std could remain unchanged but you could re-implement them for efficiency to use Node.js APIs directly instead of the Deno APIs that would be wrapping the underlying Node.js stuff.

The Deno permissions system would be tricker to re-implement on top of Node.js. I'm not sure if it's impossible, or possible, depending if Node.js is forked or simply wrapped. But, honestly I don't care about it. I am happy to wait for a web platform standard permissions API to come and skip this Deno approach. Permissions were not the main reason I built on Deno.

Of course, there will arise the question, what's the point of exposing additional Deno APIs that do the same things as existing Node.js APIs, in the same runtime? Why would people want to opt-in to a runtime that offers multiple ways of doing the same stuff? Well, that same question applies to current day Deno now that Node.js/npm compatibility is built in. In fact, it seems the direction Deno is heading is making the Node.js globals available in all contexts: #29703 .

It would be an interesting hackathon goal to see how much Deno compat Node.js could be enhanced with.

[marvinhagemeister]

No, we're not going to throw away Deno and start from scratch. There are many features in Deno that don't exist in Node.

I think this new focus is a tragic mistake;

Quite the opposite actually. The Deno user base has seen a drastic uptick since we went strong on Node compatibility. Now people can integrate Deno into their existing projects which they couldn't do before. This makes adoption of Deno a lot easier.

The more people that can use Deno, the better. Even if it means reevaluating past strategies a little. You can find more details in the reasoning in various posts on our blog.

[jaydenseric]

The point of this post is not to advocate for a different API or drop npm compat. It's to ask if it would be more technically elegant to arrive at the same fusion of Deno and Node.js APIs the inverse way; by building on Node.js instead of the other way around.

[marvinhagemeister]

Programming in Rust is much more enjoyable and modern compared to C++ if technical elegancy is the main thing you're after.