6 ms·

Anybody care to explain on how it achieve such numbers in comparison to node and deno? Why would anybody not use Bun, other than the cost of migration, given t

Anybody care to explain on how it achieve such numbers in comparison to node and deno? Why would anybody not use Bun, other than the cost of migration, given the performance improvement? Nevertheless, amazing performance. Feels refreshing to see more improvements to the JS/TS community.

EGreg 4y ago
I would ask the other way ... why use Bun if the other products are mature and good enough? I've seen Node forked (to Deno I think) and then eventually they merged it back.
- klohto 4y ago
  Node forked to Deno? And merged... back? What are you talking about?
- zdragnar 4y ago
  You might be thinking of io.js, which was a fork almost entirely due to politics. The advisory board came out of it, and a push for semver, but it started here: https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482dcc8d1c41c14333fcb48 https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482d...
- ramesh31 4y ago
  >I've seen Node forked (to Deno I think) and then eventually they merged it back. You're thinking of the io.js debacle
kamikaz1k 4y ago
Jarred is approaching this from a fundamentally performance (due to targeting of Edge runtime) and DX perspective. If you follow his twitter or bun discord, you can see he spends an enormous amount of time studying, profiling, and tweaking features so he can squeeze as much performance out of it as he can. Reasons not to use bun: - it is pre v1, so unstable API - it is unstable, so you will deal with crashes - newer, so help articles will be hard to find
culi 4y ago
I think the main difference is that while Node and Deno embed Chrome's V8 engine, Bun embed's Apple's JavaScriptCore. Bun also uses "a new JavaScript parser based on esbuild’s JavaScript parser but ported to Zig" However, it's worth noting that those benchmarks have been critized a lot for being cherry-picked and not very representative of real-world use-cases I've tried to look it up a number of times but I've yet to come across any benchmarks done by an independent party (please share if you find some)
- franciscop 4y ago
  It's worth noting that the main people I've seen complaining about those benchmarks were people working on Deno or Node :)
  - fennecfoxy 4y ago
    I'd complain about them and I don't work on either of those projects. But I have worked _with_ node for a very long time, and I am intensely familiar with the JS ecosystem's "flavour of the day" culture. I think people are rightfully suspicious of such bold claims. Particularly as Deno came out to much fanfare and self promotion but like...I barely hear of anyone actually using it in production as opposed to node. Not saying that node will be King forever, just that I'm taking a grain of salt.
  - culi 4y ago
    This is mostly true but I've also yet to see any independent party try to benchmark the runtimes
    - franciscop 4y ago
      Agreed! Just noting that there's conflict of interests all around the place, not just on one side. What seems clear though is that Bun/Jarred really care about performance, since it's a big part of the tweeting/public communication. Maybe the tests are not the best from a real-world comparison, but the fact that he's constantly trying to make every small thing high performance would suggest that performance IS important for Bun. So people might disagree on "how much better", but I'd not be surprised at all if a system built from the ground up with a big focus on performance is faster than the competition.
Jarred 4y ago
We spend an absurd amount of time profiling, benchmarking, and making stuff run fast in Bun Most of Bun is written in native code (zig) rather than JavaScript. We leverage modern CPU features like SIMD, closely watch syscall overhead and spend a lot of time reading about system calls and platform-specific system APIs Bun is still pretty early - we are not at 1.0 yet. There are crashes and many bugs to fix, but we are making steady progress towards a stable release

EGreg 4y ago

I would ask the other way ... why use Bun if the other products are mature and good enough? I've seen Node forked (to Deno I think) and then eventually they merged it back.

klohto 4y ago
Node forked to Deno? And merged... back? What are you talking about?
zdragnar 4y ago
You might be thinking of io.js, which was a fork almost entirely due to politics. The advisory board came out of it, and a push for semver, but it started here: https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482dcc8d1c41c14333fcb48 https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482d...
ramesh31 4y ago
>I've seen Node forked (to Deno I think) and then eventually they merged it back. You're thinking of the io.js debacle

kamikaz1k 4y ago

Jarred is approaching this from a fundamentally performance (due to targeting of Edge runtime) and DX perspective. If you follow his twitter or bun discord, you can see he spends an enormous amount of time studying, profiling, and tweaking features so he can squeeze as much performance out of it as he can. Reasons not to use bun: - it is pre v1, so unstable API - it is unstable, so you will deal with crashes - newer, so help articles will be hard to find

culi 4y ago

I think the main difference is that while Node and Deno embed Chrome's V8 engine, Bun embed's Apple's JavaScriptCore. Bun also uses "a new JavaScript parser based on esbuild’s JavaScript parser but ported to Zig" However, it's worth noting that those benchmarks have been critized a lot for being cherry-picked and not very representative of real-world use-cases I've tried to look it up a number of times but I've yet to come across any benchmarks done by an independent party (please share if you find some)

franciscop 4y ago
It's worth noting that the main people I've seen complaining about those benchmarks were people working on Deno or Node :)
- fennecfoxy 4y ago
  I'd complain about them and I don't work on either of those projects. But I have worked _with_ node for a very long time, and I am intensely familiar with the JS ecosystem's "flavour of the day" culture. I think people are rightfully suspicious of such bold claims. Particularly as Deno came out to much fanfare and self promotion but like...I barely hear of anyone actually using it in production as opposed to node. Not saying that node will be King forever, just that I'm taking a grain of salt.
- culi 4y ago
  This is mostly true but I've also yet to see any independent party try to benchmark the runtimes
  - franciscop 4y ago
    Agreed! Just noting that there's conflict of interests all around the place, not just on one side. What seems clear though is that Bun/Jarred really care about performance, since it's a big part of the tweeting/public communication. Maybe the tests are not the best from a real-world comparison, but the fact that he's constantly trying to make every small thing high performance would suggest that performance IS important for Bun. So people might disagree on "how much better", but I'd not be surprised at all if a system built from the ground up with a big focus on performance is faster than the competition.

Jarred 4y ago

We spend an absurd amount of time profiling, benchmarking, and making stuff run fast in Bun Most of Bun is written in native code (zig) rather than JavaScript. We leverage modern CPU features like SIMD, closely watch syscall overhead and spend a lot of time reading about system calls and platform-specific system APIs Bun is still pretty early - we are not at 1.0 yet. There are crashes and many bugs to fix, but we are making steady progress towards a stable release