A Fastify server app can easily serve thousands of reqs/s.
https://www.fastify.io/benchmarks/
The whole StackExchange network serves on average 50 page views per second.
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).
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.
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.
That said, it was a tiny and simple test set[1]. It may not be ready yet for more complex tests, as the docs warn[2]:
> You've never seen a JavaScript test runner this fast (or incomplete).
[1] https://github.com/drifting-in-space/driftdb/blob/main/js-pk...
[2] https://bun.sh/
Or is there something else going on?
bun:test is fast mostly because it’s integrated deeply into the runtime. Other test runners typically have to mutate globals and spend a lot of time setting up the environment and tearing it down. Also, expect() in bun:test is something like 10x faster[1] than in vitest (100x jest) because it’s written in native code.
Test runners involve a lot of polymorphism which means JS doesn’t get JIT’d much — in cases like that, writing in native is much faster.
Another factor is transpilation time. bun:test supports TypeScript and JSX without plugins and bun’s transpiler is very fast
[1]: https://twitter.com/jarredsumner/status/1595681235606585346?...
1. JSC rather than V8
2. Built in APIs. A lot of nodes APIs are implemented in JS and for this reason (or simply because they’re not well optimised), they run more slowly than Bun’s implementation.
3. Bun also has a highly optimised built in test runner
JSC vs V8 is interesting... I'd like to see something like tsc compile times for real projects compared. And then again against something like SWC (rust impl) :) I doubt we'll switch to bun any time soon for prod runtime, but for speeding up tsc/lint/babel/etc, sure!
bun, deno, esbuild, swc etc. can parse the syntax, but they chuck the TS (they probably don't even add it to the AST, but I haven't checked).
Keeping up with syntax is very doable. It doesn't change often, and updating the parser when it does isn't much work.
There are some past/ongoing projects[1][2] to create type checkers faster than tsc, but they aren't going to reach full parity and probably don't plan on keeping up with language features.
Heads up for the author: the dark theme seems to be handling the tables incorrectly (keeping the tables light but inverting the text to become nearly white).
When it comes to demo and bun then i suggest focusing on deno until bun hits stable release. It's still rough around the edges.
There are few areas of software where people will obstruct efforts before and support them after quite as much as CI. The biggest is probably software process maturity, where people have to see a scary production issue evaporate into the run book before they “get it”. Build pipeline maturity is solidly in third place, sometimes second.
