Art 12 ↔ Art 19 — Privacy rights in localStorage tracking conflict with freedom to access and share information; site collects user state data without visible consent while promoting open knowledge access.

slopinthebag 2026-03-13 04:59 UTC link

> 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.

johnfn 2026-03-13 05:46 UTC link

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!

brandensilva 2026-03-13 05:56 UTC link

Man the perf changes for this version are awesome. Thanks Vite.

soulchild77 2026-03-13 06:45 UTC link

Awesome! Too bad Next.js will never profit from these incredible community efforts, because Vercel suffers from NIH.

nebezb 2026-03-13 07:23 UTC link

> Built-in tsconfig paths support

A great QoL change. One less place to duplicate (and potentially mistake) a config.

karel-3d 2026-03-13 08:25 UTC link

Yesterday I stopped hating AI because it converted an old webpack project with impenetrable plugin settings to a single simple Vite 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

homebrewer 2026-03-13 08:29 UTC link

Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers. One of the projects I'm working on has been going for many years (since before React hooks were introduced), and I remember building it back in the day with tooling that was considered standard at the time (vanilla react-scripts, assembled around Webpack). It look maybe two minutes on a decent developer desktop, and old slow CI servers were even worse. Now Vite 8 builds it in about a second on comparable hardware. Another demonstration of how much resources we're collectively wasting.

imfing 2026-03-13 08:36 UTC link

Awesome! been using Vite since its early days. really excited to see how it's improving the JavaScript and TypeScript tooling landscape and how it continues to evolve

gdorsi 2026-03-13 08:48 UTC link

Sweet, great job Vite team!

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.

shunia_huang 2026-03-13 09:02 UTC link

Ah, wondering how long it will take Angular to replace it's sh*t building tool chain to fully vite compatible, hope it could happen before I change may career path or retire.

moretti 2026-03-13 09:21 UTC link

Thanks to the Vite team for building a faster, modern bundling solution on a fully open source stack that isn't tied to a specific framework...cough cough, Turbopack

throwaway290 2026-03-13 09:51 UTC link

Outsider question: why use Rollup when Esbuild exist? Is esbuild not enough for production builds?

h4ch1 2026-03-13 10:04 UTC link

I've been using rolldown-vite for the past 3-4 months with absolutely no issues on a very large monorepo with SvelteKit, multiple TS services and custom packages.

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.

raydenvm 2026-03-13 10:05 UTC link

Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it.

Kudos to the Vite maintainers!

Aldipower 2026-03-13 11:25 UTC link

As I am interested in long time maintainability (should still work in 10 years) with my projects I am just using esbuild directly. I am not interested in adjusting my projects, just because things changed under the hood in "wrappers" like Vite and I suddenly have a lot of work.

brillout 2026-03-13 12:15 UTC link

Vite+, Void Cloud, Void Framework... an epic battle between Vercel and Void is coming.

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

chrisweekly 2026-03-13 13:43 UTC link

Awesome news. Amid all the (real and perceived) js ecosystem churn, vite has been consistently excellent for dx and production. The unified rolldown bundler is only going to increase vite's appeal and widen the gap as the fastest, most pragmatic and flexible foundation for ts/js projects. Huge fan, speaking from deep experience (webdev since 1998).

vite_throwaway 2026-03-13 13:58 UTC link

I have a small React project using vite 7 and have the following in my config so that vite interprets ".js" files as JSX:

    // 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.

upsuper 2026-03-13 15:36 UTC link

I contributed this change in Vite 8:

> 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.

ameliaquining 2026-03-13 06:13 UTC link

Yes, those work fine: https://playground.oxc.rs/?options=%7B%22run%22%3A%7B%22lint...

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.

rvcdbn 2026-03-13 06:56 UTC link

maybe of interest: https://github.com/cloudflare/vinext

(haven't tried it myself)

CalRobert 2026-03-13 06:57 UTC link

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?

pjmlp 2026-03-13 07:02 UTC link

They have the enterprise partners that make Next.js the only officially supported SDK on their SaaS integrations.

See Sitecore Cloud, Sanity, Contentful,....

gherkinnn 2026-03-13 07:43 UTC link

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].

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/

Griffinsauce 2026-03-13 08:03 UTC link

4 minutes?! How large is that app?

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)

FrostKiwi 2026-03-13 08:13 UTC link

Same here (10s to 1s). The main reason for this is rolldown [1]. Already had it installed months ago, before it got merged into vite proper. Really awesome stuff.

[1] https://rolldown.rs/

vbezhenar 2026-03-13 08:45 UTC link

It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. Web development should strive to launch unchanged sources in the browser. TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.

bengale 2026-03-13 08:49 UTC link

We saw 12m -> 2m on one of our biggest projects. Incredible really.

rk06 2026-03-13 10:26 UTC link

it is not. lack of plugin support is sufficient to block adoptions among other things.

jillesvangurp 2026-03-13 11:32 UTC link

Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes.

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.

Zopieux 2026-03-13 11:43 UTC link

I wonder what will be the parallel hindsight about waste, but for matrix multiplications, in a few years.

this_user 2026-03-13 11:46 UTC link

> Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers.

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.

itsTyrion 2026-03-13 12:44 UTC link

the vite Homepage lags on both an A55 and s23fe regardless, which bears at least some irony

emadda 2026-03-13 12:45 UTC link

esbuild has been very stable for my projects too.

I think it is the only tool in the JS ecosystem that has not broken after a few years.

christophilus 2026-03-13 13:04 UTC link

This is the way. Trivial to get live reloading working. HMR is overrated. I went with esbuild in my last project, and have no regrets. Also, used my own 100-line end-to-end typed RPC layer with Zod validation doing the heavy lifting. No codegen required for any part of the project other than generating types from Postgres. No regrets there, either. The only thing I would have changed in that project is I would have used Kysely instead of just raw porsager.

jjice 2026-03-13 13:37 UTC link

800 lines config to compile code that's later interpreted is wild. I get the general idea behind having a script instead of a static config, so you can do some runtime config (whether or not we should have runtime changes to config is a different conversation), but this is absurd.

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...

silverwind 2026-03-13 13:50 UTC link

IIRC, esbuild is still lacking code splitting.

chearon 2026-03-13 13:53 UTC link

esbuild still doesn’t support top-level await. And live reloading is way, way slower than HMR.

c-hendricks 2026-03-13 13:57 UTC link

This is great news, but people should also try using regular nodejs import aliases and see if they're viable for their project.

semiquaver 2026-03-13 13:58 UTC link

The waste of slow JS bundles is nothing compared to the cost of bloated interpreted runtimes or inefficient abstractions. Most production software is multiple orders of magnitude slower than it needs to be. Just look at all the electron apps that use multiple GB of ram doing nothing and are laggier than similar software written 40 years ago despite having access to an incredibly luxurious amount of resources from any sane historical perspective.

spiros 2026-03-13 14:25 UTC link

The solution here is working for me: https://github.com/vitejs/vite/discussions/21505

Though sometimes oxc complains about JSX in JS when running vite, but it still works fine.

abrztam 2026-03-13 14:51 UTC link

also since typescript is being ported to go and rolldown is rust, they're stuck using IPC, so they miss out on native stuff like type awareness that a pure go toolchain would get for free

iainmerrick 2026-03-13 15:09 UTC link

Sorry if this comes across as overly facetious — I’m sure you have a reason for doing it that way! — but would it not be easier just to bow to convention and rename your .js files to .jsx?

ezfe 2026-03-13 15:29 UTC link

I'm curious why you use `.js` files instead of `.jsx`? In my experience, using `jsx` files makes everything work better

bovermyer 2026-03-13 16:37 UTC link

This is a fun insight, thank you for sharing that!

I like Vite as a tool, but knowing that the Vite folks actually care about helping others learn and contribute is awesome.

yurishimo 2026-03-13 16:58 UTC link

You say that, but isn't Vercel also a Void(0) investor in a roundabout way?

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.

0: https://void.cloud/

KronisLV 2026-03-13 20:40 UTC link

> Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take."

I feel the same way about tools like ESLint and Prettier as well after discovering Oxc https://oxc.rs/

Klaster_1 2026-03-14 05:55 UTC link

They recently put out a new roadmap item to adapt the compiler to modern tools: https://angular.dev/roadmap#developer-velocity . Given the great track record of recent Angular road map deliverables, I think they'll come up with something at least faster than what we have now. Angular already runs on Vite, and the fact that Vite 8 exposes AST level plugin endpoints are good signs. Not waiting 1 minute for unit test suite or `ng serve` cold start would be very welcome indeed.

rk06 2026-03-14 07:48 UTC link

Vercel owns nuxt and sveltekit, so they do benefit. only nextjs suffers from not being on vite.

flohofwoe 2026-03-14 09:55 UTC link

No worries, projects will soon catch up by throwing more code at the build system.

Editorial Channel

What the content says

Structural Channel

What the site does