Hacker News

> Can someone explain why it sounds like there's such rapid growth of Bun?

In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.

Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.

A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).

So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.

I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.

Edit: And Deno is now more compatible with node than bun.

I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works. Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.

Same, I'm mostly a back end dev but when I dip my toes into frontend for personal projects Deno just seems like the most sane choice. It's really nice to work with. I'm kind of sad it doesn't seem to have taken off among the JS folks.

Deno is from scratch attempting to pass as many NodeJS tests as possible. Bun piggybacks off the WebkitJS library iirc and shims anything nodejs specific it needs.

I can tell you my experience as a js package dev, last tried a few weeks ago. We're building an npm package that's supposed to run on both node.js, deno & bun & the web.

This is an annoying to do for exactly two platforms: node.js, and deno.

node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works!

Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error.

Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated.

Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports.

So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that!

I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.

I used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite.

So, I switched to Bun and things have been much smoother!

because for most people they don't need what deno promises.

me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).

bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.

too bad it is a failed promise now.

I think the main issue was when deno first came out it used urls for imports then later added support for npm.

By then bun was already a thing and just ate into its share.

I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines.

(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)

When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that.

But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.

They did lay off ~half the company ~2 months ago: https://news.ycombinator.com/item?id=47467746

It's good to have some options, to prevent the ecosystem from stalling

> Plus, bought by Anthropic.

Who thinks this is a positive?!

You can already ship single executables, my product's CLI is a Node single executable application

> and, soon enough, you'll be able to build your app to a single executable -- including native deps.

Whoa, did not know that. That's a killer feature!

Yeah, that's my immediate debate in reading this blog post: `deno pack` might be a great replacement to my existing `npm publish` workflow for my open source packages and continue shifting my work to Deno-first/Deno-mostly, but on the flipside, with Node's growing TS support I'm also considering switching to Typescript-only npm packages as a (tiny) message to the ecosystem.

Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.

It's surprising to me that bun is so much faster serving web requests. The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?

Similarly, it seems, though they didnt exactly say, that they're running bun with a warm package cache... What about the others? Do they have caches?

Likely because everybody would still strip types, bundle and minify their typescript code anyway.

My gripe is why doesn't Webassembly fully support dom manipulation. If we got that working anyone could just bring any language to the browser and we would finally be free from the shackles of JS.

Because standardization is a political process that takes time and consensus to achieve?

https://github.com/tc39/proposal-type-annotations

Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?

JS promise to never break the web. can't say the same about TS

There wouldn't be any benefit. It's not sound so it can't really be used to improve performance.

There was a proposal to support TypeScript syntax, but ignore the actual types (this is basically how Python works). That would be kind of nice because you can skip the compilation step completely (less faff for small projects), but I don't think it went anywhere... or if it is it's getting there at a snail's pace:

https://github.com/tc39/proposal-type-annotations

I actually lost interest in Deno once it started leaning into NPM. I thought it was a bold and wise idea to make a clean break from the mess of Node and restart with a sensible ecosystem. Absent that... I'm just sticking with Node.