Hacker News new | ask | show | jobs
by redox99 1344 days ago
I disagree. If we're talking of microbenchmarks focused on 100k rps or whatever that are mostly IO/syscall limited, sure.

But if it's that JS execution is outright faster, it's a big deal.

People here handwave "oh, your business doesn't require more than 10rps". Sure. But rps is just half the story, latency is the other. I'll give you two examples

1) SSR with something like Material UI is slow, especially because of the CSS-in-JS. The server rendering the page can easily take 200ms or more.

2) Modern backend stacks. On an API I have I use Prisma + Apollo GraphQL. Some queries take 500ms. These same queries but using REST and knex are <10ms. There is no slow SQL queries here or N+1 issues, it's just prisma and graphql executing a lot of JS.

In either case, the user experience is impacted because the website becomes slower. And a faster runtime would make these JS run faster, thus the web/api load faster.

4 comments

You've given 2 of the worst (imo) regressions in frontend dev in the last decade.

If you're relying on innovation to make your existing tech stack not behave like dogshit when proven and trivial solutions exist, you're valuing the wrong things when choosing your stack.

They may be the worst, but they have now become extremely common to find in a variety of company projects. Not just FAANG or FAANG-adjacent but boring insurance or healthcare companies too.
Youre almost proving my point. This bechmark is focused on one tiny layer. It’s not executing complex graph queries. If you want to do a real comparison then the benchmark should be “apollo graph query performance on node vs deno vs bun” and then decide if its good enough to compare speed of feature delivery using knex. Even then the benchmark would need to be carefully crafted.
Hot take: If every layer of your stack focused on similarly useless performance improvements, the web would be a much better place.
You may be able to slash SSR from 200ms to 195ms by using a different JS runtime. Or you may slash it to 100ms by rewriting and optimizing code (caching and such). Resources are limited. You either do one or the other.
They are all V8 so will all be approximately the same speed of JS execution I imagine?
Bun uses javascript core.

There is also overhead in passing structures and other communication required so that layer can change the number as well.

They are not all V8