3 ms·

> 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

by zmxz 3y ago

> 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"

robertjpayne 3y ago
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.
gcau 3y ago
>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.
sgarland 3y ago
> 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.
Jarred 3y ago
> 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?

by zmxz 3y ago

robertjpayne 3y ago

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.

gcau 3y ago

>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.

sgarland 3y ago

> 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.

Jarred 3y ago

> 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?