People underestimate the node compatibility that Deno offers. I think the compat env variable will do a lot of adoption. Maybe a denon command or something could enable it automatically? Idk.
The deno compatibility with node has been a lie for me. I tried to port a simple project (100-200 LOC) to deno and it took me an hour which should have been 5-10 minutes. It didn't support some of node's methods and if it did, it was completely undocumented. Had to install basic functionality from some obscure URLS. Onxe it came to porting my test suite I just gave up. The problem was CJS -> ESM transition that was way more painful than I anticipated it to be. And definitely not as simple as deno's docs make it to be. Couldn't just port the whole library
I believe the reason Deno is not more widely used in production environments is the lack of a standardized vulnerability database (other than using 100% npm compatibility which will take many popular deno packages out of scope). The issue is that there is no real centralized package manager (by design) which makes it challenging.
Was there any development in that direction?
From a security standpoint it really icks me when projects prominently ask their users to do the `curl mywebsite.com/foo.sh | sh` thing. I know risk acceptance is different for many people, but if you download a file before executing it, at least you or your antivirus can check what it actually does.
As supply chain attacks are a significant security risks for a node/deno stack application, the `curl | sh` is a red flag that signals to me that the author of the website prefers convenience over security.
With a curl request directly executed, this can happen:
- the web server behind mywebsite.com/foo.sh provides malware for the first request from your IP, but when you request it again it will show a different, clean file without any code
- MITM attack gives you a different file than others receive
Node/deno applications using the npm ecosystem put a lot of blind trust into npm servers, which are hosted by microsoft, and therefore easily MITM'able by government agencies.
When looking at official docs for deno at https://docs.deno.com/runtime/getting_started/installation/ the second option behind `curl | sh` they're offering is the much more secure `npm install -g deno`. Here at least some file integrity checks and basic malware scanning are done by npm when downloading and installing the package.
Even though deno has excellent programmers working on the main project, the deno.land website might not always be as secure as the main codebase.
Just my two cents, I know it's a slippery slope in terms of security risk but I cannot say that `curl | sh` is good practice.
Nice list of solid changes. I really like Deno for scripting random glue code; I use it most places (maybe with the exception of random machine learning stuff, where python/uv fits.) Looking forward to gRPC support later this year, too, for some of my long-tail use cases. And the bundle command looks nice!
Really love the ideas behind Deno, and tried to do things the Deno way (Deno.json, JSR, modern imports, Deno Deploy) for a monorepo project with Next.js, Hono and private packages. Some things like Hono worked super well, but Next.js did not. Other things like types would sometimes break in subtle ways. The choice of deployment destination e.g. Vercel for Next also gave me issues.
In contrast, Bun had less cognitive overhead and just "worked" even though it didn't feel as clean as Deno. Some things aren't perfect with Bun either like the lack of a Bun runtime on Vercel
15 comments
[ 5.8 ms ] story [ 57.6 ms ] threadMy only concern is that they lose patience to their hype-driven competition and start doing hype-driven stuff themselves.
From a security standpoint it really icks me when projects prominently ask their users to do the `curl mywebsite.com/foo.sh | sh` thing. I know risk acceptance is different for many people, but if you download a file before executing it, at least you or your antivirus can check what it actually does.
As supply chain attacks are a significant security risks for a node/deno stack application, the `curl | sh` is a red flag that signals to me that the author of the website prefers convenience over security.
With a curl request directly executed, this can happen:
- the web server behind mywebsite.com/foo.sh provides malware for the first request from your IP, but when you request it again it will show a different, clean file without any code
- MITM attack gives you a different file than others receive
Node/deno applications using the npm ecosystem put a lot of blind trust into npm servers, which are hosted by microsoft, and therefore easily MITM'able by government agencies.
When looking at official docs for deno at https://docs.deno.com/runtime/getting_started/installation/ the second option behind `curl | sh` they're offering is the much more secure `npm install -g deno`. Here at least some file integrity checks and basic malware scanning are done by npm when downloading and installing the package.
Even though deno has excellent programmers working on the main project, the deno.land website might not always be as secure as the main codebase.
Just my two cents, I know it's a slippery slope in terms of security risk but I cannot say that `curl | sh` is good practice.
Here is an example of a small microcut I faced (which might be fixed now) https://github.com/honojs/hono/issues/1216
In contrast, Bun had less cognitive overhead and just "worked" even though it didn't feel as clean as Deno. Some things aren't perfect with Bun either like the lack of a Bun runtime on Vercel