Not meant as a gotcha but I'm surprised because people always tout it as being so much faster than Next. (4m with Turbo would have to be a crazy huge app IME)
Next started with Turbopack alpha as a Webpack alternative in Next 13 (October 2022) and finally marked Turbopack as stable and default in Next 16 (October 2025). They also ran sketchy benchmarks against Vite back in 2022 [0].
Next's caching has a terrible history [1], it is demonstrably slow [2] (HN discussion [3]), RSCs had glaring security holes [4], the app router continues to confuse and relied on preview tech for years, and hosting Next outside of Vercel requires a special adapter [5].
Choosing Next.js is a liability.
0 - https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...
1 - https://nextjs.org/blog/our-journey-with-caching
2 - https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...
3 - https://news.ycombinator.com/item?id=43277148
There are several much better options right now. My favourite is Tanstack Start. No magice, great DX
5 or so years ago, Next was a pretty solid option to quickly build up a non SPA, when combined with the static export function. It wasn't ideal, but it worked and came batteries included. Over time it's become more bloated, more complicated, and focused on features that benefit from Vercel's hosting – and static builds can't take advantage of them.
These newer features seem of limited benefit, to me, for even SPAs. Why is there still not a first class way of referencing API routes in the client code that provides typing? Once you reach even medium scale, it becomes a mess of inteprolated string paths and manually added shared response types.
JSX is a nice server side templating language. There a lot of people who aren't dependency conscious, and a lot of people who love react, and there is quite a bit of overlap in those two groups. I've used bun + preact_render_to_string for server side JSX templates before and it was nice. When I did it seemed that bun somewhat embraced react, and I could imagine react being the path of least resistance to server-side JSX there for some of the folks in the aforementioned groups.
And to sell Vercel on top.
See Sitecore Cloud, Sanity, Contentful,....
I checked sitecore cloud to have special integration for nextjs and reactjs. But it also support vanilla js as well.
Are there really anyone who is exclusive to nextjs?
In many places they will say it is supported, but when you look into the details only React/Next.js work out of the box without additional work.
A bit like you can deploy Next.js on Vercel, or do it yourself somewhere else.
(haven't tried it myself)
I wonder how much of the Rollup bundling magic has been ported to Rolldown.
One thing that always made this kind of switch to Rust has always been that Rollup has become so sophisticated that's hard to replace with something new.
A great QoL change. One less place to duplicate (and potentially mistake) a config.
I still don't understand how people used to think scripts like this are the proper way to bundle an app.
https://github.com/facebook/create-react-app/blob/main/packa...
vite is great, is all I am saying
Does Oxc also support TS runtime features like constructor parameter properties and enums? I seem to recall in the beta that they had enabled --erasableSyntaxOnly, presumably because Rolldown / Oxc didn't support doing a full transform.
For that matter, TypeScript's version of decorators ("experimental decorators") also works: https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint...
What's not supported is the current draft proposal for standardized ECMAScript decorators; if you uncheck experimentalDecorators, the decorator syntax is simply passed through as-is, even when lowering to ES2015.
Do you know what the status is on using Rolldown as a crate for rust usage? At the moment most rust projects use SWC but afaik its bundler is depreciated. I usually just call into Deno for builds but would be nice to have it all purely in Rust.
What about finally stop using node.js for server side development?
In fact it still does, I only use node when forced to do so by project delivery where "backend" implies something like Next.js full stack, or React apps running on iframes from SaaS products.
It just shows that people don’t value the actual performance of what they’re running.
Node.js has been extraordinarily useful for building build tools. We're outgrowing it's capacity and rightfully moving to a compiled language. Also faster tooling is essential for establishing a high quality feedback loop for AI agents
Fast all the way down, especially when coupled with REPL tooling.
Also, writing JavaScript for the backend is needlessly underperforming for anything with any load.
Node dependencies are fine, add an npmrc file to have it default to exact versioning and you solve 90% of common day to day problems. It's not ideal, but nor is cargo's mystery meat approach to importing optional features from packages.
Maybe leave JavaScript on the browser, where it belongs.