I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens?
If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for some value of "work") in the other engines, so that their code can still be "portable" (i.e. at least not crash) despite calling the feature. Also, eventually, the other engines might introduce their own versions of the feature, with their own APIs, for the polyfill to fill over; and then even more eventually, those will get standardized.
If there's a huge demand for the feature (think: XMLHTTPRequest), then other engines will rush to just clone the feature's API as-is, so that their engine won't be held back by the lack of it, or by the bad performance of a polyfill solution.
But if there's next-to-no demand for doing what the feature does, such that you can predict that nobody will even bother to write a polyfill, let alone port the feature, and so the feature will languish in that one engine — then yes, people will intentionally avoid using that feature at that point. See e.g. most of the Microsoft ActiveX-based stuff you could do in Chakra (IE's long-dead JavaScript engine.)
Also FWIW, all of these various runtimes are starting to converge on a single spec so they are interoperable and your code is truly portable — https://wintercg.org/
Having a feature is not the same thing as having API compatibility with Node's implementation of the feature. I think people are worried that an exciting project that aimed to have a different approach and a different set of trade-offs from Node will end up having to support everything that Node does, possibly inheriting its trade-offs and losing the freedom to innovate that they started with.
Even if there's no technical trade-off, it does seem that most of their engineering efforts will be focused on backwards compatibility with Node, instead of the new vision that they were promising.
I’ve seen this type of thing in vanilla js vs react projects. Where there was a fine vanilla js implementation, but it was abandoned by maintainers to do a react version.
Or a new frontend package is built for react by default rather than vanilla js, (or a very light set of js dependencies) even if it easily could have been.
And my experience is that react has been corruptive to the vanilla js ecosystem as a result.
It’s a bit of a reverse from node->deno but I could easily see how deno would be stunted or affected in an unknown but possibly not great way by this.
All that said, Deno has had to pivot because node seems to have gotten its act together to some extent. At least compared to when Deno set out.
So as a practical user acquisition need, not want but need, Deno had no choice but to do this. And the decision to go down this path was made quite a while back, iirc.
I remain hopeful for Deno and the team behind it. Frontend tech is very competitive.
The thrashing across the frontend stack that backend folks recoil from has made things stronger and there’s a lot of talent at work.
I think that most wanting to use Deno are wanting to write an application in a more Deno friendly way. Linting, formating, and typescript in the box. But pragmatically also needing or desiring to be able to utilize existing NPM modules. Those NPM modules more often than not needing node compatibility.
It doesn't mean the application at its core will be more node based so much as wanting to be able to use a given NPM module.
Just want to point out one issue in your comment -- webkit, blink would be more suitable as examples for "browser runtimes". V8 and JavaScriptCore are JavaScript engines. In other words, the page here is more about platform APIs (or maybe "standard library") rather than JavaScript language features. V8 vs JavaScriptCore vs SpiderMonkey doesn't matter to most developers because they are mostly up-to-date with ECMAScript specs and the behavior is mostly consistently, while different browser engines have varying support for features.
Sure, but the sort of features I was referring to are more to do with things where one JS engine introduces a new pre-standardization language feature, like async/await. This used to happen a lot, before the standards got ahead of the implementation with E6.
Unlike with browser-embedded JS engines, where "what native APIs are accessible from JS" is a relevant question†, in backend JS runtimes the answer to that question is always "all of them, because they're all just C FFI libraries, and these runtimes use the same C ABI, allowing interoperation with any such library." So for backend runtimes, it's only things to do with the JS engine itself — like language features — where the differences really matter.
† And actually, browser JS engines could have gone this way as well, if NPAPI/PPAPI <object> had caught on. The "Java" in "JavaScript" was supposed to refer to using Java applets as ActiveX-like COM servers which would expose APIs to be scripted against! In other words: a common-standard for native FFI, just with sandboxing.
If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for some value of "work") in the other engines, so that their code can still be "portable" (i.e. at least not crash) despite calling the feature. Also, eventually, the other engines might introduce their own versions of the feature, with their own APIs, for the polyfill to fill over; and then even more eventually, those will get standardized.
If there's a huge demand for the feature (think: XMLHTTPRequest), then other engines will rush to just clone the feature's API as-is, so that their engine won't be held back by the lack of it, or by the bad performance of a polyfill solution.
But if there's next-to-no demand for doing what the feature does, such that you can predict that nobody will even bother to write a polyfill, let alone port the feature, and so the feature will languish in that one engine — then yes, people will intentionally avoid using that feature at that point. See e.g. most of the Microsoft ActiveX-based stuff you could do in Chakra (IE's long-dead JavaScript engine.)