Vite 8.0 Is Out

3/13/2026 at 10:05:02 AM

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!

by raydenvm

3/13/2026 at 1:58:03 PM

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.

by semiquaver

3/13/2026 at 2:28:40 PM

Something I realized while doing more political campaign work is how inefficient most self hosted solutions are. Things like plausible or umami (analytics) require at least 2 gigs of ram, postiz (scheduled social media planner) requires 2 gigs of ram, etc.

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

by shimman

3/13/2026 at 4:48:42 PM

So you have free software that requires 2 GB of RAM and the alternative is $2k per month and you're complaining that the free solution is inefficient? Really?

Why do you expect to be able to replace a 2k/month solution with a $10/month VPS?

by ahtihn

3/13/2026 at 5:15:09 PM

Because the fundamental task many of these programs are doing is neither complicated nor resource intensive.

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.

by xyzzy_plugh

3/13/2026 at 7:34:44 PM

Thank you, I get so confused when people think a $5/vps shouldn't be able to do much. We're talking about 99% of small business that might have 5 concurrent users max.

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

by shimman

3/13/2026 at 5:43:28 PM

Your criticism contradicts itself.

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.

by MoonWalk

3/13/2026 at 7:26:21 PM

I'm not saying it's so bad I don't recommend it, quite the opposite; but these things can be written in more performant languages. There's no reason why a cron job scheduler requires 500 mb of ram in idle. Same for the analytics. That is just a waste of resources.

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.

by shimman

3/14/2026 at 3:31:08 PM

Dude you're complaining about the efficiency of free software.

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.

by ahtihn

3/14/2026 at 5:04:11 PM

I am writing software myself and your attitude is just weird. We should always strive for better more efficient software, the climate crisis is a real thing and our industry has done an excellent job exacerbating it with more inefficient tools, libraries, and languages.

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.

by shimman

3/15/2026 at 2:04:38 PM

People choose JS because it’s the only first class browser language. Why they choose it on the backend I honestly couldn't tell you.

by semiquaver

3/13/2026 at 7:30:26 PM

Dude, the $2k solution is not only worse than postiz they charge an additional thousand for each channel.

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.

by shimman

3/14/2026 at 3:34:09 PM

> A $5/vps should be enough to host every suite of software a small business needs

Where is this weird expectation coming from?

Why should that be the case?

by ahtihn

3/14/2026 at 5:00:38 PM

The expectation is that these aren't complicated tools, they should not command that many resources. Why do you think a $5/vps with half a gig of ram can't handle basic CRON/background jobs or management software? 512 mb of ram can do so much if you choose the appropriate tools but if you start with a weak foundation that requires 512 mb of ram to just stay idle it hurts a class of users that could benefit from this software.

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.

by shimman

3/13/2026 at 2:36:20 PM

I guess there's the distinction between capacity that could be taken up by other things, and free capacity that doesn't necessarily cost anything.

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.

by awongh

3/13/2026 at 4:24:20 PM

It’s more likely that Electron app uses poor code and have supply chain issue (npm,…). Also loading a whole web engine in memory is not cheap. The space could have been used to cache files, but it’s not, which is inneficient especially when laptops’ uptime is generally higher.

by skydhash

3/13/2026 at 8:28:04 PM

Don't forget the human time wasted by an app being slow and laggy.

by patmorgan23

3/13/2026 at 5:46:23 PM

> Most production software is multiple orders of magnitude slower than it needs to be.

at least 100x slower than it needs to be?

by jjtheblunt

3/13/2026 at 6:23:59 PM

Easily. Lots of things can take 3ms that actually take 300ms. Happens all the time.

by eudamoniac

3/13/2026 at 10:26:07 PM

what's an example?

by jjtheblunt

3/14/2026 at 12:01:55 AM

A poorly written SQL query, an algorithm on large data sets using suboptimal bigO, the Home Depot or Lowe's website search bars, etc

by eudamoniac

3/14/2026 at 2:50:22 AM

good examples, i agree

by jjtheblunt

3/13/2026 at 4:51:05 PM

Why are electron apps memory intensive compared to other cross platform frameworks. Is it language, UI system or legacy?

by blackoil

3/13/2026 at 5:53:46 PM

Electron apps tend to use a lot of memory because the framework favors developer productivity and portability over runtime efficiency.

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

by gamefamecame

3/13/2026 at 5:46:05 PM

Loading a browser context isn't helping.

by PacificSpecific

3/13/2026 at 5:08:51 PM

Imagine the amount of useful apps that would not have been made without Electron.

by spiderfarmer

3/13/2026 at 8:40:49 PM

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

by KronisLV

3/13/2026 at 11:43:54 AM

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

by Zopieux

3/13/2026 at 11:47:55 AM

By then I understand that matrix multiplication will have cured cancer and invented unlimited free energy, so no hindsight of waste needed.

by _heimdall

3/13/2026 at 1:25:14 PM

Cure cancer? It doesn't have to cure cancer for it to make billions.

All it has to do is put price pressure on your salary. (And it is already doing that.)

by echelon

3/13/2026 at 3:40:07 PM

The economic incentives line up much better there. You charge for tokens -> cost is GPUs -> you work very hard to keep GPUs utilized 100% and get max tokens out of those cycles.

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.

by xxpor

3/13/2026 at 11:32:58 AM

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.

by jillesvangurp

3/13/2026 at 1:36:07 PM

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

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.

by Sammi

3/13/2026 at 4:50:59 PM

Assuming you use sqlite in prod or are willing to take the L if some minor db difference breaks prod...

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.

by yurishimo

3/14/2026 at 10:32:51 AM

We've had this exact same issue (clean db for every test) - the way we solved it was with ZFS snapshots - just snapshot a directory of our data (databases, static assets, etc) - and the OS will automatically create a copy-on-write replica that can be written to, and the modification can be just thrown away (or preserved).

Once you've created a zfs snapshot, everything else is basically instant and costs very little perf.

by torginus

3/13/2026 at 3:30:17 PM

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

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.

by panstromek

3/16/2026 at 1:55:57 AM

>With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax.

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.

by charleslmunger

3/13/2026 at 2:09:27 PM

Kotlin compiles fast; I don't have any problems with ktor. Spring Boot and Rust do not.

by esafak

3/14/2026 at 9:55:08 AM

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

by flohofwoe

3/13/2026 at 5:12:48 PM

[dead]

by gtsop

3/13/2026 at 8:29:13 AM

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.

by homebrewer

3/13/2026 at 11:46:05 AM

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

by this_user

3/13/2026 at 12:44:04 PM

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

by itsTyrion

3/13/2026 at 8:45:05 AM

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.

by vbezhenar

3/13/2026 at 8:57:51 AM

JavaScript was not supposed to a lot of things.

by __alexs

3/13/2026 at 11:26:23 AM

Steve Jobs decided differently when he hated on ActionScript.

10 years ago this sentence probably would have start a flame war. ;-)

by Aldipower

3/13/2026 at 11:55:34 AM

Jobs’ complaint wasn’t actionscript the language, it was the security and performance nightmare of the Flash runtime.

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.

by brookst

3/13/2026 at 1:19:31 PM

And at least the "performance nightmare" is an irony from today's perspective as the Flash player wasn't actually slow at all! It was the incapability of the Safari browser to handle plugins in a good way and on mobile devices. Today's implementations of mobile application, JavaScript heavy applications and websites are much much more performance heavy.

ActionScript3 was a very suitable language.

by Aldipower

3/13/2026 at 3:19:46 PM

Flash performance was also hit or miss on Linux.

by c-hendricks

3/15/2026 at 1:17:57 AM

Eh, language was fine, runtime was pretty bad.

by brookst

3/13/2026 at 5:30:32 PM

Well JavaScript was supposed to be a glue between browsers and Java Applets.

by karel-3d

3/13/2026 at 9:19:01 AM

And yet it pays my bills for almost two decades.

by dschu

3/13/2026 at 12:50:16 PM

Probably wasn't supposed to either :-)

by azangru

3/13/2026 at 4:53:07 PM

Nice gatekeeping. :-)

by dschu

3/13/2026 at 9:02:41 AM

If you're already passing over the sources to strip the types, why would you also not do tree-shaking and minifications?

by olmo23

3/13/2026 at 9:52:57 AM

Why would I want to strip my types?

by ZiiS

3/13/2026 at 10:17:03 AM

Because it's a waste of bandwidth if they're not enforced at runtime, the same reason why minification exists.

by wildpeaks

3/13/2026 at 10:52:54 AM

Both not minifying and including unenforced type hints consumes a little bandwidth though this can be largely offset by compression. This is an engineering trade off against the complexity of getting source maps working reliably for debugging and alerting. If I am shipping a video player or an internal company dashboard how much of my time is that bandwidth worth?

by ZiiS

3/13/2026 at 11:07:11 AM

Maybe because TypeScript is not valid JavaScript (yet)? If you don't strip types, your code doesn't work.

by dminik

3/13/2026 at 12:25:25 PM

It depends on the runtime: Node can run Typescript because it automatically strips types (which is so convenient during development).

But in browser, for now only the more limited JSDoc-style types can be shipped as-is indeed.

by wildpeaks

3/13/2026 at 10:08:31 AM

This feels like a ridiculous thread that captures everything wrong with modern Javascript ecosystem.

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.

by 1dom

3/13/2026 at 11:04:00 AM

The current state of Javascript is you _have_ to remove types; I was pointing out I can think of reasons why I sometimes wouldn't want to. (Admittedly in a glib manor; though on this site many prefer that to four paragraphs)

by ZiiS

3/13/2026 at 10:54:40 AM

How goes that saying?... always assume ignorance or malice will getcha

by pestatije

3/14/2026 at 8:47:39 AM

Hear me out: javascript integrates types as comments (ignored by default) in its standard and engines start to use types as performance / optimization hints. If you mistype, your program runs, but you get worse performance and warnings in console. If you type correctly, your program runs more efficiently. We already have different levels of optimization in V8 or JSC, why can't they use type hints to refine predictions?

by curtisblaine

3/13/2026 at 12:49:24 PM

> TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.

Was it? Have you forgotten namespaces and enums?

by azangru

3/13/2026 at 1:19:31 PM

More recently, it's been designed so this is the case. Namespaces, enums, and the property constructor shortcut thing were all added relatively early on, before the philosophy of "just JS + types" had been fully defined.

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.

by MrJohz

3/13/2026 at 2:59:10 PM

> TypeScript also was specifically designed so engine could strip types and execute result code.

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!

by tshaddox

3/13/2026 at 12:21:16 PM

> It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me.

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?

by mexicocitinluez

3/13/2026 at 4:44:57 PM

If you want to make ultra-complicated clients, I assume that's what WebAssembly is heading towards. And it doesn't limit you to a poorly evolved language that wasn't intended for ultra-complicated software in the first place, or even force you to use that poorly evolved language on a server if you need to run the same logic in both places.

by jhgb

3/13/2026 at 7:12:05 PM

You're moving the goal posts.

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?

by mexicocitinluez

3/13/2026 at 8:54:55 AM

[dead]

by k4rnaj1k

3/13/2026 at 5:46:32 AM

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!

by johnfn

3/13/2026 at 8:13:24 AM

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/

by FrostKiwi

3/13/2026 at 8:03:27 AM

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)

by Griffinsauce

3/13/2026 at 8:39:06 AM

most likely they are not running the prod build on latest mac. so it is slower.

by rk06

3/13/2026 at 9:20:42 AM

Yeah, 4 mins is currently the avg. build time for our TanStack app dockerized. The turbo part takes 30 sec with Vite 7

by dschu

3/13/2026 at 8:49:41 AM

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

by bengale

3/13/2026 at 9:39:54 AM

It blows my mind that there is a 12m build for a JavaScript application. How may lines of code is this app?

by christophilus

3/13/2026 at 10:42:57 AM

Seems to be around 1 million. It's chunky and it's probably not well optimised for the build to be honest, but it was only starting to creep up the priority list as it crossed the 10m mark.

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.

by bengale

3/13/2026 at 11:02:12 AM

My banking site takes 10 seconds to LOAD...I hate thinking how long it must take them to compile it

by pestatije

3/13/2026 at 6:12:21 PM

I am still trying to work out what Teams is "setting up for me" when it takes several seconds from opening the bookmark in my browser to having a UI where I can read the chats. It's running on a PC that can render complex graphical scenes in real time but it takes half a minute to see "LGTM!". (Shaking head emoji goes here.)

Then again Teams is still barely an amateur compared to the incomprehensible slowness of Jira.

by Silhouette

3/13/2026 at 3:36:20 PM

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.

by upsuper

3/13/2026 at 4:37:32 PM

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.

by bovermyer

3/13/2026 at 9:21:52 AM

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

by moretti

3/13/2026 at 6:45:26 AM

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

by soulchild77

3/13/2026 at 7:43:14 AM

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/

by gherkinnn

3/13/2026 at 7:51:12 AM

Next took a very bad turn and double downed on it. Coupled with years of terrible bugs its beyond repair for me unless they rewind a bunch of core changes they did.

There are several much better options right now. My favourite is Tanstack Start. No magice, great DX

by ssijak

3/13/2026 at 9:14:17 AM

+1 for Tanstack start. I just setup a new project with it and like the whole ecosystem. Only slight disadvantage is most third party documentation and automatic setup with packages aren't setup for Tanstack Start yet.

by adamgoodapp

3/13/2026 at 9:19:42 AM

Any suggestions to replace NextJS when you only use static export (no SSR)?

by littlecranky67

3/13/2026 at 10:39:09 AM

Tanstack Start is the gold standard here. It’ll do a static export no problem.

by dbbk

3/13/2026 at 4:02:39 PM

I'm surprised anyone's using Next for static exports when they've left dynamic paths broken for years.

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)

by BoorishBears

3/13/2026 at 9:42:15 AM

It depends on your application, but for typical SPAs, there are any number of approaches which are better than next by every metric I (personally) care about.

by christophilus

3/13/2026 at 12:02:55 PM

Care to list those?

by littlecranky67

3/13/2026 at 10:39:29 AM

Astro: https://astro.build/

by J_tt

3/13/2026 at 11:59:01 AM

From my first glance, it is not really. Has its own templating syntax, its own file format etc. With NextJS static export I only have valid react/tsx and would not want to introduce a framework-specific language. Also could not easily find something about the routing

by littlecranky67

3/13/2026 at 12:35:21 PM

While Astro does indeed have its own type of components, it also supports React, Solid and a host of others. So transplanting your current tree of components in, adding the React plugin and saying "GO" is likely a fairly straight-forward project. I moved a previous static site into an older verison of Astro with very little trouble.

by nobleach

3/13/2026 at 9:46:51 AM

tanstack router

by NamlchakKhandro

3/13/2026 at 6:57:01 AM

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?

by CalRobert

3/13/2026 at 7:49:52 AM

I'm being rather snarky here, but the main point of front-end JS UI frameworks is to exist and to survive in their environment. For this purpose they have evolved to form a parasymbiotic relationship with others in their environment, for example with influencers. The frameworks with the best influencers win out over older ones that do not have the novelty value anymore and fail to attract the best influencers.

by flowerbreeze

3/13/2026 at 8:05:34 AM

This could also apply to the recent wave of hate towards Next.

by Griffinsauce

3/13/2026 at 9:46:00 AM

Next is the Microsoft Sharepoint of the JavaScript world. It’s a terrible solution to just about anything, and yet gets crammed into places and forced on people due to marketing-led decision making.

by christophilus

3/13/2026 at 4:12:28 PM

My 10 minute Next build was replaced with a 1 minute 30 second Vite build.

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?

by BoorishBears

3/13/2026 at 8:29:01 AM

Vercel has slowly taken over Facebook's position as being the employer of the main developers of React. There's a debate to be had over how much they 'control' it or not, but the fact create-next-app is the first recommended option on the official installation page now does show it's had an impact.

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.

by drawfloat

3/13/2026 at 3:11:00 PM

Exactly, this why if I use next.js I always hijack the api routes and use Elysia, it comes with something called eden that makes the typing e2e fantastic, can't recommend it enough.

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

by jvidalv

3/13/2026 at 12:25:25 PM

> but the fact create-next-app is the first recommended option on the official installation page now does show it's had an impact.

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.

by mexicocitinluez

3/14/2026 at 1:27:45 AM

Hi! I played a major part in getting that "installation" page rewritten to actually mention other tools like Vite :)

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.

by acemarke

3/14/2026 at 12:49:50 PM

Hey acemark,

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.

by mexicocitinluez

3/13/2026 at 10:36:05 AM

I'm trying to build a nextjs app and it's quite painful. It seems to be more and more focused on SSR, which I don't care about (looking for a static app that calls separate API endpoints). That would have been fine in the NextJS I remember from a few years ago, where static and SSR seemed equally viable, but I can't be bothered now. I'm going to try Tanstack Start.

by robertlagrant

3/13/2026 at 4:10:35 PM

99% of what you see with the word "server" vs "client" is actually orthogonal to SSR is that wasn't clear.

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.

by BoorishBears

3/13/2026 at 7:31:44 AM

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.

by codetantra

3/13/2026 at 7:36:45 AM

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.

by CalRobert

3/13/2026 at 8:06:40 AM

I had had a client cancel a job when they heard it's not going to use Wordpress. It was going to be a dashboard showing statistics (air quality, room bookings etc.) from their facility.

by patates

3/13/2026 at 8:25:16 AM

why? jsx is a great language for templating, the ui being a function of state is an incredible model. i am not a huge nextjs fan but React, mdx and friends are great for pre-rendered static content

by davidodio

3/13/2026 at 11:30:46 AM

Isn’t all templates language that way (blade, jade,…)? The main selling point of JSX is being a DSL for React, which present a functional model instead of the imperative paradigm of the DOM API.

by skydhash

3/13/2026 at 2:19:53 PM

If you are dealing with a static site then Astro makes more sense. Renders to just plain HTML while still allowing you to provide interactivity for part of page components using React or any framework by creating what Astro calls an island. You get best of both worlds, rich interactiveness by using JS and plain HTML/CSS where you need static.

by codetantra

3/13/2026 at 7:42:08 AM

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.

by gnarlbar

3/13/2026 at 11:49:50 AM

Instead of going:

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.

by user34283

3/13/2026 at 12:07:27 PM

It makes sense for sites with a lot of static pages, but you barely need react in that case. NextJS does not perform that well out of the box. I’d argue that a basic SPA with no SSR using something like preact would be a better choice for many building dashboards or applications (not marketing/docs sites). It’s also easier to host & operate and has fewer footguns.

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)

by anon7000

3/13/2026 at 12:48:38 PM

It rather appears to make sense for any site that currently makes additional requests to fetch data as part of the page load.

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.

by user34283

3/13/2026 at 1:01:43 PM

> Are people using react for non-SPA’s?

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?

by azangru

3/13/2026 at 8:30:03 AM

The point is JavaScript developers rediscovering PHP, Spring MVC, ASP.NET MVC, Rails,.....

And to sell Vercel on top.

by pjmlp

3/13/2026 at 7:02:35 AM

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

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

by pjmlp

3/13/2026 at 7:24:30 AM

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?

by rk06

3/13/2026 at 7:27:57 AM

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.

by pjmlp

3/14/2026 at 7:48:06 AM

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

by rk06

3/13/2026 at 6:56:53 AM

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

(haven't tried it myself)

by rvcdbn

3/13/2026 at 7:16:17 AM

It's not a good piece of software. Breaks in many places

by vijaybritto

3/13/2026 at 9:42:58 AM

that makes sense, it's not 1.0 yet

by rozenmd

3/13/2026 at 8:13:04 AM

"Read the announcement: How we rebuilt Next.js with AI in one week".

by littlecranky67

3/13/2026 at 8:25:14 AM

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

by karel-3d

3/13/2026 at 1:37:54 PM

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

by jjice

3/13/2026 at 3:11:14 PM

No no no, the script on the link was BEFORE llms. That was how it used to be done before. That was the recommended facebook way.

The LLM generated vite config is 20 lines

by karel-3d

3/13/2026 at 6:10:21 PM

Oh yeah, I got that - my comment is a bit confusing reading it back. The fact we used to built trash like that blows my mind. Makes me content having been on the backend.

by jjice

3/15/2026 at 3:38:48 AM

People fought to replace the tools of the era with this. It had some advantages over time - ES6, a good plugin ecosystem, react adoption - but quickly it just became "the standard" which everyone is afraid to question.

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.

[1] https://github.com/ricardobeat/cake-flour

by ricardobeat

3/13/2026 at 12:15:28 PM

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

by brillout

3/13/2026 at 4:58:54 PM

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/

by yurishimo

3/13/2026 at 5:07:50 PM

Doesn't seem like it — see VoidZero investors [0].

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

[0]: https://voidzero.dev/about

by brillout

3/14/2026 at 12:16:35 PM

Im pretty sure Accel is also heavily invested Vercel.

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.

by yurishimo

3/14/2026 at 12:50:39 PM

Indeed Accel is a long-term Vercel investor [0].

Not sure whether VoidZero and Vercel sharing the same investor has any sorts of implication.

[0]: https://vercel.com/blog/series-f

by brillout

3/14/2026 at 4:12:26 PM

Well, your original comment was about a war brewing between Vervel and Void0. If Accel has a stake in both, I don’t know that they really care. See the Laravel investment as well.

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.

by yurishimo

3/13/2026 at 4:59:08 AM

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

by slopinthebag

3/13/2026 at 6:13:32 AM

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.

by ameliaquining

3/13/2026 at 7:00:16 AM

TC39 decorators emit just landed in tsgo about 24 hours ago. Hopefully they're available in Vite 8 soon. I'm using them in GodotJS https://github.com/godotjs/GodotJS/commit/a4bafef9f14c103b09...

by Benjamin_Dobell

3/13/2026 at 6:51:37 AM

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.

by slopinthebag

3/13/2026 at 9:09:45 AM

It doesn't support const enum, unlike esbuild which supports them well enough to be credible.

https://github.com/oxc-project/oxc/issues/6073

by krona

3/13/2026 at 10:04:01 AM

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.

by h4ch1

3/13/2026 at 11:25:30 AM

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.

by Aldipower

3/13/2026 at 1:04:49 PM

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.

by christophilus

3/13/2026 at 12:45:42 PM

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.

by emadda

3/13/2026 at 1:50:22 PM

IIRC, esbuild is still lacking code splitting.

by silverwind

3/13/2026 at 1:53:43 PM

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

by chearon

3/13/2026 at 7:23:39 AM

> Built-in tsconfig paths support

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

by nebezb

3/13/2026 at 1:57:41 PM

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

by c-hendricks

3/13/2026 at 9:25:24 PM

I keep trying the "native" solutions every so often, but every time I quickly hit some snag that makes me question why I'm not just using the solution that actually works. As an example, I just generated a new project using create-vite & added two subpath imports:

    {
        // ...
        "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).

by Timon3

3/14/2026 at 4:11:30 AM

You need Typescript 6 for that too: https://devblogs.microsoft.com/typescript/announcing-typescr...

by arkon_hn

3/14/2026 at 6:49:12 PM

I'm confused myself. I have one project that uses package json aliased imports and TS doesn't complain. Then another where it does.

by c-hendricks

3/13/2026 at 1:58:50 PM

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.

by vite_throwaway

3/13/2026 at 2:25:18 PM

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.

by spiros

3/13/2026 at 3:25:43 PM

Thanks, I will consider this workaround later on.

Another instance is the use of rollupOptions.output.manualChunks that now has to be rewritten, maybe that would be less frustrating to fathom.

by vite_throwaway

3/13/2026 at 3:09:41 PM

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?

by iainmerrick

3/13/2026 at 3:36:07 PM

Probably. It's just that I've always used .js for my projects (decades). Such a rename would likely result in configuration changes to the other tools I use, but indeed they are better documented. When faced with a multiplicity of conventions I pick one and stick to it; the tools are flexible enough to work with it I'm sure, the real issue is of discoverability.

by vite_throwaway

3/14/2026 at 2:14:36 AM

But it’s not just convention… JSX files are not valid JS files. Also, as a programmer, I would be annoyed to open a JS file and find out it’s actually something else.

by elondaits

3/13/2026 at 3:29:45 PM

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

by ezfe

3/13/2026 at 1:43:45 PM

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

by chrisweekly

3/13/2026 at 9:02:18 AM

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.

by shunia_huang

3/14/2026 at 5:55:24 AM

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.

by Klaster_1

3/13/2026 at 9:51:11 AM

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

by throwaway290

3/13/2026 at 2:51:43 PM

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

by abrztam

3/13/2026 at 10:26:54 AM

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

by rk06

3/13/2026 at 11:34:10 AM

but it has plugin support? what kind of plugins you mean?

by throwaway290

3/13/2026 at 2:22:10 PM

look at plugin api limiation here:

https://esbuild.github.io/plugins/#svelte-plugin

esbuild's plugin support is limited which is why vite had to use rollup for prod build.

by rk06

3/13/2026 at 5:56:34 AM

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

by brandensilva

3/13/2026 at 8:48:44 AM

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.

by gdorsi

3/13/2026 at 8:36:16 AM

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

by imfing

3/13/2026 at 6:48:54 AM

I tried it and I saw more than 6x improvement in speed. It's on the top. Awesome tool 1

by verma_yatharth

3/13/2026 at 10:17:38 AM

Migrating straight away! Thank you!

by heldrida

3/13/2026 at 6:11:47 AM

Congratulations!

by pkilgore

3/13/2026 at 6:44:53 AM

holy shit - Vite 8 - rhymes in french! Did they mention that somewhere?

by hackernewsman71

3/13/2026 at 2:41:50 PM

[flagged]

by useftmly

3/13/2026 at 3:16:58 PM

That's the boat I'm in with several static sites, from tens to hundreds of pages, build on Next.js and stuck a few major versions behind because I didn't have the motivation to upgrade them. One of these days I'll roll up my sleeves and convert them to Vite, and finally be free of that awful framework.

by lioeters

3/13/2026 at 3:55:33 PM

[flagged]

by useftmly

3/13/2026 at 5:01:26 PM

[dead]

by raphaelmolly8

3/13/2026 at 8:04:43 AM

[dead]

by ptak_dev

3/13/2026 at 9:10:51 AM

[flagged]

by JulianPembroke

3/13/2026 at 7:03:35 AM

Another rewrite in Rust.

What about finally stop using node.js for server side development?

by pjmlp

3/13/2026 at 7:59:39 AM

Rust works well for toolchains where speed counts and you can control deps, but it's a much bigger ask for server-side app logic where teams lean on JS and its libraries. Switching an established stack to Rust hits hiring and maintenance friction fast, especially with async and lifetime bugs. For Vite's community, requiring plugin authors to redo everything in Rust would probably destroy most of the value users care about.

by hrmtst93837

3/13/2026 at 8:25:59 AM

It has worked perfectly fine with compiled languages until someone had the idea to use V8 outside of the browser.

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.

by pjmlp

3/13/2026 at 2:33:58 PM

> ... it's a much bigger ask for server-side app logic where teams lean on JS and its libraries.

Well that's where they went wrong.

by esafak

3/13/2026 at 7:18:33 AM

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

by vijaybritto

3/13/2026 at 7:26:33 AM

Why go halfway, embrace compiled languages in the backend.

Fast all the way down, especially when coupled with REPL tooling.

by pjmlp

3/13/2026 at 7:49:50 AM

Because writing Rust backend is needlessly complex for majority of projects.

by omnimus

3/13/2026 at 8:49:19 AM

There’s a middle ground between node and rust. Dotnet and Java are wildly productive places to work but they’re not as exciting as rust.

Also, writing JavaScript for the backend is needlessly underperforming for anything with any load.

by maccard

3/13/2026 at 8:24:29 AM

Still easier than dealing with node dependencies, webpack and co, they make me wish to write ASP with OCX components instead.

by pjmlp

3/13/2026 at 8:33:26 AM

Your complaint is with Vite – famously incredibly simple and reliable to work with – using Rust, but you're bringing up webpack's complexity?

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.

by drawfloat

3/13/2026 at 8:36:17 AM

My remark, and not complaint, is that the fashion to rewrite everything in Rust across the JavaScript ecosystem proves the point of holding it wrong.

Maybe leave JavaScript on the browser, where it belongs.

by pjmlp

3/13/2026 at 7:02:17 PM

Rewriting build time tooling to Rust is leaving Javascript on the browser?

by drawfloat

3/13/2026 at 9:20:17 PM

Somebody just really dislikes JS. I sympathize. I wouldn't (be able to) write backend in Rust though.

by omnimus

3/14/2026 at 5:57:45 AM

Why stop at tbe build tools, take JS ecosystem out of the backend.

by pjmlp

3/13/2026 at 8:14:02 AM

I've had a great time using Rust with Actix as the framework.

by potwinkle

3/13/2026 at 8:00:31 AM

It takes tooling team and discipline to keep compile times at bay when you reach mid size projects with compiled languages (looking at you Java, C++, Rust).

by wiseowise

3/13/2026 at 9:58:02 AM

But, it doesn’t need to be so. Go is pretty fast to compile. So is Jai, from what I’ve seen. So was TurboPascal. Rust has a similar problem to the one Vite has been solving- Rust (and most languages) weren’t designed for compilation speed, and it’s hard to retroactively fix that. But, there’s no reason we shouldn’t have a bunch of statically typed, fast-to-compile languages.

by christophilus

3/13/2026 at 10:08:10 AM

I agree with your remark, only that Rust's current problem is tooling, not the language itself.

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.

by pjmlp

3/13/2026 at 8:25:17 AM

Lack of discipline is exactly the magic word regardig the node ecosystem mess.

by pjmlp

3/13/2026 at 9:43:47 AM

Maybe? The point still stands that majority of programmers/industry is not equipped to deal with this adequately.

by wiseowise

3/13/2026 at 8:51:55 AM

I’m with you. It’s very telling when all of the tools are being rewritten and seeing orders of magnitudes of speed ups.

It just shows that people don’t value the actual performance of what they’re running.

by maccard

3/13/2026 at 7:51:24 AM

Node as a compiler runtime or node as a runtime runtime?

by CodeCompost

3/13/2026 at 8:26:17 AM

Anything backend related.

by pjmlp

3/13/2026 at 8:53:11 AM

isnt that what projects like bun are aiming to do?

by mmusc