I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?
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.)
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.
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.
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.
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.
Deno does have some benefits, such as security model and speed, but those are not things that couldn't be added to Node. Once Node adds the security model why use Deno?
1. Native support for TypeScript.
2. Better built-in APIs.
3. Security model.
4. Easy package management.
Node.js is closing the gap. E.g. top-level await, fetch() API, Permissions.
I believe Node.js will follow Deno and implement more and more features. Sort of a npm/yarn situation.
It's cool to see what Deno does, but I don't think you will be left out by sticking with Node.js.
If anything, deno's package management is definitely not easy.
And no, "just throw your deps into deps.ts and re-export each manually" isn't easy either.
About the security model: can someone explain why it's a good idea to have isolation at the interpreter level rather than relying on OS features? (or VMs). I cannot see why a security team would want an isolation system that's different for a specific platform.
Those technologies are platform-specific and difficult to use.
For example, provide the command line for running a Node.js program in Linux without file system access.
In deno, it's
deno run main.ts
deno run --allow-read --allow-write main.ts
That said, I agree that I'd rather rely on containers, VMs, etc.
> docker run -it --rm -v "$PWD":/app -w /app node:18 node main.js
It's a tad longer but it's more flexible too ;)
But I do see your point :)
Forgive me if I don't believe that running a full OS on a host OS to run a single node command doesn't amount to running a VM.
You can think of Docker containers as a way to package an application dependencies, ending at the (Linux) kernel API/ABI.
As in: "a completely different node js binary in its own environment, its own networking, its own file system overlay etc."
Or the millions of daily passengers in transport mechanisms powered by high integrity operating systems.
Zero POSIX.
And almost all systems on AWS are running on Linux/KVM. Even quite a few that report as Xen are actually running on KVM; Amazon added a bunch of code to KVM to lie on guest hypervisor cpuid leaves as well as emulate Xens hypercall interface.
Which happens to be a special Windows build, Azure Host OS.
https://techcommunity.microsoft.com/t5/windows-os-platform-b...
Additionally, bare bones Linux kernel infrastructure for Xen and KVM support isn't UNIX.
"Transcending POSIX: The End of an Era?"
https://www.usenix.org/publications/loginonline/transcending...
> Additionally, bare bones Linux kernel infrastructure for Xen and KVM support isn't UNIX.
> "Transcending POSIX: The End of an Era?"
Xen and KVM aren't equivalent here.
KVM is ultimately an interface involving file descriptors, mmap(2), read(2), write(2), etc. IMO while not being UNIX™ it still very much embodies the UNIX spirit.
Deno supports typescript out of the box. This alone greatly simplifies any deployment, and even if Deno did not offered anything else it would already take the lead in developer experience.
People will make sure to distribute their library so that it works on all of them. They might even use `deno compile` to bundle the library into a single file that can be consumed from any of the runtimes.
Long shot though.
I expect deno to convert all of their features to node modules and simply be an opinionated stack, similar to create-react-app vs. next.js. The path they're entertaining now isn't really tenable.