3 ms·

They just released 1.0 with massive speed increases over node in many scenarios and still have to fix compatibility issues (like the lack of dgram). Let them pr

by rcarmo 3y ago

They just released 1.0 with massive speed increases over node in many scenarios and still have to fix compatibility issues (like the lack of dgram). Let them prioritise coverage.

littlestymaar 3y ago
I mean, they do what they want but if they market themselves as much faster than nodejs and when people are trying it, it's no really faster (and it's not the first time I see such a benchmark), then it's gonna leave a bad impression. Why bother with all the instability that comes from the project's young age[1] if the project fails to deliver on its biggest selling point? [1] and I'm not blaming them for that, their goal of being node compliant is a big undertaking
- 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 rcarmo 3y ago

They just released 1.0 with massive speed increases over node in many scenarios and still have to fix compatibility issues (like the lack of dgram). Let them prioritise coverage.

littlestymaar 3y ago

I mean, they do what they want but if they market themselves as much faster than nodejs and when people are trying it, it's no really faster (and it's not the first time I see such a benchmark), then it's gonna leave a bad impression. Why bother with all the instability that comes from the project's young age[1] if the project fails to deliver on its biggest selling point? [1] and I'm not blaming them for that, their goal of being node compliant is a big undertaking

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?