Hacker News new | ask | show | jobs
by tombl 329 days ago
It's funny, I would actually argue the opposite point. When Deno and Bun first came out, they promised a hard break from the Node ecosystem, like how Deno leaned heavily into browser compatibility, and Bun into framework features like Bun.App.

At some point they both decided that Node compatibility was more important than their unique features, but in the time since their release Node got type stripping, require(esm), sqlite, single executable apps, a permission system, a test runner, and basically ever other Deno/Bun feature they could port over.

So at this point why use runtimes that imitate Node when you could just use Node? You'll get most of the modern niceties, but also get 100% compatibility with the existing ecosystem.

2 comments

> When Deno and Bun first came out, they promised a hard break from the Node ecosystem

I don't think that's true for Bun. In fact Bun was planned to NOT break from Node ecosystem as much as possible:

"Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more." - 2022

https://archive.is/lWjNn#selection-399.0-403.55

It sounds like Bun and Deno might have been a huge success! Could have had the effect of lighting a fire under node to innovate