I'm working on switching webstreams to Node.js streams in Next.js which removes most of the overhead and increases RPS by a lot. Webstreams have a lot of overhead, the only reason we used them is to support edge runtime as well. Splitting implementations now.
It's clear that most people don't understand the numbers in the table and it leads to making wrong conclusions and having wrong assumptions which is quite unfortunate.
I gave that feedback to Matteo yesterday 🙂
Because the benchmark is set to run over 1K RPS regardless requests start failing the "average latency" goes up, it does not mean rendering takes that amount of time.
It renders in similar time in the benchmark app across the different frameworks. None is "2x faster". It's all React rendering.
Seems you're misunderstanding this table. It's worth reading the related blogpost end-to-end.
The only takeaway is:
- Next.js does 700RPS
- If you do more than 700RPS the benchmark app can't handle more right now, so requests start failing. Thus timing out.
Replied here: x.com/timneutkens/...
No. It works by default, the default is using Turbopack. You explicitly opted into webpack in your application 🙂
It's using webpack which has different limitations 🙂
By default Next.js uses Turbopack. webpack is opt-in only for backwards compat
Please correct the record / delete the incorrect information 🙂
Proof that the icon import you showed works as-is: 8rrzh7-3000.csb.app
Sandbox: codesandbox.io/p/devbox/8rr...
And screenshot:
This is not true. You can import .css files anywhere in Next.js with App Router.
The Tailwind loader works in Turbopack 😄 That's what I created it for in the first place.
The image will be used to create a false narrative, and you now know the image is incorrect. Best thing you can do at this point is fix the mistake instead of letting it get out there.
I'd recommend deleting and starting over with a new thread without results, it only has 12 likes so far. Enough room to correct the record at this point.
Otherwise you'll be undermining your own work / credibility of the work, which is the opposite of what you want.
Happy to join.
If the first interaction with framework authors is spreading charts that are wrong you're not setting yourself up for success here. Hurts your credibility a lot.
We already have to deal with enough misinformation being posted.
I'm expecting the original post will be deleted? Now that you know it's inaccurately showing frameworks performance.
It's very disappointing that you end up sharing numbers you know are not final yet. They will be misused to create a false narrative.
Before working on anything else I'd highly recommend first making sure that the results are actually correct, because the current setup is not as evidenced by my PR. Check with framework authors first.
Hey Alexander,
The comparison is not doing the same work and added additional overhead in the Next.js implementation.
I'm disappointed you did not reach out to verify these before just sharing such results on social media. You know full well people will misuse these.
PR: github.com/e18e/framewo...
Following up here
Why?
Next.js 16
• Cache Components
• Turbopack enabled by default
• Turbopack file system caching (beta)
• Optimized navigations and prefetching
• Improved caching APIs
• Build Adapters API (alpha)
• React 19.2
nextjs.org/blog/next-16
There hasn’t been many new bundlers 😄 proving that it works at the scale of large Next.js applications is important to us 👍
What packages are you using?
Because we decided to focus on Next.js applications first. There will be a more generic API to use the bundler in the future.
Maybe there is a lockfile at multiple levels in the monorepo incorrectly, which makes automatic root detection detect the application directory as the root.
More info in these docs: nextjs.org/docs/app/api...
Thank you!
Saying "be honest" claims I'm lying. I'm not lying.
Everything you're bringing up so far is stuff outside of our control that we're somehow getting blamed for by you "Not using Unjs" "Not using Vite" "The React docs".
We maybe made decisions you personally don't like, that's different than evil.
We have no control over what the React team at Meta recommends in their documentation. There is no conspiracy.
It's really weird for you to claim that because we did not contribute to one project (i.e. unjs) we're somehow "hostile"? We contribute to many other projects that help everyone.
We live in a time where I couldn’t be happier about web tooling. A time of optimizing what came before, and everyone building for the web wins. We want the web to win. That includes people building with Nuxt / Nitro / Vite.
Somehow people assume that because we don’t use Vite in Next.js that we believe it’s bad. This is just not the case. It’s a good tool, it just wasn’t the tool for us to build Next.js. We had different requirements. It’s good for other things.