Just upgraded to 8 with some version bumping. Dev server time reduced to 1.5s from 8s and build reduced to 35s from 2m30. Really really impressed.
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.
https://github.com/vitejs/vite/issues/21939
Build filesizes have doubled... No build speed gain is worth that...
I would take a slightly longer build time for half the filesize any day
Kudos to the Vite maintainers!
> Wasm SSR support: .wasm?init imports now work in SSR environments, expanding Vite's WebAssembly feature to server-side rendering.
While the process was relatively slow, I really appreciate the extra effort that the team have put on even this minor feature add. They not only guided me towards more compatible and idiomatic approach, but also added docs and helped keeping the code up to date before merging.
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
The PRC (aka server functions) demo [0] is particularly interesting — end-to-end type safety (from DB to UI) is a major milestone for JavaScript. We've been doing a lot of RPC design work in that space with Telefunc (tRPC alternative) [1] — it's a really hard topic, and we're looking forward to collaborating with the Void team. (Also looking forward to contributing as the creators of Vike [2].)
[0]: https://www.youtube.com/watch?v=BX0Xv73kXNk (around the end of the first talk) [1]: https://telefunc.com (see the last PR) [2]: https://vike.dev
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.
A great QoL change. One less place to duplicate (and potentially mistake) a config.
// See https://github.com/vitejs/vite/discussions/14652
esbuild: {
loader: "jsx",
include: /.*\.jsx?$/,
exclude: [],
},
optimizeDeps: {
esbuildOptions: {
loader: {
".js": "jsx",
},
},
},
Note the comment at the top. I had no idea how to come up with this config by checking the documentation pages of vite and its various related tools. Luckily I found the GitHub issue and someone else had come up with the right incantation.Now this new vite uses new tools, and their documentation is still lacking. I spent half an hour trying to figure out how vite (and related tools that I had to navigate and try to piece a coherent view of: esbuild, oxc, rolldown, etc.) might be convinced, but gave up and stayed with vite 7.
Someone could respond with a working solution and it would help, sure, but these tools sure as hell have documentation issues.
I feel the same way about tools like ESLint and Prettier as well after discovering Oxc https://oxc.rs/
I think it is the only tool in the JS ecosystem that has not broken after a few years.
Though sometimes oxc complains about JSX in JS when running vite, but it still works fine.
What about finally stop using node.js for server side development?
With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax. Apparently the Rust compiler isn't a speed daemon either. But tests are something that's under your control. Unit tests should be done in seconds/milliseconds. Integration tests are where you can make huge gains if you are a bit smart.
Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system.
The fix for this is 1) allow no cleanup between tests 2) randomize data so there are no test collisions between tests and 3) use multiple threads/processes to run your tests to 1 database that is provisioned before the tests and deleted after all tests.
I have a fast mac book pro that runs our hundreds of spring integration tests (proper end to end API tests with redis, db, elasticsearch and no fakes/stubs) in under 40 seconds. It kind of doubles as a robustness and performance test. It's fast enough that I have codex just trigger that on principle after every change it makes.
There's a bit more to it of course (e.g. polling rather than sleeping for assertions, using timeouts on things that are eventually happening, etc.). But once you have set this up once, you'll never want to deal with sequentially running integration tests again. Having to run those over and over again just sucks the joy out of life.
And with agentic coding tools having fast feedback loops is more critical than ever.
Luckily, we have invented a completely new nightmare in the form of trying to graft machine-usable interfaces on top of AI models that were specifically designed to be used by humans.
It just shows that people don’t value the actual performance of what they’re running.
Compare this to essentially any modern business app, the product being sold has very little relationship with CPU cycles, or the CPU cycles are SO cheap relative to what you're getting paid, no one cares to optimize.
Yea, cypress has this in their anti-patterns:
https://docs.cypress.io/app/core-concepts/best-practices#Usi...
Dangling state is useful for debugging when the test fails, you don't want to clean that up.
This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.
This is because the kotlin compiler is not written in the way people write fast compilers. It has almost no backend to speak of (if you are targeting the jvm), and yet it can be slower at compilation than gcc and clang when optimizing.
Modern fast compilers follow a sort of emerging pattern where AST nodes are identified by integers, and stored in a standard traversal order in a flat array. This makes extremely efficient use of cache when performing repeated operations on the AST. The Carbon, Zig, and Jai compiler frontends are all written this way. The kotlin compiler is written in a more object oriented and functional style that involves a lot more pointer chasing and far less data-dense structures.
Then, if run on a non-graal environment, you also have to pay for the interpreter and JIT warmup, which for short-lived tasks represents nontrivial overhead.
But unlike header inclusion or templates, which are language level features that have major effects on compilation time, I don't think kotlin the language is inherently slow to compile.
I like Vite as a tool, but knowing that the Vite folks actually care about helping others learn and contribute is awesome.
I used to maintain a build workflow library [1] a lifetime ago; while our frontend build needs have evolved way beyond it, I can't avoid the feeling that we overengineered a little too much.
{
// ...
"imports": {
"#assets/*": "./src/assets/*",
"#/*": "./src/*"
},
// ...
}
The second one (#/*) is similar enough to what I usually use (@/*), and it's supported in Node since v25.4.0! Yet when I try to import the file at projectRoot/src/router/index.ts using: import router from "#/router/index"
VS Code shows an error: "Cannot find module '#/router/index' or its corresponding type declarations."Now, imports from e.g. "#assets/main.css" work, so I could work around this issue - but this is what I keep experiencing: the native variant usually kinda works except for the most common use case, which is made unnecessarily awkward. For a long time this is what ESM used to feel like, and IMO it still does in places (e.g. directory imports not working is a shame).
Another instance is the use of rollupOptions.output.manualChunks that now has to be rewritten, maybe that would be less frustrating to fathom.
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
It all slowly adds up where you think a simple $10 VPS with 2 gigs of ram is enough but it's not, especially if you want a team of 10-30ish to work sporadically within the same box.
There can be a lot of major wins by rewriting these programs in more efficient languages like Go or Rust. It would make self hosting more maintainable and break away from the consulting class that often has worse solutions at way higher prices (for an example, one consulting group sells software similar to postiz but for $2k/month).
For a server built in the cloud those cycles could actually be taken up by other things, freeing the system and bringing costs down.
For a client computer running electron, as long as the user doesn't have so many electro apps open that their computer slows down noticeably, that inefficency might not matter that much.
Another aspect is that the devices get cheaper and faster so today's slow electron app might run fine on a system that is a few years away, and that capacity was never going to be taken up by anything else on the end user's device.
at least 100x slower than it needs to be?
For anyone that doesn't know: With sqlite you can serialize the db to a buffer and create a "new" db from that buffer with just `new Datebase()`. Just run the migrations once on test initialization, serialize that migrated db and reuse it instantly for each test for amazing test isolation.
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
See Sitecore Cloud, Sanity, Contentful,....
(haven't tried it myself)
I'm a big believer in fully reviewing all LLM generated code, but if I had to generate and review a webpack config like this, my eyes would gloss over...
The big news regarding Void Cloud is that it all seems to be built on Cloudflare workers. The landing page is very light on info atm too. [0]
I am super excited that they are MIT open sourcing Vite+ however. In that realm, they are obviously targeting Bun as their main competition. Unfortunately for Bun, if they are forced to help Anthropic more than they can focus on OSS, they might lose their current (perceived?) advantage.
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.
- Every Electron app ships with its own copy of Chromium (for rendering the UI) and Node.js (for system APIs). So even simple apps start with a fairly large memory footprint. It also means that electron essentially ships 2 instances of v8 engine (JIT-compiler used in Chromium and NodeJS), which just goes to show how bloated it is.
- Electron renders the UI using HTML, CSS, and JavaScript. That means the app needs a DOM tree, CSS layout engine, and the browser rendering pipeline. Native frameworks use OS widgets, which are usually lighter and use less memory.
- Lastly the problem is the modern web dev ecosystem itself; it is not just Electron that prioritises developer experience over everything else. UI frameworks like React or Vue use things like a Virtual DOM to track UI changes. This helps developers build complex UIs faster, but it adds extra memory and runtime overhead compared to simpler approaches. And obviously don't get me started on npm and node_modules.
All it has to do is put price pressure on your salary. (And it is already doing that.)
That's no less a build step than concating, bundling, minifying, etc. When people say "I'm against processing code before deploying it to a web site" but then also say "TypeScript is okay though" or "JSX is okay though," all they're really saying is "I like some build steps but not others." Which is fine! Just say that!
There are several much better options right now. My favourite is Tanstack Start. No magice, great DX
Fast all the way down, especially when coupled with REPL tooling.
Why do you expect to be able to replace a 2k/month solution with a $10/month VPS?
This method is actually super popular in the PHP world, but people get themselves into trouble if they tidy up all the footguns that stock sqlite leaves behind for you (strict types being a big one).
Also, when you get a certain size of database, certain operations can become hideously slow (and that can change depending on the engine as well) but if you're running a totally different database for your test suite, it's one more thing that is different.
I do recognize that these are niche problems for healthy companies that can afford to solve them, so ymmv.
Was it? Have you forgotten namespaces and enums?
You're not actually suggesting that technology can't evolve are you? Especially one whose original design goals were to process basic forms and are now being used to build full-blown apps?
It's absolutely wild to me that with everything that has happened in the last 2 decades with regard to the web there are still people who refuse to accept that it's changed. We are building far bigger and more complex applications with JavaScript. What would you propose instead?
These days, TypeScript will only add new features if they are either JavaScript features that have reached consensus (stage 3 iirc), or exist at the type system only.
There have been attempts to add type hints directly to JavaScript, so that you really could run something like TypeScript in the browser directly (with the types being automatically stripped out), but this causes a lot of additional parsing complexity and so nothing's really come of it yet. There's also the question of how useful it would even be in the end, given you can get much the same effect by using TypeScript's JSDoc-based annotations instead of `.ts` files, if you really need to be able to run your source code directly.
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.
Imagine a page that loads html during the first load, and then performs client-side routing during subsequent navigations. Is it an SPA? Is it not an SPA?
And to sell Vercel on top.
10 years ago this sentence probably would have start a flame war. ;-)
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.
Fetch index.html -> Fetch JS bundle -> Evaluate -> Fetch /users/me
You do:
Fetch index.html (your page is rendered at this point) -> rehydrate with client side JS for interactivity in the background
It's a pretty smart solution I think, and many people are still sleeping on the whole SSR topic.
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?
The LLM generated vite config is 20 lines
> Unfortunately for Bun, if they are forced to help Anthropic more than they can focus on OSS
Curious: is that speculation, or based on observation?
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.
https://esbuild.github.io/plugins/#svelte-plugin
esbuild's plugin support is limited which is why vite had to use rollup for prod build.
Once you've created a zfs snapshot, everything else is basically instant and costs very little perf.
It was originally about build steps but now you're talking about it's design.
And your only response is to use a technology years away from being practical for most web apps?
This is also the length on our CI which is running on some POS build machine. Locally it's far faster, but with Vite 8 its crazy fast.
I recently migrated to Tanstack for this and confirm it's been strictly better so far, especially having dynamic paths in my use-case (makes a hybrid app much more realistic)
As a side note, I'm slowly moving out of Next.js, as you said, is bloated, full of stuff that is just noise and that benefits them (more network requests more money) for little user benefit.
Right now for me the gold standard is Vite + Tanstack Router. (And Elysia for api/server, but thats unrelated).
There is a decent bit of history around that page and whether some things should go in a collapsible div and whether that was prioritizing certain frameworks over other ones.
One thing I'm still salty about is that CRA isn't mentioned anywhere (in the entire site). It's like it never existed.
Getting SSR right is tricky and barely even matters for a lot of use cases I’m seeing with Next.
Better server/client integration when it comes to rendering UIs is neat, but there are other technologies that solve for that at a more fundamental level (htmx, phoenix)
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.
Regarding the Bun comment, that is speculation on my part. I have no real horse in the race but Anthropic didn’t buy them for lols.
In the age of cheap custom software solutions everyone should at least try to make something themselves that's fit for purpose. It doesn't take much to be a dangerous professional these days, and certainly more than ever before can a dangerous professional be truly dangerous.
He's saying that the software seems free, but is so inefficient that it bloats other costs to run it. And he never said he wanted to replace $2K/month with $10/month.
It's just garbage software, I brought it up as an example IDK why. Commentators here like knowing snippets about other industries in the profession, I know I do at least.
But to answer your Q, yes I do expect a cron job schedule, analytics, and a CRM not to require 8 gig of ram in order to not barf on itself too hard.
These things are incredibly resource intensive for their actual jobs. The software is incredibly wasteful.
A $5/vps should be enough to host every suite of software a small business needs. To think otherwise is extremely out of touch. We're talking about 3 concurrent users max here, software should not be buckling under such a light load.
Though it’s hard to imagine what the web would look like if the language had become the standard. JS is a pain but AS was even less suitable for general purpose compute.
It's grown into a product of cults and attempted zingers rather than pragmatic or sensible technical discussions about what we should and shouldn't expect to be able to do with an individual programming language.
edit: to clarify, I assume there needs to be a basical level of comprehension of programming languages to debate the nuance of one, and if you can't think of a single reason as to why someone would want types removed, that's a possible indicator you don't have that necessary level yet, and I think the most effective way for you to learn that is to Google it. Sorry for coming across as rude if you genuinely don't know this stuff.
If you already know many reasons as to why types would be removed, then it seems disingenuous to ask that question, other than to make the point that you feel types shouldn't be stripped. If you think that, say it, and explain why you think they shouldn't be stripped.
Also, writing JavaScript for the backend is needlessly underperforming for anything with any load.
2 gigs of ram should be considered overkill to cover every single business case for a variety of tools (analytics, mailer/newsletter, CRM, socials, e-commerce).
But in browser, for now only the more limited JSDoc-style types can be shipped as-is indeed.
March 12, 2026

We're thrilled to announce the stable release of Vite 8! When Vite first launched, we made a pragmatic bet on two bundlers: esbuild for speed during development, and Rollup for optimized production builds. That bet served us well for years. We're very grateful to the Rollup and esbuild maintainers. Vite wouldn't have succeeded without them. Today, it resolves into one: Vite 8 ships with Rolldown as its single, unified, Rust-based bundler, delivering up to 10-30x faster builds while maintaining full plugin compatibility. This is the most significant architectural change since Vite 2.
Vite is now being downloaded 65 million times a week, and the ecosystem continues to grow with every release. To help developers navigate the ever-expanding plugin landscape, we also launched registry.vite.dev, a searchable directory of plugins for Vite, Rolldown, and Rollup that collects plugin data from npm daily.
Quick links:
Play online with Vite 8 using vite.new or scaffold a Vite app locally with your preferred framework running pnpm create vite. Check out the Getting Started Guide for more information.
We invite you to help us improve Vite (joining the more than 1.2K contributors to Vite Core), our dependencies, or plugins and projects in the ecosystem. Learn more at our Contributing Guide. A good way to get started is by triaging issues, reviewing PRs, sending tests PRs based on open issues, and supporting others in Discussions or Vite Land's help forum. If you have questions, join our Discord community and talk to us in the #contributing channel.
Stay updated and connect with others building on top of Vite by following us on Bluesky, X, or Mastodon.
Since its earliest versions, Vite relied on two separate bundlers to serve different needs. esbuild handled fast compilation during development (dependency pre-bundling and TypeScript/JSX transforms) that made the dev experience feel instant. Rollup handled production bundling, chunking, and optimization, with its rich plugin API powering the entire Vite plugin ecosystem.
This dual-bundler approach served Vite well for years. It allowed us to focus on developer experience and orchestration rather than reinventing parsing and bundling from scratch. But it came with trade-offs. Two separate transformation pipelines meant two separate plugin systems, and an increasing amount of glue code needed to keep the two pipelines in sync. Edge cases around inconsistent module handling accumulated over time, and every alignment fix in one pipeline risked introducing differences in the other.
Rolldown is a Rust-based bundler built by the VoidZero team to address these challenges head-on. It was designed with three goals:
The migration to Rolldown was deliberate and community-driven. First, a separate rolldown-vite package was released as a technical preview, allowing early adopters to test Rolldown's integration without affecting the stable version of Vite. The feedback from those early adopters was invaluable. They pushed the integration through real-world codebases of every shape and size, surfacing edge cases and compatibility issues we could address before a wider release. We also set up a dedicated CI suite validating key Vite plugins and frameworks against the new bundler, catching regressions early and building confidence in the migration path.
In December 2025, we shipped the Vite 8 beta with Rolldown fully integrated. During the beta period, Rolldown itself progressed from beta to a release candidate, with continuous improvements driven by the testing and feedback of the Vite community.
During the preview and beta phases of rolldown-vite, several companies reported measurable reductions in production build times:
For large projects, the impact can be especially noticeable, and we expect further improvements as Rolldown continues to evolve.
With Vite 8, Vite becomes the entry point to an end-to-end toolchain with closely collaborating teams: the build tool (Vite), the bundler (Rolldown), and the compiler (Oxc). This alignment ensures consistent behavior across the entire stack, from parsing and resolving to transforming and minifying. It also means we can rapidly adopt new language specifications as JavaScript evolves. And by integrating deeply across layers, we can pursue optimizations that were previously out of reach, such as leveraging Oxc's semantic analysis for better tree-shaking in Rolldown.
None of this would have been possible without the broader community. We want to extend our deep thanks to the framework teams (SvelteKit, React Router, Storybook, Astro, Nuxt, and many others) who tested rolldown-vite early, filed detailed bug reports, and worked with us to resolve compatibility issues. We are equally grateful to every developer who tried the beta, shared their build time improvements, and reported the rough edges that helped us polish this release. Your willingness to test the migration on real projects helped make the transition to Rolldown smoother and more reliable.
Vite 8 requires Node.js 20.19+, 22.12+, the same requirements as Vite 7. These ranges ensure Node.js supports require(esm) without a flag, allowing Vite to be distributed as ESM only.
Beyond the Rolldown integration, Vite 8 includes several notable features:
Integrated Devtools: Vite 8 ships devtools option to enable Vite Devtools, a developer tooling for debugging and analysis. Vite Devtools provide deeper insights into your Vite-powered projects directly from the dev server.
Built-in tsconfig paths support: Developers can enable TypeScript path alias resolution by setting resolve.tsconfigPaths to true. This has a small performance cost and is not enabled by default.
emitDecoratorMetadata support: Vite 8 now has built-in automatic support for TypeScript's emitDecoratorMetadata option, removing the need for external plugins. See the Features page for details.
Wasm SSR support: .wasm?init imports now work in SSR environments, expanding Vite's WebAssembly feature to server-side rendering.
Browser console forwarding: Vite 8 can forward browser console logs and errors to the dev server terminal. This is especially useful when working with coding agents, as runtime client errors become visible in the CLI output. Enable it with server.forwardConsole, which activates automatically when a coding agent is detected.
@vitejs/plugin-react v6 Alongside Vite 8, we are releasing @vitejs/plugin-react v6. The plugin uses Oxc for React Refresh transform. Babel is no longer a dependency and the installation size is smaller.
For projects that need the React Compiler, v6 provides a reactCompilerPreset helper that works with @rolldown/plugin-babel, giving you an explicit opt-in path without burdening the default setup.
See the Release Notes for more details.
Note that v5 still works with Vite 8, so you can upgrade the plugin after upgrading Vite.
The Rolldown integration opens the door to improvements and optimizations. Here is what we are working on next:
Full Bundle Mode (experimental): This mode bundles modules during development, similar to production builds. Preliminary results show 3x faster dev server startup, 40% faster full reloads, and 10x fewer network requests. This is especially impactful for large projects where the unbundled dev approach hits scaling limits.
Raw AST transfer: Allows JavaScript plugins to access the Rust-produced AST with minimal serialization overhead, bridging the performance gap between Rust internals and JS plugin code.
Native MagicString transforms: Enables custom transforms where the logic lives in JavaScript but the string manipulation computation runs in Rust.
Stabilizing the Environment API: We are working to make the Environment API stable. The ecosystem has started regular meetings to better collaborate together.
We want to be transparent about changes to Vite's install size. Vite 8 is approximately 15 MB larger than Vite 7 on its own. This comes from two main sources:
We will continue monitoring and working to reduce install size as Rolldown matures.
For most projects, upgrading to Vite 8 should be a smooth process. We built a compatibility layer that auto-converts existing esbuild and rollupOptions configuration to their Rolldown and Oxc equivalents, so many projects will work without any config changes.
For larger or more complex projects, we recommend the gradual migration path: first switch from vite to the rolldown-vite package on Vite 7 to isolate any Rolldown-specific issues, then upgrade to Vite 8. This two-step approach makes it easy to identify whether any issues come from the bundler change or from other Vite 8 changes.
Please review the detailed Migration Guide before upgrading. The complete list of changes is in the Vite 8 Changelog.
As Vite moves to Rolldown, we want to take a moment to express our deep gratitude to the two projects that made Vite possible.
Rollup has been Vite's production bundler since the very beginning. Its elegant plugin API design proved so well-conceived that Rolldown adopted it as its own, and Vite's entire plugin ecosystem exists because of the foundation Rollup laid. The quality and thoughtfulness of Rollup's architecture shaped how Vite thinks about extensibility. Thank you, Rich Harris for creating Rollup, and Lukas Taegert-Atkinson and the Rollup team for maintaining and evolving it into something that has had such a lasting impact on the web tooling ecosystem.
esbuild powered Vite's remarkably fast development experience from its early days: dependency pre-bundling, TypeScript and JSX transforms that completed in milliseconds rather than hundreds. esbuild proved that build tools could be orders of magnitude faster, and its speed set the bar that inspired an entire generation of Rust and Go-based tooling. Thank you, Evan Wallace, for showing all of us what was possible.
Without these two projects, Vite would not exist as it does today. Even as we move forward with Rolldown, the influence of Rollup and esbuild is deeply embedded in Vite's DNA, and we are grateful for everything they have given to the ecosystem. You can learn more about all the projects and people Vite depends on at our Acknowledgements page.
Vite 8 was led by sapphi-red and the Vite Team with the help of the wide community of contributors, downstream maintainers, and plugin authors. We want to thank the Rolldown team for their close collaboration in making the Rolldown-powered Vite 8 possible. We are also especially grateful to everyone who participated in the rolldown-vite preview and the Vite 8 beta period. Your testing, bug reports, and feedback made the Rolldown migration possible and shaped this release into something we are proud of.
Vite is brought to you by VoidZero, in partnership with Bolt and NuxtLabs. We also want to thank our sponsors on Vite's GitHub Sponsors and Vite's Open Collective.
Then again Teams is still barely an amateur compared to the incomprehensible slowness of Jira.
And such an extrodinary different is usually holding the tool wrong, but Next has years old open issues for many of the causes here (like forced output tracing) and has just ignored them. Possibly because the Next team's preferred deployment environment isn't affected?
The general TLDR is:
- CRA was listed in the _old_ docs site
- The new docs site coincided with the React team emphasizing "frameworks" to provide an all-in-one build experience and hopefully lead to better apps.
- That also meant no ala-carte build tools were listed. This made many people (including me) unhappy.
- CRA broke when React 19 came out in Dec 2024. This caused problems for beginners.
- I pushed the React team to both deprecate CRA and finally rewrite the setup pages to list other build tools as valid options.
I wrote up a much longer background of what happened around the "frameworks" push and this docs page here:
- https://blog.isquaredsoftware.com/2025/06/react-community-20...
And here's the issue I filed pushing the React team to deprecate CRA (after some online discussion):
- https://github.com/facebook/create-react-app/issues/17004
and a follow-up PR where I tried to rewrite the initial rather confusing post-CRA-deprecation "Creating Your Own Framework" page with a more relevant "Creating a React App" page:
- https://github.com/reactjs/react.dev/pull/7618
but the overall point of _all_ of this is that CRA was unmaintained as of 2023, the community had _already_ moved on to Vite, and all this was an attempt to get the React docs to reflect that reality.
The React team (really Vercel + Shopify) decided to use the supremely misleading names "Server Component" and "Client Component" for two things that do not affect CSR vs SSR.
Even if you label the root of your app "use client" (thus opting out of all the new complexity around RSC and server actions), it's still getting rendered server side.
It is broadly useful and relatively easy to use while still staying within the React framework the developer knows well.
That said, I didn't build more than a demo app with NextJS, so I don't know a lot about possible issues. Just the concept seems to be good.
Not sure whether VoidZero and Vercel sharing the same investor has any sorts of implication.
Software can be drastically way less resource intensive, there is no excuse outside of wanting to exacerbate the climate crises.
This period of our history in the profession will be seen as a tremendous waste of resources and effort.
Where is this weird expectation coming from?
Why should that be the case?
ActionScript3 was a very suitable language.
See OCaml or Haskell, they also have interpreters and REPLs as part of their tooling.
Also there should be no need to always compile crates from scratch when starting a new project.
Which ironically circles back to your remark of having a similar problem.
These things aren't complicated, but when you choose NodeJS/Javascript they become way more complicated than expected. I say this as someone who has ever worked professionally with JS and nothing else for a 15 year long career.
Writing software that can only be used by the affluent is not the direction I want our industry to go in.
I've been following you and some of the other main React devs.
> That also meant no ala-carte build tools were listed. This made many people (including me) unhappy.
I had followed a decent bit of this back on Twitter, and appreciate you guys trying to make the documentation better (despite all of the drama that came up as a result).
And while it's definitely slowed down a bit, I still randomly see a "What happened to CRA" on the r/react sub.
I guess what bothers me the most is that CRA was not only mine, but quite a few others first introduction to React. And it's just weird that it wasn't even called out in the new docs (even back in 2022-2023). Like it had never existed.
Regardless, I appreciate that you guys care enough to help move React in the right direction. A lot happened while this was going on, and you guys put up with A LOT during this process.
Accel sees the money in vendor lock-in and is so far willing to let these companies fund their open source endeavors and sell hosting as a means to an end. Im not sure we’ve seen the real end game here yet but with geopolitics raising the cost of energy a ton this year, perhaps some screws are going to begin being tightened as margins are reduced. At present, I think its too early to tell.
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.
Go write the software yourself, no one owes you anything.
Maybe if you had to actually write it yourself, you'd quickly figure out why people prefer "inefficient" languages for these things.
A cron job scheduler does not in fact require 500 MB of memory. You're just being disingenous, that software is doing a lot more than just that.
Maybe leave JavaScript on the browser, where it belongs.
People prefer JS because all they know is JS, it's that simple. Please tell me why you think devs choose JS, I'm legitimately curious but your attitude of constant dismissal and disparagement makes it seem you just want to beat people down and not engage.