4 ms·

I work on Bun Fastify is not fast in Bun. Bun.serve() is 3x - 4x faster. Our node:http code currently just wraps Bun.serve(). node:http has to go through many

by Jarred 3y ago

I work on Bun Fastify is not fast in Bun. Bun.serve() is 3x - 4x faster. Our node:http code currently just wraps Bun.serve(). node:http has to go through many extra string -> buffer conversions and microticks and does a lot of unnecessary work. We have a branch that makes about 2x faster, but we need to prioritize our 1700+ open issues over performance optimizations right now.

littlestymaar 3y ago
> We have a branch that makes about 2x faster, but we need to prioritize our 1700+ open issues over performance optimizations right now. Maybe “has incredibly high performance” should not be the first selling point in your marketing pitch then.
- 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?
tarruda 3y ago
> We have a branch that makes about 2x faster, but we need to prioritize our 1700+ open issues over performance optimizations right now. Recently I have even tried to port onde of my nextjs projects to it, but to my surprise it does not work on Linux ARM64 due to a broken syscall. To me, the biggest selling point of Bun is not the runtime performance, but the fact that it can replace all tools for installing packages and bundling apps. (No need for a node modules for with hundreds of packages for a simple hello world web app) Runtime performance is not that important for JS servers, considering that most of the applications are just http glue code to a database server. (Maybe it is just me, but I would never use JS to write performance critical code). So focusing on making things stable would be a really good move right now. In any case I'm super enthusiastic about Bun and it has a lot of potential. I hope you can make it work!

by Jarred 3y ago

littlestymaar 3y ago

> We have a branch that makes about 2x faster, but we need to prioritize our 1700+ open issues over performance optimizations right now. Maybe “has incredibly high performance” should not be the first selling point in your marketing pitch then.

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?

tarruda 3y ago

> We have a branch that makes about 2x faster, but we need to prioritize our 1700+ open issues over performance optimizations right now. Recently I have even tried to port onde of my nextjs projects to it, but to my surprise it does not work on Linux ARM64 due to a broken syscall. To me, the biggest selling point of Bun is not the runtime performance, but the fact that it can replace all tools for installing packages and bundling apps. (No need for a node modules for with hundreds of packages for a simple hello world web app) Runtime performance is not that important for JS servers, considering that most of the applications are just http glue code to a database server. (Maybe it is just me, but I would never use JS to write performance critical code). So focusing on making things stable would be a really good move right now. In any case I'm super enthusiastic about Bun and it has a lot of potential. I hope you can make it work!