Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind.
Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.
This meme has to die. It hasn't been true for longer than it was ever true. Yes, we all know Brendan Rich "designed JavaScript in a week" in 1995, but that initial design was A) actually quite elegant for its goals, and B) has really only been an historical curiosity since the ECMAScript standardization process started in 2005. There are people who were born, grew up, learned JS, and have solid careers working in it since that time.
The ECMAScript we have today, and the Typescript extensions of it, is one of the most robust, best performing, intentionally designed dynamic scripting languages on the market. It helps that every major tech corporation in the world has gobs of the stuff bearing loads somewhere in their organizations; they invest massively in making sure it's pretty good.
Before any pedant comes in to post the "Wat" talk, no, JavaScript is not a perfect language. While I personally prefer strictly typed JIT language to it, I still write a lot of it, might even be most of what I write. JavaScript today is as good of a design of a dynamic scripting language as you will find.
even with blocking lifecycle scripts, the attacker could have planted it somewhere else or just trick the dev somehow to run it
Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.
if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness...
I should check actual perf numbers... well next week or month?
- Deno plugin in editor, otherwise types dont work
- All imports via absolute URL, like Golang
- No backwards compatibility, so no existing code worked.
Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.
Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).
tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects