3 ms·

Bun is a cool project but probably less than 1% of web apps actually need more perf than Node can provide. A Fastify server app can easily serve thousands of r

by pier25 4y ago

Bun is a cool project but probably less than 1% of web apps actually need more perf than Node can provide. A Fastify server app can easily serve thousands of reqs/s. https://www.fastify.io/benchmarks/ https://www.fastify.io/benchmarks/ The whole StackExchange network serves on average 50 page views per second. https://stackexchange.com/performance https://stackexchange.com/performance

deleted 4y ago
[deleted]
jdxcode 4y ago
I bet nearly 100% of web apps would benefit from increased performance in npm install, typescript and webpack compilation
- cassepipe 4y ago
  For npm install it seems it is a solved problem: just use pnpm as a drop in replacement. It's such a basic idea : instead of reinstalling dependancies in each repo, just hard link them from a common store and there you go, you just reuse them. Simple yet brilliant.
  - jdxcode 4y ago
    That doesn't help CI performance. I bet `bun install` is way faster than `pnpm install` on a cold or hot cache (though I haven't tested myself). I think it does similar things to pnpm under the hood to improve local development speed as well. EDIT: just tested on the eslint codebase: cold (nothing installed, no cache): bun: 1.53s, pnpm: 8.25s, npm: 25s hot (already installed, noop): bun: 218ms, pnpm: 1300ms, npm: 1230ms
- pier25 4y ago
  If performance is critical IMO it would make a lot more sense to switch to Rust or Go than Bun. Instead of getting a 2-3x improvement (best case scenario) you will get more like 10-20x. Webpack 5 is probably the last version. Not my words, but from its main author. Vite is the new de facto bundler which uses EsBuild (written in Go).
  - jdxcode 4y ago
    I don't think you understand the point of bun. It's not to make npm/webpack/typescript faster at running JS code, it's to replace those tools entirely. So in essence, it's doing the same thing that esbuild is doing, just across all of the major tasks people currently do with node. What's different about bun vs esbuild is that it's one tool you can use for everything you do in JS projects. I've swapped much of my usage of npm over to bun. I still work on projects where nobody else is using bun, but I can run `bun install` instead of `npm install` and `bun run` instead of `npm run` and these run probably 100x faster.
    - pier25 4y ago
      > So in essence, it's doing the same thing that esbuild is doing, just across all of the major tasks people currently do with node. Except that Bun is not going to be able to do what esbuild is doing because Go and other languages are in another league regarding perf.
      - pfg_ 4y ago
        bun is already faster than esbuild? i don't understand this comment. the bun transpiler is basically a direct port of esbuild to zig. esbuild is a javascript transpiler. it transpiles typescript into javascript that v8 or another js engine can run. it's written in go which is the main reason it's faster than pure js transpilers like babel. were you thinking that esbuild is for go code? i'm confused bun is a combined javascript transpiler & runtime & test runner & package manager. it improves performance of many things: - startup time including transpiling code and resolving modules and initializing the javascript vm - installing packages - running tests it can also improve runtime performance (it is faster at basically every bit of the node api it covers & it has its own versions of some things like http servers that can have better performance than the node APIs) switching your project to rust would improve runtime performance, but would make it slower to run tests & compile the project & use an ide language server & … i haven't used go but i've heard it's fast to compile & has better runtime performance than js
      - jdxcode 4y ago
RedShift1 4y ago
Faster is always better. Given the same hardware, faster requests, faster CI pipelines, etc... = lower power usage. Scale this up to the planet and the power savings could be substantial.
- pier25 4y ago
  I 100% agree. Precisely why another solution is needed. Bun is not fast enough.
namuol 4y ago
You’re right. The first paragraph of the article acknowledges that these kinds of throughout benchmarks don’t matter, and the author focuses on the CI/CD time savings you get with tooling like Bun, which can be substantial.
yonifei 4y ago
Besides the other use cases that benefit others have mentioned, there's much more to perf than req/s for a webserver. Basic examples: - Latency/processing (which suffers as req/s grows or peaks) - Memory usage (idle, at peak) - Startup time (one-off jobs, serverless cold boot) The "thousands of req/s" benchmarks are often unrealistic - either super simple (the benchmark you linked serves a static tiny JSON payload) or hyper optimized and not representing a run-of-the-mill webserver.
- pier25 4y ago
  > The "thousands of req/s" benchmarks are often unrealistic A hello world Fastify project can get you into the 20k reqs per second. On the same hardware with a real project you probably will get a couple thousands which is more than enough to satisfy 99% of projects.

by pier25 4y ago

deleted 4y ago

[deleted]

jdxcode 4y ago

I bet nearly 100% of web apps would benefit from increased performance in npm install, typescript and webpack compilation

cassepipe 4y ago
For npm install it seems it is a solved problem: just use pnpm as a drop in replacement. It's such a basic idea : instead of reinstalling dependancies in each repo, just hard link them from a common store and there you go, you just reuse them. Simple yet brilliant.
- jdxcode 4y ago
  That doesn't help CI performance. I bet `bun install` is way faster than `pnpm install` on a cold or hot cache (though I haven't tested myself). I think it does similar things to pnpm under the hood to improve local development speed as well. EDIT: just tested on the eslint codebase: cold (nothing installed, no cache): bun: 1.53s, pnpm: 8.25s, npm: 25s hot (already installed, noop): bun: 218ms, pnpm: 1300ms, npm: 1230ms
pier25 4y ago
If performance is critical IMO it would make a lot more sense to switch to Rust or Go than Bun. Instead of getting a 2-3x improvement (best case scenario) you will get more like 10-20x. Webpack 5 is probably the last version. Not my words, but from its main author. Vite is the new de facto bundler which uses EsBuild (written in Go).
- jdxcode 4y ago
  I don't think you understand the point of bun. It's not to make npm/webpack/typescript faster at running JS code, it's to replace those tools entirely. So in essence, it's doing the same thing that esbuild is doing, just across all of the major tasks people currently do with node. What's different about bun vs esbuild is that it's one tool you can use for everything you do in JS projects. I've swapped much of my usage of npm over to bun. I still work on projects where nobody else is using bun, but I can run `bun install` instead of `npm install` and `bun run` instead of `npm run` and these run probably 100x faster.
  - pier25 4y ago
    > So in essence, it's doing the same thing that esbuild is doing, just across all of the major tasks people currently do with node. Except that Bun is not going to be able to do what esbuild is doing because Go and other languages are in another league regarding perf.
    - pfg_ 4y ago
      bun is already faster than esbuild? i don't understand this comment. the bun transpiler is basically a direct port of esbuild to zig. esbuild is a javascript transpiler. it transpiles typescript into javascript that v8 or another js engine can run. it's written in go which is the main reason it's faster than pure js transpilers like babel. were you thinking that esbuild is for go code? i'm confused bun is a combined javascript transpiler & runtime & test runner & package manager. it improves performance of many things: - startup time including transpiling code and resolving modules and initializing the javascript vm - installing packages - running tests it can also improve runtime performance (it is faster at basically every bit of the node api it covers & it has its own versions of some things like http servers that can have better performance than the node APIs) switching your project to rust would improve runtime performance, but would make it slower to run tests & compile the project & use an ide language server & … i haven't used go but i've heard it's fast to compile & has better runtime performance than js
    - jdxcode 4y ago

RedShift1 4y ago

Faster is always better. Given the same hardware, faster requests, faster CI pipelines, etc... = lower power usage. Scale this up to the planet and the power savings could be substantial.

pier25 4y ago
I 100% agree. Precisely why another solution is needed. Bun is not fast enough.

namuol 4y ago

You’re right. The first paragraph of the article acknowledges that these kinds of throughout benchmarks don’t matter, and the author focuses on the CI/CD time savings you get with tooling like Bun, which can be substantial.

yonifei 4y ago

Besides the other use cases that benefit others have mentioned, there's much more to perf than req/s for a webserver. Basic examples: - Latency/processing (which suffers as req/s grows or peaks) - Memory usage (idle, at peak) - Startup time (one-off jobs, serverless cold boot) The "thousands of req/s" benchmarks are often unrealistic - either super simple (the benchmark you linked serves a static tiny JSON payload) or hyper optimized and not representing a run-of-the-mill webserver.

pier25 4y ago
> The "thousands of req/s" benchmarks are often unrealistic A hello world Fastify project can get you into the 20k reqs per second. On the same hardware with a real project you probably will get a couple thousands which is more than enough to satisfy 99% of projects.