[zmxz]

> then it's gonna leave a bad impression

My company's frontend team (comprised mostly of people who believe anything written) jumped the wagon on Bun.

After a few days of working with it, it turned out that Bun isn't really faster in real world scenarios.

This brings up the question - why market it as so much faster then?

Many frameworks and tools market themselves primarily as faster than $otherThing but it won't fix suboptimal code, wrong choices for data structures, silly things like "let's select * and sort in browser". When you remove those mistakes that bad devs make, it turns out node/deno are more than fast enough. What we need is less bloat, more engineering and no lazy development by "packagemanager install lib-that-could-do-my-work"

[gcau]

>This brings up the question - why market it as so much faster then?

Speed is somewhat the main selling point. It loses in most other metrics to node or deno. I think speed is a dumb thing to have as a main selling point too; nodejs/v8 are already quite fast, if I needed more speed I'd try to optimise it, before then rewriting it to rust. I want stability, soundness, features, a good toolchain etc.

[Jarred]

> After a few days of working with it, it turned out that Bun isn't really faster in real world scenarios.

Which scenarios? Are you sure it was using Bun and not Node? Is it using bun’s tools for things or the same tools as it did in node?

[robertjpayne]

What parts of Bun were you using? All the features I've used (that work*) are faster, the hard part is the compatibility is still lacking so turning on the Bun runtime over just using Node is tricky.

[sgarland]

> What we need is less bloat, more engineering and no lazy development by "packagemanager install lib-that-could-do-my-work"

Millions of voices suddenly cried out in terror, and were suddenly silenced.