Vite+ – Unified toolchain for the web
viteplus.dev
viteplus.dev
Bun is also attempting it. Thye have made tremendous progress but they are also competing against node, and thus I don't expect to for bun to go mainstream.
However, despite the difficulties, I strongly believe that Vite+ can achieve it.
I strongly recommend all readers here to watch Vite documentary[0] that got released less than a day ago for vite's history and bacground of Vite+
The sestertius isn't what it used to be.
It was also unfortunately timed. When they started they were competing against webpack, but right around the start of the project compilers written in more performant languages like ESBuld and SWC start to take off and out compete Rome before it even got off the ground.
Even Vite+ is focused on vite and rolldown first, and formatter last.
But when SWC/Esbuild came around to prove how much faster and efficient the compilation can be when written in a more performant language like Rust or Go, all hype around Rome died because no one wanted another Javascript toolchain.
Turbopack is backed by Vercel who obviously have a lot more capital behind them, but it's also built on Rust and at least has the potential to compete.
A big "Request early access" followed by a contact form at the top of the landing page is an instant redflag of vendor locking, who would ever want that?
Eventually you'll need to migrate away or cough up serious money. So yeah, not sure who'd go for this.
Mind you we use NX at the moment and that was quick and easy enough to set up with no major issues for years now, so I wonder what the USP of this tool is. We also use Vite in some projects in combination with NX so maybe this is mainly aimed at that.
I'm concerned that it erodes trust into vite and makes all the other open source maintainers contributing to /the commons/ asking some questions.
There is nothing really special about vite too. It's important, sure, but there is a lot of important open source projects that also need funding. Can all of them pull the same trick?
Are you affiliated with this project? Based on your comment history, you seem to be
As for why? some people have very large codebase and prefers their developers to have better UX and are willing to pay for it. lower CI/CD server costs also directly translate to cost savings if you are Replit or stackblitz,
You may not like it, and that is ok. as individual developers are already benefitting from vite. and will get rolldown soon.
92 requests 22.6 MB transferred 25.2 MB resources Finish: 9.54 s DOMContentLoaded: 290 ms Load: 9.50 s
at least the page is a work of art
1. This is a Vite rugpull, right?
2. What the hell do I migrate to to avoid the rugpull, now?
Lots of stuff builds on top of Vite, and this is an incredibly bad move from the Vite people.
Voidzero Inc owns the Vite trademark:
https://tsdr.uspto.gov/#caseNumber=98845059&caseSearchType=U...
2. Nothing because Vite is OSS and this is something extra on top for managing everything else people usually use on a project.
Did you watch the keynote from the conference today? The conference attended by all the people who you see as great contributors to the Vite project?
They want this. This is good for the ecosystem to maintain funding as a whole.
I did not watch any keynote and frankly place exactly 0% faith in the words of the people behind this move. The rugpulls we have seen so far have all been shady business moves mostly by dishonest people, so that is my expectation.
It's like every acquisition ever, they say nice words at the time it happens, reality unfolds later: https://ourincrediblejourney.tumblr.com/
I see nothing here but yet another Open Core project that will be utterly irrelevant in 1-3 years.
Before Vite+, we maintain Vite, Rolldown, Oxc, all of which are open source and widely used. These remain open source - nothing changes about existing projects.
Vite+ is an entirely new product built on top of our own open source, with additional features that are entirely new. You don't need to use Vite+. You can keep using all the open source that we already provide.
The revenue generated from Vite+ flows back into the development of both its proprietary features the underlying OSS. So if you are a user of our OSS, you'd benefit from Vite+ even if you don't use it, because it allows us to keep improving the OSS you are using.
Companies willing to pay for Vite+ help sustain and improve the open source parts powering it, including Vite. Even if you only use Vite and not Vite+, you’d benefit from the success of Vite+, not the other way around.
I don’t really find anything inherently wrong with your definition of “rugpull”. If some people in the community are happy to pay for it and the rest also benefit because of it, that’s a win-win in my book.
Best of luck with your commercial project. History has not been kind to open core projects.
The first and most important distinction is obviously which ecosystem you are more familiar / invested in (webpack vs. vite). It does make sense for projects deeply coupled to webpack to consider rspack first.
Putting that aside:
- Vite+ is a commercial offering with a company that can provide paid support. Rstack is a big corp by-product where their primary customers are internal teams.
- The Vite ecosystem provides way more options in choice of meta frameworks (Nuxt, Astro, React Router, Tanstack Start, SvelteKit, SolidStart...), and 3rd party tooling integrations
- While both written in Rust, our tools in general perform significantly better than rstack. With the upcoming full bundle mode, Vite 8 will be at least 2x faster than rsbuild across all categories (dev server start up, HMR, production build)
- Vitest and Oxlint are mature and widely used in production. rstest and rslint are both quite new and not even feature complete.
One approach is to setup consulting services. Looks like Void Zero's approach is to start building value-add tools and features on top of Vite that are no longer free.
The decision that users must make now is whether it's worth the risk investing in Vite, assuming that more and more functionality will move to the paid tier.
All functionality as part of OSS projects will stay there. OSS projects such as Vite, Vitest, Rolldown and Oxc will stay open source.
Eventually, the (financial) success of Vite+ is directly tied to the health, stability, and adoption of the free, open-source Vite ecosystem, so the incentive is rather low.
As far as Astral goes, so far they've distributed all the tooling separately but it seems they might be going towards consolidation as well.
Vite: The Documentary https://www.youtube.com/watch?v=bmWQqAKLgT4
Please list the prices.
previously (i.e. before current viteconf), Evan had said that existing OSS (vite and below) will remain OSS. only newer tooling will be monetised
If anything, FE tooling starts looking like it moves to more sane place. Also Anthony Fu is cool
Me personally -- I would rather see it staying fully opensource and be funded through open collective or EU grants or something, like a lot of core stuff should. The fact this model doesn't work is sad.
I feel that something that the whole FE community gravitates to converge on should stay that way to prevent rag pulls and license dramas, otherwise it sabotages the process of converging on the same set of tools in the first place. Then the whole work will be wasted and eventually the project will die out and we get back to the same mess.
That being said, I get that the problem they are aiming to solve is a big pain point and whoever solves it -- they deserve money, but don't deserve to keep the whole community hostage to their whims indefinitely.
Then again, if people can pay 20 bucks a month for oracle lottery tickets selling infinite wisdom one token at time, why not pay actually helpful people doing great tools.
This is not good news.
Vite already has rolldown support in the current version, it's just in alpha/test stage.
https://vite.dev/guide/rolldown.html#how-to-try-rolldown
Nothing is keeping them to this plan other though, I hope they do follow through. That would make the graph on the page misleading in the other direction though as the speed feature would be included in the non plus version.
I want to also say I'm a happy vite user (and the other projects that team makes).
I would love more information about this feature! Bad line-wrapping is the reason I loathe Prettier.
Hopefully Evan can pull this off and we have simpler initial setup.
Vite+ is a tool similar to Rust Cargo or Go's toolchain that handles building (via Vite), testing, linting and formatting.
Ah, great, another Javascript tooling stack! Let's jump on board! I'll get straight to configuring, replacing and patching as soon as possible. Or maybe let's just don't. I'm tired, Boss.
The current dominant toolchain has been very stable for years now, and is much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc.
The only problem is that NOW there are too many separate different tools that aren't bundlers, so in addition to Vite one also has to configure Prettier, Eslint, Vitest, Typescript, Husky, Lint-Staged, Playwright, DotEnv, what else?
A unified toolchain might not replace each and every tool above, but it will simplify a lot of this process.
It will also simplify migrating between tools that it doesn't intend to replace, like migrating between Typescript and Typescript-Go. Etc.
This is already the reality in Go, Rust and other languages.
"Vite+ will be source-available and offers a generous free tier."
I'm also a developer ( sometimes ) and we need to eat. However, for me these tools are too low of a level of he stack to monetize, so I'll probably stick with my collection of free tools.
Every for-profit is subject to being sold to someone with different plans. If the license is not fully open, it's not smart to expect the licensing terms to get worse.
I remember gulp/grunt saga, I remember webpack 5 saga and the most recent pain with eslint 8 → 9 is a final nail in the coffin of anything stable for web building.
The only two tools I like in the JS world is `yarn` and `prettier`. They're focused and do what they do well. But you add eslint and any of the others and their configuration is a full fledged turing machine. Even autotools feels nice in comparison to that mayhem.
I agree that ESLint can become a mess, which is why I'm ok with a new competitor that doesn't require the extra configuration. Sure: they're also replacing Prettier (unnecessary) but everyone can keep using Prettier and change if Oxfmt ever becomes better.
All the other tools here are either existing, or drop-in replacements.
The current version of webpack was released 5 years ago. You can keep using eslint 8 which was released 4 years ago. This really isn’t the constantly changing space it was in the 2010’s
You will certainly be able to compile it. You might have hard time updating it though.
Updating is a different matter, if you're using multiple tools, hundreds of packages and several configuration files.
Which is why a unified tool that doesn't require configuring 20 tools at once is a good idea IMO.
This is like the comment version of the gish gallop.
And I gave three other examples, and I can give others: React itself has been around for 12 years, leading. Vue has been super stable too.
Migrating versions of frameworks is several magnitudes harder than migrating the ESLint config, and ESLint is optional. Migrating versions of previous tooling like Babel or Webpack is several orders of magnitude more complicated than ESLint.
Sure it would be better if people had gotten it right the first time, but the fatigue problem isn't really due to React.
And my argument isn't that "X is better than Y". It's that the number of new tools showing up is WAY smaller than it was when those complaints started. Today it has become a meme here in HN, often by people outside the frontend community.
But now there’s no unifying principles behind anything. No conventions. It’s just incantations to get thing working nicely together. It’s all preprocessing and post processing, code generation an what not.
Everything else is smooth and silk
Ohh, yes eslint 8 => 9 migration were also a big pain to handle.
Still not resolved. Their main recommended config is still not updated for 9.
Like, their decision to change configuration format in a way that breaks all and every plugin, tutorial, project in existence as a giant "fuck you" to the whole ecosystem and all web developers of the world - isn't that a reason good enough to never come back at this tool ever again?
It wasn't there X years ago and had changes to the config Y years ago that were very annoying time-consuming. One can believe that single digits of X and Y are "not stable enough" with a simple reason that you live in Decenarian Math.
For all its warts and all the hate that it gets, at least autotools is stable and not introducing breaking changes.
What? That mess is still ongoing. Next.js for example (probably the most popular "out of the box" solution) technically uses SWC, but not quite, because it doesn't support `styled-components` so you need to use Babel for that. But wait, you might also need to use tailwind, and for that you'll need `postcss` which might also work with Babel with `babel-plugin-import-postcss` but not necessarily, could also just use it as a Next plugin, but that doesn't always[1] seem to work.
I don't think this mess will ever end unless we throw React/Vue, and all "reactive" frameworks in the dustbin and we'll get enough folks on board to re-invent the web starting from scratch. But no one really wants to do that (yet?), so even things like Bun or Deno will try to be as compatible as possible making continuous concessions that will lead to the ongoing spaghettification of toolchains.
In the C world, most tools are orthogonal. The compilers don't need to know about the design of the package managers and the task runners don't care about either. Yes, we have glue tooling, but that is also and external project and the dependencies are interfaces instead of monkey-patching each other.
This less a problem when your project is on the web though, because vite (and I think under the hood esbuild) transforms the imports gracefully.
You do know that Vite uses a lot of these behind the scenes right? Vite in general has much better defaults so that you don't have to configure them most of the time, but anything a bit out of the box will still require messing with the configs extensively.
Not like OPs Vite+ changes anything regarding that.
It used Rollup.
And it does so transparently, while the alternative, Rolldown, was being finished.
To me this sounds like a more than acceptable compromise in the interim.
Didn't have to touch the webpack stuff either. Perhaps the issues you're having are due to something else?
Why should it even be your problem.
For NextJS, do you remember the runtime used for middlewares? What was this swc thing again?
It never ends. Every year new things are added and they never really replace anything, it's just one more thing to learn and maintain.
If every technology causes exactly 1 issue per week then you quickly spend 50% of your time fixing bugs that have absolutely zero to do with what your company is actually doing.
---- EDIT
And it doesn't even stop at issues. Every one of those technologies regularly goes through breaking changes. In the process, plugins are deprecated, new ones have completely different APIs. You want to upgrade one thing for a security fix, then you're forced to upgrade 10 other things and it spirals out of control and you've spent entire work days just sifting through change logs to change `excludeFile` to `excludedFile` to `includeGlob` to `fileFilter` to `streamBouncer` to I don't know what.
Opening up iOS or macOS app source code I haven't touched in years in the latest Xcode I just downloaded is a lot like that. There is anything from Swift errors to API changes to my build plist being invalid. And if I use any third-party tools, they probably don't work until I visit each one's latest readme.
And that's without even insisting on using the latest unstable tech (bun, biome, nextjs) like you did in your comment where you would expect that experience.
Because of Vite, there was a total of ZERO work from my side involved in changing from Rollup to Rolldown, or from babel to Esbuild to SWC.
The Rust/Go/uv model is the one to go. This is ONE step in this direction.
I haven't experienced nearly as much brittle build and dev tooling with other ecosystems, PHP or Python for example. Sure, they have their warts and problems and their fair amount of churn. But the sheer amount of JS tool and framework churn I experienced over the last few years was insane.
It might have cooled down somewhat by now, but I'm burned out. So reading about more churn to fix the churn just rubbed me the wrong way.
But many projects won't adopt it. There are so many competitors all with their own little ecosystems. So in the end, I'll still have to fix all the issues I fix right now PLUS the issues that Vite+ will add on its own.
The only chance I see for something like this actually working is if something like Node/NPM decided to add a default formatter, linter, and so on.
When these cynical takes were crafted, Angular, AngularJS, Aurelia, Backbone, Ember, Knockout, React and Vue were all competing for mindshare, with new members joining/leaving that group every month (anyone remember OJ.js and Google FOAM?) being compiled by traceur, 6to5, the Google Closure Compiler and others from (Iced) CoffeeScript, TypeScript, ES6, Atscript, Livescript and Closurescript. We had two fucking major package registries (npm and bower) for literally no reason and we’d use both in every project. We had like 4 ways of doing modules.
Today the stack has stabilized around React and Vue, with a couple perennial challengers like Suede in the background. Vite and Webpack have been the two main build toolchains for years now. We discarded all of those languages except for TypeScript (and new ES features if you want them, but there are fewer changes every year). There are a couple package management tools, but they’re cross-compatible-ish and all pull from the same registry.
So does the fact that it’s not NEARLY as bad as it was in 2015 mean that people in 2025 aren’t allowed to complain? Yes. Yes it does.
But just in the repos at work I deal with: yarn, npm, pnpm, bun, NextJS, biome, Prettier, ESlint, Vite, Vitest, Jest, Turbopack and esbuild. At least those are the things I remember right now. They all have their idiosyncracies and issues. They all require learning slightly different configs. Nothing is compatible with anything else. I can't take one library and `npm link` it into another because their toolchains are completely different. Then you have the whole topic of exporting TS vs. JS, different module types, module resolution, custom module resolution rules to accomodate for how some outdated plugin somewhere works.
And this really is just the tip of the iceberg.
I wish these folks the best and I hope I'm wrong and in a few years all of this is replaced by `vite lint` and `vite build`. But my past experience tells me that I'll simple add one more word to this list.
No, it doesn't mean people in 2025 can't complain. Hype based noise that gets in the way of people doing good work should be decried even if someone else somewhere (or somewhen) has it bad too.
This isn't a competition of badness.
Gates open. Come on in!
And as I wrote in another reply: of course other technologies are not without issues and have their churn and warts and problems, but the sheer amount of JS hype and tool and framework churn I experienced over the last few years was insane.
It might have cooled down somewhat by now, but I'm burned out. So reading about more churn to fix the churn just rubbed me the wrong way.
Especially eslint with their decision to change configuration format in a way that breaks all and every plugin, tutorial, project in existence as a giant "fuck you" to the whole ecosystem and all web developers of the world.
Jesus, it's bad enough I can't leave a js project for 6 months without it starting to rot. Now my cynicism has to be updated too?
Vite is basically replicating what one would expect as normal behaviour from the JDK + IDE has been doing since years. Javascript was meant to be readable for an open web, nowadays it is compiled into a puddle of text.
It is OK to reinvent the wheel, it just doesn't look much better than the old one.
Works great.
But the requirements of "modern" software are always changing. Sure, the static table might be enough, but then some business person says, "It sure would be nice if I could check a little box in the table row or assign this user here..." and now you're adding little JS hacks. Again, not impossible, but at a certain scale, the ability to have infinite access to client driven reactivity becomes a real business empowerment.
Given the interest in the JS working group to add reactive Signals to the core language, I suspect this will only become _more_ prevalent in the future. Maybe it will need less input from frameworks to do the same work and we can move back towards using built-in browser APIs, but the programming model itself works really well (so much so that SwiftUI uses a very similar reactive UI programming model).
Again, I don't disagree with your point, just at a certain scale, it becomes a huge hassle to maintain. If people are going to use these tools and frameworks anyway, it helps the entire web to make them more efficient.
I have this set-up where .NET ViewHelper would do `RenderReactComponent('complexTableComponent', '.complex-table-component')` and it would load bundled react as 1st script and then this component as second script. If page does not need no react components it does not load any. If you have more than one it will still load the react itself only once. It is really amazingly working very, very well.
And yes, if I would to build some kind of dashboard/email client or something I would say use React or Angular and API. But for regular website rendered HTML is king.
It is so different when compared to Java/.NET where organizing large code blocks and making sure the pieces work well together is so easy. Very frustrating as there is so much that can be done on a browser but hampered by a development environment not much different from only using a text editor.
It pains me that so many SaaS go for Next.js based SDKs, but at least it is the closest to Spring/Quarkus/ASP.NET in spirit.
Hot take but: it took 20 years for Next.js to catch up to 10% of WebForms offered.
But if people want whatever Next.js offers to build their copycat SaaS with shadcn/ui, so who am I to argue.
Productivity is now wasted trying to make sure that buttons work when pressed or scratching the heads why box is not aligned with another programatically.
You mean many developers want. Actual customers, the ones who pay for your work don't even know what Next.js is and are extremely happy with whatever works. The hard part is to sell the idea that - no, next.js is not the best for your SEO heavy website :)
I’ve been in situations where a non-technical founder asked me to use Angular just to fit in.
With technology becoming about trends, clueless founders more and more are pushing for certain technologies.
Recruitment and developers just follow.