Vite 8 is pretty incredible. We saw around an 8x improvement (4m -> 30s) in our prod build, and it was nearly a drop-in replacement. Congrats (and thank you!) to the Vite team!
soulchild77 1 hours ago [-]
Awesome! Too bad Next.js will never profit from these incredible community efforts, because Vercel suffers from NIH.
gherkinnn 2 minutes ago [-]
It's the Vercel way to first run broken previews for several years.
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].
Got back in to react after a few years’ hiatus and I struggle to even understand what the point of Next is. Bizarrely the official docs even reference Next. Are people using react for non-SPA’s? Why?
gnarlbar 3 minutes ago [-]
Not me, but I can imagine it happening.
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.
codetantra 14 minutes ago [-]
After Tanstack Start, Next.js seems even less intuitive. While it remains a viable option due to its established momentum, it feels quite alien to backend devs, esp with its unconventional defaults.
CalRobert 9 minutes ago [-]
It feels like Wordpress inasmuch as it’s shoving a tool in places that don’t make sense. React is great for SPAs but if I wanted pre-rendered static content I’d use a different tool.
pjmlp 43 minutes ago [-]
They have the enterprise partners that make Next.js the only officially supported SDK on their SaaS integrations.
See Sitecore Cloud, Sanity, Contentful,....
rk06 21 minutes ago [-]
Really the enterprise partner supports next, but not vanilla js sounds stupid? Honestly I expect them to prioritize nextjs and react given the popularity, but still be open to vanilla js.
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?
pjmlp 18 minutes ago [-]
Vanilla JS is "supported" if you write the missing parts, e.g. layout service, visual editing integration,...
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.
It's not a good piece of software. Breaks in many places
nebezb 22 minutes ago [-]
> Built-in tsconfig paths support
A great QoL change. One less place to duplicate (and potentially mistake) a config.
brandensilva 2 hours ago [-]
Man the perf changes for this version are awesome. Thanks Vite.
steve_adams_86 19 minutes ago [-]
It cut my build/dev times by ~1/3 for a few projects. Deployments are meaningfully faster. It also plays perfectly with Deno projects which isn't totally shocking or anything, but I was expecting at least some friction somewhere. They did great work on this.
It looks like I'm at the lower end of their reported improvement range (like Mercedes-Benz.io at 38% improvement). Some of these are insane. "Linear: Production build times dropped from 46s to 6s" wow
verma_yatharth 57 minutes ago [-]
I tried it and I saw more than 6x improvement in speed.
It's on the top. Awesome tool 1
pjmlp 42 minutes ago [-]
Another rewrite in Rust.
What about finally stop using node.js for server side development?
vijaybritto 27 minutes ago [-]
This is for tooling.
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
pjmlp 19 minutes ago [-]
Why go halfway, embrace compiled languages in the backend.
Fast all the way down, especially when coupled with REPL tooling.
slopinthebag 3 hours ago [-]
> Currently, the Oxc transformer does not support lowering native decorators as we are waiting for the specification to progress
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.
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.
Awesome. Standard decorators support is not a dealbreaker for me, but enums and other types of non-erasable syntax would be.
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.
pkilgore 2 hours ago [-]
Congratulations!
hackernewsman71 1 hours ago [-]
holy shit - Vite 8 - rhymes in french! Did they mention that somewhere?
Rendered at 07:45:31 GMT+0000 (Coordinated Universal Time) with Vercel.
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
4 - https://nextjs.org/blog/CVE-2025-66478
5 - https://opennext.js.org/
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.
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)
A great QoL change. One less place to duplicate (and potentially mistake) a config.
It looks like I'm at the lower end of their reported improvement range (like Mercedes-Benz.io at 38% improvement). Some of these are insane. "Linear: Production build times dropped from 46s to 6s" wow
What about finally stop using node.js for server side development?
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.
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.