I am a big fan of Vite. But I have zero clue what those other tools are. I swear to God, I just put my head down to do some work and all the sudden, frontend tooling has evolved. I wonder if there is a push towards a "boring but works" stack.
> But I have zero clue what those other tools are.
The incorporated tools are actually really amazing:
- vitest, an ultra fast test runner. After using a lot of others, including jest and node's built in one, I love vitest.
- oxlint, replaces eslint but is compatible with its file format and ultra fast, since it isn't written JavaScript. I tried biome, but I found oxlint to have more rules and the eslint compatibility was nice.
- oxfmt, replaces prettier and is faster since it isn't written in JavaScript.
- rolldown, replaces rollup and is compatible with it but it is much faster since it isn't written in JavaScript.
The above are my go-tos in new projects anyhow since they are killer good and fast.
At work we've tried switching to vitest, and it's 1.5-2x slower than Jest (I think it's related to our very large and circular module graph), so performance is very much a your-mileage-may-vary thing.
The initial selling point was performance, but then they gradually realized that a lot of the slow cruft in Jest was necessary for correctness, and now it's about the same performance as Jest (obviously may vary in some specific situation).
However vitest is still great! Selling points now are stuff like:
- shares config with vite
- works with ESM out of the box (I think Jest still doesn't)
- integrated browser testing mode that is very nice
- overall just has a ton of nicely integrated features
I do recommend turning off "isolate" for as much of your code base as possible when it makes sense. And I recommend ensuring "maxWorkers" is being used properly, I prefer something like 60% of my totals cores as the number of workers to use. And use a top level vitest start so it properly runs all the packages in a pipeline rather than as separate vitest runs (which would mess up the maxWorkers optimization anyhow.)
I have my 3000 test project suite completing in 15 seconds on my MacBook Air M3. It is pretty sweet with that setup.
I wish Oxfmt supported plugins. Prettier's plugin API is one of the worst APIs I've ever worked with. I'm eager to switch to a different formatter with a better plugin API (and I need plugins).
I was hoping for something more flexible. I suppose the whole point of Prettier is that it's not flexible but I find 90% of the times the code is actually uglier when using it.
> Vite, Vitest, Rolldown, tsdown, Oxlint, and Oxfmt
You already use the first, the second you should be using and has existed for years - it's a jest-compatible runner integrated to Vite.
Rolldown is a part of Vite already (since version 8, alongside other implementing tools like lightnincss).
The ox* suite are native replacements for eslint and prettier. The latter has existed for years. Both of them aim to be drop-in compatible soon.
This is a boring stack.
FWIR, prior to the purchase by Vercel (or was it Cloud flare?), Vite+ was going to be a convenient, no fuss, low movement way set up projects that they sold to businesses for funding.
I think the boring stack would skip the need for most of these.
That is 5 different tools to write TypeScript in order to get some HTML, CSS and JavaScript for things that are not covered by modern web standards. Not including the frameworks itself which mostly have the same goal.
That's a pretty disingenuous take on the purpose of TS and misses the point of having a stack in general. The tools actually cover a lot more than that.
Yes, if your goal is to get HTML/CSS/JS in any form to a web client then you don't need this stuff.
If your goal is to ship a web app that stands a chance of surviving multiple devs, production traffic, etc then you need more tools. Testing behavior (vitest), enforcing code standards (oxfmt and oxlint), optimizing network calls (e.g. tree shaking from Rollup), etc. all go beyond what you describe.
This stack is as boring as it gets without literally using the tools it consolidates and replaces or dropping a requirement that necessitates them.
the other tools are for testing, bundling, linting and formatting. Previously you would use different tools from very different open source projects for these things, with different configurations, update cycles etc. Now it's all covered by one simple toolchain. Vite+ is basically the "boring but works" stack, while also being more performant and with less configuration required.
Okay, then how can something become boring? It needs to start as the new hotness? Does that imply that the people who use non-boring software are the ones who determine which things get to graduate to being boring?
Unfortunately, yes. It's a backward looking metric, like how economists can only call a recession/depression after it's been X months of bad metrics, even if everyone living in the first month of one feels the economy going poorly. We'll only know if these tools are "boring but work" at some point in the future.
The hope is always that "this time will be different". Maybe these tools are so awesome that they'll become a de facto standard and, therefore, "boring". It's JavaScript, so I'm not holding my breath, though.
A "push" towards a boring stack? That won't happen because the hype cycle trends towards new tools like water down a river. But if you're looking, I can't recommend Rails enough in 2026. Built on web standards, it's quietly pushing the framework forward and is so much less maintenance than modern JS apps.
I use oxfmt and oxlint, the first JS linter I've used. For a long time, I avoided Eslint due to how strict it was, but even though oxlint uses eslint, I've been ok using it. I haven't used vitest before though.
And I think Webpack should be discontinued by now, because Vite has replaced it in every way. Maybe to get other projects to switch, they should make a Webpack-to-Vite migration script.
I'm currently experimenting with a stack combining assistance, ASP.NET Razor Pages, and htmx, specifically to avoid dealing with the complexities of the modern frontend stack.
AI eliminates a lot of the tedium, grinding tasks, while HTML partials and htmx complement each other perfectly.
Not having to manage frontend framework, SSR states is incredibly liberating. Sprinkle in some vanillla js and redraw specific parts of the page as needed... done
I guess I'm just an old man pumping my fist and yelling at the clouds at this point, but I think compartmentalizing every possible aspect of development and then making each one of those as complex as possible lead AI in the bureaucratic deterioration of the trade.
Fear not, engineer! Recently some smart folks invented something called BackRub that’ll soon solve all your problems! Soon you’ll be able to find information in even less than time than it takes you to type a comment and out yourself as clueless!
I love Vite, Vitest, Oxlint and Oxfmt and look in their direction for most of my new projects! I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade.
Sure beats opening some ancient project and seeing some mix of Gulp, Grunt, webpack and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).
> I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade.
I believe VoidZero has been acquired by Cloudflare [1], so money should not be an issue. Question is if Cloudflare will be willing to continue letting these people work on Vite and Vite+ features that benefit all cloud platforms, not just Cloudflare.
Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR.
If you only focus on the front-end and remove Typescript from the equation it becomes easy enough. We'll have to see if Vite+ helps for the more complex cases.
Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR.
Although about 98%* of that is because ESLint keeps making breaking changes and getting everything else to work compatibly with ESLint requires 27,573* additional dependencies.
Things I work on have been moving over to Biome recently (mostly these are Vue projects rather than React these days) for formatting and linting and it's so much simpler and avoids all the "What ESLint-related package broke our build process this week?" discussions entirely.
*Some numbers here may be made up. Or they might not.
Lots of breaking changes but I like where they landed, the config file is now clearly an mjs, no longer a hidden file, allows JSX without a plugin. I reckon the best way to upgrade is to generate a new project that has everything configured and copy that and stay close to defaults unless there's a good reason not to.
> Sure beats opening some ancient project and seeing some mix of Vite, Vitest, Oxlint and Oxfmt and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).
I mean if I see those in N years, I'll be happier than with the older stack that came before them - the jank levels seem to generally be decreasing with every next attempt to get things right!
Vite had five major version in the four years 2022-2026. Version 3 => 4 => 5 => 6 => 7 => 8. Each one of those had breaking changes and required devs to go through a migration. It's too much. And for what? It's not as if it is dramatically better now than it was in version 3.
I can't say I would really look forward to bringing this level of needless churn and constant disruption to the rest of my development toolchain. Anyway, Vite+ is really just wrapping existing tools into an abstracted command-line interface? And so I have more layers of indirection to wade through in order to get the thing to do what I want? So far I am not optimistic about this prospect...
I've followed all the main migrations and I've say they where really quite smooth, can't remember having any major issues and each time it tended to be worth it.
I did the migrations and they were not horrible. A few breaking changes but they were relatively isolated. And the speed and improvements over these versions had been quite significant.
All those APIs at that point were marked as experimental, and this is the place where things were ironed out. Churn should be expected when using an experimental API.
SSR is a huge pain in the ass. Now it starts to be hard to have all of that do the frontend properly and let good appropriate languages take care of the backend.
Instead of a stupid, broken and leaky node equivalent backend totally interlocked with code of the frontend.
The major change through all of those was solidifying Vite's concepts of "environments" for better SSR support. If you weren't using that, there wasn't much instability.
Surely lacking features also creates demand for more tooling.
Did very little changes to tsconfig during past 6 months adoption
My day-to-day process - get the new package unless it some antd6, echart or some rendering engine or geo spatial lib, clean up with Claude, strict and unify type system and align it with my vite, tsconfig, oxlint tastes. The result - no need to follow libs bloat and supply chain attack issues. Easy to read, easy to fix.
I think they should find a better name for this project. I find it very confusing since it's not really a better Vite.
At the time Void Zero was probably looking to monetize the Vite brand but now that they've been acquired by Cloudflare they don't need to do that anymore.
Because VILT is dead and Livewire is now on version 1100?
I've worked on both stacks in the last few years across several clients. Honestly like with anything in tech it seems to mostly fall apart with half-regarded usage of the tools in growing teams that don't care about their quality in favour of "get ticket done".
Yeah, not only the name: they’re also going with various semiotic signs that are strongly associated with a subscription service, including their website design, choice of typography, and even the press release–style copy.
Looks like they have been acquired by Cloudflare, and pivoted to fully open source, but they haven’t really tweaked their messaging to make that fully land with unsuspecting visitors.
It’s kinda like the reverse situation of open source projects that switch to a source available license, but keep the aesthetics of an open source project. Kinda funny!
uv removes all the pain from python packaging. and if you ever used it for anything more than one off scripts you know it used to be a lot of pain.
manually activating venv, inconsistent python and dep versions, duplicate files taking up space, slow and broken tools, fragmented configs, global state, all of that is gone now. if you never experienced it you have no idea how bad it was.
not all of it was uv specifically (pyproject.toml was a proposal for some time before) but they cleaned it up. its the only reason i even think about python as an option for new projects.
Seen this play out again and again: a tool becomes popular, starts incorporating other tools, including mananging language runtime versions. It wants to become the entire platform, to do everything with this one tool. After people get hooked and adapt their workflows to depend on it, inevitably it starts to enshittify. Repeat cycle with new tool.
In my experience the bundling isn’t really the important aspect (though it also doesn’t harm anything), it’s more just having an ecosystem of plugins for code transpiling, static asset inclusion (e.g. text files) etc and a configuration format folks are already used to.
Running typescript without compilation is still tricky with plain Node. `vite dev` has amazing DX not available for Node programs. I'm wondering if Vite+ tackles this problem.
Don't we have `tsx` and `nodemon` (or the native Node reloader) for that? What are the DX gaps you see on the server side out of on-the-fly transpilation and reload on watch?
Yes, I use tsx for Node programs. It's not great when sharing the same codebase for both client and server code, they have completely different dev workflows.
One advantage of precompilation is risk reduction. Say tsx gets hacked somehow (hardly unprecedented with Node modules!) you’ve got it running on your production server exposed to the internet. Precompilation on a CI pipeline is still a risk but a significantly lower one.
In theory, typescript doesn't need to be transpiled, you can run ts files using `node --experimental-strip-types file.ts` as long as you don't use any code that needs transpilation (like typescript enums).
No, because of ESM import resolution rules. Typescript suggests extensionless imports, making it incompartible with ESM and therefore Node. Luckly, `node --import=tsx file.ts` handles imports well.
This is especially hairy when making a typescript library that is distributed non-compiled (without dist/) and is supposed to run in both browser and Node.
This allows you to use fully-specified imports in TypeScript files, which works basically everywhere — NodeJS, TypeScript, bundlers, etc.
The exceptions are browsers (obviously, only normal JS syntax there), and packages inside `node_modules`, which NodeJS will not do any type stripping for. So if you're writing a library, you'll probably still need to distribute the compiled sources, rather than distributing the raw TypeScript files alone. Or you use the JSDoc syntax for TypeScript, which can do everything that .ts files can do, but is more verbose and idiosyncratic.
I transpile for prod, but use --strip-types when running in dev, and all I had to do was to make a 10-line ESM register hook that rewrites .js to .ts if the .js import fails, and then a one-liner import register trampoline script. Not sure I'd do that in prod, but works fine in dev at least.
This way I could just use node --watch instead of tsx or nodemon.
For me, the main benefit is deployment bundle/artifact size reduction. Mostly from dropping unneeded files from node_modules. Many packages include both esm and cjs builds, sources, docs, TS types, etc. stuff that you don’t need in prod.
This matters for lambdas, for example, because deployed code size has limits there.
In my case, for my fullstack framework, I used vite on the server to add my own vite plugin, which can cut client-only code from server code. But it was really needed only when I use my framework with Vite. For example, if we use it with a clean bun setup, then I can do it with bun runtime plugins, which also allow me to modify code on the fly and do it really faster than vite. So I want to say that in server js code we may use vite to modify code during the dev/build process, and I have no idea what else we can use vite for in server/cli code
In cases where startup time matters and you have a slow disk, bundling can drastically reduce the number of filesystem calls you have to make for large dependency graphs.
I’ve found if you want interop ts esm and js cjs you need to compile your code - and then `tsc` doesn’t bundle your dependencies for you and outputs incomplete code.
That "+" is making me really nervous. Is this just a naming quirk, or the start of them trying to monetize Vite? If the latter, this is a dark day for frontend dev.
> Is this just a naming quirk, or the start of them trying to monetize Vite?
VoidZero got acquired by Cloudflare, which gives out insane amounts of free services, I'd be very surprised if vite is the place they try start pinching pennies.
This is just what modern languages have out of box. (Like rust and go.) it’s a true shame that web isn’t actually unified behind a type safe language with a single solid toolchain. It’s a huge pain to manage and I’m curious how much money it’s cost the industry. “Vite+” isn’t a true solution to that. There are many competing toolchains. And no default standardized one.
I'm not very familiar with Rust, but doesn't cargo pull a lot of external dependencies for most projects? I really like how Go can do everything with just the standard library, but I wasn't aware Rust was similar. For typescript we've moved our stuff to bun. It has it's own risk management perspective compared to node, but at least it's now possible to build web services without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them.
Cargo itself doesn't pull the dependencies, but yes to Rust's standard library being much more lean than Go. Bring your own HTTP, text templating, and such, but core data structures are provided.
Go gives you a bunch of goodies in the standard library.
Rust provides things like your build system, testing, and package management all together, which is what I assume OP meant.
> without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them.
How about the dependencies Bun is pulling? How did you ever managed to pass security policies with Bun which has so many segfaults that nobody even bothers to write CVEs for them.
> a type safe language with a single solid toolchain
Been paying the bills for 5.5 years now writing in one that gets a fair amount of stick for being ~6.7 years with no language version releases (one is planned for this summer though that should make it just under 7). There's one compiler, one standard library, one formatter (with no config options), one linter, and two test runners but one is a rust rewrite of the other one so it's chill. The language being on a timeout has led to all kinds of things like compilers for native (consuming the intermediate representation .o files), fullstack un-forks (no change to syntax of language), fullstack actual forks, really a lot of weird but delightful activity.
It's like me and a few hundred other people, so "unified" is the part that's missing, haha.
Vite+ isn't a layer, it's "just" a high-performance suite of excellent tools that work well together to provide a great DX for developers.
Vite+ can improve and simplify what developers are already doing with ad-hoc collections of tools. Vite is already an industry standard, and Vite+ has a good chance of achieving that status as well.
I have been doing "modern web" things since essentially day zero (you kids with your fancy JIT compiled javascript interpreters!)
SvelteKit, and by extension, Vite, has been the single most productive webstack I have ever used. If this offers anything on top of that, I welcome it with open arms.
Some barbarian without a grasp of the Dutch language knee-jerked the down-vote button so I'll add a Swedish version which adds an important attribute.
Imse vimse spindel klättra upp för trå'n.
Ner faller regnet, spolar spindeln bort.
Upp stiger solen, torkar bort allt regn.
Imse vimse spindel klättrar upp igen.
Here's how to interpret this saga of the ever-climbing little spider in the context of web development. It climbs up its tread (klättra upp för trå'n) 'cause that new framework will sure make catching those flies (clicks/jobs/likes/whatevers) easier. And then the rain starts (the CVEs start piling up, the corrupted packages come flooding in) and the hapless spider gets thrown off its web (Pwned!) until the sun comes back and dries away the rain (a new framework, yay, this will solve all problems) upon which the spider climbs up its thread again.
I think web development does not need that many layers. Usually there is a clear purpose for each layer. I think most problems in web are self-created.
It's all great to leverage until something breaks in a middle layer and you can't reproduce without submitting your entire project in the GitHub issue.
Is everyone project so simple that it can fit in these "vp check" / "vp dev" commands? Like even for my amateurish web app, I have a custom web server with a self-signed certificate with an "/etc/hosts" domain; and for checks I need to do custom checks for GraphQL and a couple of cloned NPM packages.
I have removed vite because dev build and reload is noticable slower than just esbuild and browser refresh. Vite does nothing for me that an LLM can not just trivially rebuild in a bespoke manner.
I am actually pushing our frontend devs to remove more and more dependencies and leverage LLMs to just write the code instead of all the dumbass packages in hellscape of supply chain attacks via node/npm.
You are signing up for another hellscape of unmaintainable slop. Enable package cooldowns and only whitelist internal packages and you are better off than 90%
"Unmaintanable" by who? Vite is on its n-th major revision, yet as a user none of my pain points have been addressed and god-knows-what has been added. If that's "maintenance", I don't want it, because what I need out of Vite is trivially replaced. It's the same for most other dependencies. I need a particularly problem solved, but along with a dependency come the authors who, having solved the problem, continue to invent new problems, because they are emotionally invested in their work. I don't begrudge that, but there is a conflict of interest here.
You act like the existing packages being published in this ecosystem aren’t already slop or quickly getting there.
We already do cooldowns and disable preinstall and postinstall scripts on all packages except for ones that actually require it.
I bet if you looked at 70% of your dependencies pulled in, you would be horrified. I would rather have that capabilities via code in my repos at this point.
How do you bundle web workers that import dependencies? iirc the issue in esbuild for that is still open and users are manually building their workers as separate entry points, which is very fragile.
I build them as separate entry points. And to be clear, esbuild doesn't do everything for me, but the solution is bespoke script, not the whole of something like Vite.
I am a big fan of Vite. But I have zero clue what those other tools are. I swear to God, I just put my head down to do some work and all the sudden, frontend tooling has evolved. I wonder if there is a push towards a "boring but works" stack.
> But I have zero clue what those other tools are.
The incorporated tools are actually really amazing:
- vitest, an ultra fast test runner. After using a lot of others, including jest and node's built in one, I love vitest.
- oxlint, replaces eslint but is compatible with its file format and ultra fast, since it isn't written JavaScript. I tried biome, but I found oxlint to have more rules and the eslint compatibility was nice.
- oxfmt, replaces prettier and is faster since it isn't written in JavaScript.
- rolldown, replaces rollup and is compatible with it but it is much faster since it isn't written in JavaScript.
The above are my go-tos in new projects anyhow since they are killer good and fast.
I don't get how a test runner can be "ultra fast". Surely all the time is taken by the tests, not calling the test functions?
At work we've tried switching to vitest, and it's 1.5-2x slower than Jest (I think it's related to our very large and circular module graph), so performance is very much a your-mileage-may-vary thing.
The initial selling point was performance, but then they gradually realized that a lot of the slow cruft in Jest was necessary for correctness, and now it's about the same performance as Jest (obviously may vary in some specific situation).
However vitest is still great! Selling points now are stuff like:
- shares config with vite
- works with ESM out of the box (I think Jest still doesn't)
- integrated browser testing mode that is very nice
- overall just has a ton of nicely integrated features
I do recommend turning off "isolate" for as much of your code base as possible when it makes sense. And I recommend ensuring "maxWorkers" is being used properly, I prefer something like 60% of my totals cores as the number of workers to use. And use a top level vitest start so it properly runs all the packages in a pipeline rather than as separate vitest runs (which would mess up the maxWorkers optimization anyhow.)
I have my 3000 test project suite completing in 15 seconds on my MacBook Air M3. It is pretty sweet with that setup.
Say this again when you have worked with Jest, one of the worst and slowest pieces of software I've ever worked with.
And Jest was itself a huge step up from what came before (Jasmine, Mocha...)
I switched to Jest from Mocha and my memory is that Mocha was much faster.
You'd be surprised https://github.com/artemave/node-test-runners-performance-co...
I expected Bun to be among the fastest and yes, I was not surprised.
> Surely all the time is taken by the tests, not calling the test functions?
Calling tests has overhead. Also knowing how to schedule and parallelize tests with dependencies is not as "simple".
You'd be surprised how slow the JS ecosystem can be.
I wish Oxfmt supported plugins. Prettier's plugin API is one of the worst APIs I've ever worked with. I'm eager to switch to a different formatter with a better plugin API (and I need plugins).
I was excited about Oxfmt until I tried it and found that it's mostly intended to be a Prettier replacement. Ugh.
I'm curious to know what you were hoping for. Are there features you're looking for in a formatter that prettier/oxfmt don't offer?
I was hoping for something more flexible. I suppose the whole point of Prettier is that it's not flexible but I find 90% of the times the code is actually uglier when using it.
Try Biome then. But Oxfmt is still faster.
being worked on : https://github.com/oxc-project/oxc/discussions/21936
Have you tried contributing a system for that?
Rolldown is used in Vite (non plus) though.
> Vite, Vitest, Rolldown, tsdown, Oxlint, and Oxfmt
You already use the first, the second you should be using and has existed for years - it's a jest-compatible runner integrated to Vite.
Rolldown is a part of Vite already (since version 8, alongside other implementing tools like lightnincss).
The ox* suite are native replacements for eslint and prettier. The latter has existed for years. Both of them aim to be drop-in compatible soon.
This is a boring stack.
FWIR, prior to the purchase by Vercel (or was it Cloud flare?), Vite+ was going to be a convenient, no fuss, low movement way set up projects that they sold to businesses for funding.
> This is a boring stack.
I think the boring stack would skip the need for most of these. That is 5 different tools to write TypeScript in order to get some HTML, CSS and JavaScript for things that are not covered by modern web standards. Not including the frameworks itself which mostly have the same goal.
That's a pretty disingenuous take on the purpose of TS and misses the point of having a stack in general. The tools actually cover a lot more than that.
Yes, if your goal is to get HTML/CSS/JS in any form to a web client then you don't need this stuff.
If your goal is to ship a web app that stands a chance of surviving multiple devs, production traffic, etc then you need more tools. Testing behavior (vitest), enforcing code standards (oxfmt and oxlint), optimizing network calls (e.g. tree shaking from Rollup), etc. all go beyond what you describe.
This stack is as boring as it gets without literally using the tools it consolidates and replaces or dropping a requirement that necessitates them.
Cloudflare.
the other tools are for testing, bundling, linting and formatting. Previously you would use different tools from very different open source projects for these things, with different configurations, update cycles etc. Now it's all covered by one simple toolchain. Vite+ is basically the "boring but works" stack, while also being more performant and with less configuration required.
This is the latest emerging "boring but works" stack.
"Latest emerging boring but works" sounds like an oxymoron.
So something can only be "boring but works" if it was created before today?
Yes, it's not boring if it's the new hotness
Okay, then how can something become boring? It needs to start as the new hotness? Does that imply that the people who use non-boring software are the ones who determine which things get to graduate to being boring?
Yeah, boring implies that it is predictable, proven and mostly unchanging. In software those almost always come with age.
More or less, yeah?
Unfortunately, yes. It's a backward looking metric, like how economists can only call a recession/depression after it's been X months of bad metrics, even if everyone living in the first month of one feels the economy going poorly. We'll only know if these tools are "boring but work" at some point in the future.
The hope is always that "this time will be different". Maybe these tools are so awesome that they'll become a de facto standard and, therefore, "boring". It's JavaScript, so I'm not holding my breath, though.
Or sarcasm.
I’ve bounced off Vite because I don’t see a big advantage over esbuild. (I also use Deno.) What do you find useful?
That's what I liked from Bun's proposition. A single binary that just works. Hopefully the others take notice.
Honestly, I hate that Bun is vibe-coded and seems amateurish in many ways, but it’s still an excellent tool.
so instead of looking at the result, you are complaining about (a minor aspect of) the process.
Jarred is an excellent engineer. He'll deliver.
> I wonder if there is a push towards a "boring but works" stack.
Yea, this.
eslint -> oxlint (but in rust, and fast)
prettier -> oxfmt (but in rust, and fast)
webpack -> vite (...I have thoughts; but vite is popular enough so w/e)
rolldown -> tsdown (ts support, but in rast and fast)
jest -> vitest (works with vite)
It's basically taking the last decade of established conventions and supporting ts, rewriting in rust for speed, and making it all interoperable.
It's a linter, a code formatter, a tester, and a bundler. What exists in your "boring" stack that's more boring than that?
A "push" towards a boring stack? That won't happen because the hype cycle trends towards new tools like water down a river. But if you're looking, I can't recommend Rails enough in 2026. Built on web standards, it's quietly pushing the framework forward and is so much less maintenance than modern JS apps.
I use oxfmt and oxlint, the first JS linter I've used. For a long time, I avoided Eslint due to how strict it was, but even though oxlint uses eslint, I've been ok using it. I haven't used vitest before though.
And I think Webpack should be discontinued by now, because Vite has replaced it in every way. Maybe to get other projects to switch, they should make a Webpack-to-Vite migration script.
I'm currently experimenting with a stack combining assistance, ASP.NET Razor Pages, and htmx, specifically to avoid dealing with the complexities of the modern frontend stack.
AI eliminates a lot of the tedium, grinding tasks, while HTML partials and htmx complement each other perfectly.
Not having to manage frontend framework, SSR states is incredibly liberating. Sprinkle in some vanillla js and redraw specific parts of the page as needed... done
You're on a good path.
While consulting, I have seen .NET + htmx in production, but it was an internal tool used by thousands of folks (HR system).
The 1ms response times and quick browser rendering due to no JS bloat put a smile on my face.
I have since been planning to give C# backend + htmx frontend a go for a CRUD demo.
Are you open to opportunities?
not at the moment :)
I guess I'm just an old man pumping my fist and yelling at the clouds at this point, but I think compartmentalizing every possible aspect of development and then making each one of those as complex as possible lead AI in the bureaucratic deterioration of the trade.
Fear not, engineer! Recently some smart folks invented something called BackRub that’ll soon solve all your problems! Soon you’ll be able to find information in even less than time than it takes you to type a comment and out yourself as clueless!
I love Vite, Vitest, Oxlint and Oxfmt and look in their direction for most of my new projects! I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade.
Sure beats opening some ancient project and seeing some mix of Gulp, Grunt, webpack and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).
> I hope these folks manage to get a bunch of money and can fund the continued development for at least the next decade.
I believe VoidZero has been acquired by Cloudflare [1], so money should not be an issue. Question is if Cloudflare will be willing to continue letting these people work on Vite and Vite+ features that benefit all cloud platforms, not just Cloudflare.
1. https://blog.cloudflare.com/voidzero-joins-cloudflare/
Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR.
If you only focus on the front-end and remove Typescript from the equation it becomes easy enough. We'll have to see if Vite+ helps for the more complex cases.
Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR.
Although about 98%* of that is because ESLint keeps making breaking changes and getting everything else to work compatibly with ESLint requires 27,573* additional dependencies.
Things I work on have been moving over to Biome recently (mostly these are Vue projects rather than React these days) for formatting and linting and it's so much simpler and avoids all the "What ESLint-related package broke our build process this week?" discussions entirely.
*Some numbers here may be made up. Or they might not.
Lots of breaking changes but I like where they landed, the config file is now clearly an mjs, no longer a hidden file, allows JSX without a plugin. I reckon the best way to upgrade is to generate a new project that has everything configured and copy that and stay close to defaults unless there's a good reason not to.
> Sure beats opening some ancient project and seeing some mix of Vite, Vitest, Oxlint and Oxfmt and a bunch of other disjointed stuff (I migrated that one over to also use the newer stack).
I mean if I see those in N years, I'll be happier than with the older stack that came before them - the jank levels seem to generally be decreasing with every next attempt to get things right!
Vite had five major version in the four years 2022-2026. Version 3 => 4 => 5 => 6 => 7 => 8. Each one of those had breaking changes and required devs to go through a migration. It's too much. And for what? It's not as if it is dramatically better now than it was in version 3.
I can't say I would really look forward to bringing this level of needless churn and constant disruption to the rest of my development toolchain. Anyway, Vite+ is really just wrapping existing tools into an abstracted command-line interface? And so I have more layers of indirection to wade through in order to get the thing to do what I want? So far I am not optimistic about this prospect...
I've followed all the main migrations and I've say they where really quite smooth, can't remember having any major issues and each time it tended to be worth it.
> Version 3 => 4 => 5 => 6 => 7 => 8.
I did the migrations and they were not horrible. A few breaking changes but they were relatively isolated. And the speed and improvements over these versions had been quite significant.
Echoing another person, but we did all those major version migrations without any breakage / churn. What were the breaks you ran into?
I went from 4 to 8 in a single step. I had to change 5 lines of config.
Can we please stop the incessant belly-aching over problems that don't exist. I have to question if you even use these tools?
I'm glad that your trivial migration was trivial.
All this was a big source of churn for plugins and frameworks: https://github.com/vitejs/vite/discussions/16358
All those APIs at that point were marked as experimental, and this is the place where things were ironed out. Churn should be expected when using an experimental API.
also i'm pretty sure claude can one shot this these days. a non-issue.
> It's not as if it is dramatically better now than it was in version 3
Adding stuff for SSR was a major improvement.
SSR is a huge pain in the ass. Now it starts to be hard to have all of that do the frontend properly and let good appropriate languages take care of the backend.
Instead of a stupid, broken and leaky node equivalent backend totally interlocked with code of the frontend.
The churn is the product.
This makes absolutely zero sense. If you're going to post cynically, at least try to have some sort of coherent point?
Tooling instability creates the demand for more tooling.
The major change through all of those was solidifying Vite's concepts of "environments" for better SSR support. If you weren't using that, there wasn't much instability.
Surely lacking features also creates demand for more tooling.
Extremely happy user of Vite, Vitest, Rolldown, tsdown, Oxlint, and Oxfmt.
I do have lot of hardforked packages, and dont want to look back. Everything just works.
If you confused by the naming, start from Oxlint https://oxc.rs/docs/guide/usage/linter Rolldown https://rolldown.rs/
Did very little changes to tsconfig during past 6 months adoption
My day-to-day process - get the new package unless it some antd6, echart or some rendering engine or geo spatial lib, clean up with Claude, strict and unify type system and align it with my vite, tsconfig, oxlint tastes. The result - no need to follow libs bloat and supply chain attack issues. Easy to read, easy to fix.
I think they should find a better name for this project. I find it very confusing since it's not really a better Vite.
At the time Void Zero was probably looking to monetize the Vite brand but now that they've been acquired by Cloudflare they don't need to do that anymore.
Its vite... plus a bunch of stuff. Plus can mean different things
> I think they should find a better name for this project.
Need another plus? Vite++
vite pro max
Vite Enterprise Edition Service Pack 3
Truly have so much trouble keeping up with the frontend (or JavaScript?) ecosystem. I so miss working in laravel. Wish more jobs paid well to use it.
Trust me you don't want to work with Laravel Livewire and Alpine.js, that would still require keeping up and for a less than satisfying result.
Because VILT is dead and Livewire is now on version 1100?
I've worked on both stacks in the last few years across several clients. Honestly like with anything in tech it seems to mostly fall apart with half-regarded usage of the tools in growing teams that don't care about their quality in favour of "get ticket done".
you actually don't have to keep up, whatever you were using still works
I feel ya, we're slowly phasing out our Laravel monolith for python lambdas. I miss those beautiful Laravel 6 days!
Is there a subscription with this?
I'm just wary about anything with a '+' and I assume there is a subscription attached to it.
Looking at this it doesn't look like it.
My first thought too. "$name+" is strongly coded now as "subscription service for $name"
Yeah, not only the name: they’re also going with various semiotic signs that are strongly associated with a subscription service, including their website design, choice of typography, and even the press release–style copy.
Looks like they have been acquired by Cloudflare, and pivoted to fully open source, but they haven’t really tweaked their messaging to make that fully land with unsuspecting visitors.
It’s kinda like the reverse situation of open source projects that switch to a source available license, but keep the aesthetics of an open source project. Kinda funny!
Says:
"It is fully open source under the MIT license"
I think that used to be the idea but then they got acqui-hired
Naming is worrisome!
it worked for uv so i can imagine a competent team can do the same thing for javascript!
Surprised to see this is the only uv reference in the comments!
Feels like an obvious comparison to me, and a very welcome development for the JS ecosystem.
uv made me actually _enjoy_ working in Python again.
a single tool was the enabler of enjoyment? It seems enjoyment is a fleeting thing these days if that's the case
uv removes all the pain from python packaging. and if you ever used it for anything more than one off scripts you know it used to be a lot of pain.
manually activating venv, inconsistent python and dep versions, duplicate files taking up space, slow and broken tools, fragmented configs, global state, all of that is gone now. if you never experienced it you have no idea how bad it was.
not all of it was uv specifically (pyproject.toml was a proposal for some time before) but they cleaned it up. its the only reason i even think about python as an option for new projects.
I appreciate the effort to bring things together in this but…
> Vite+ will manage your global Node.js runtime and package manager.
What? Why?
You’re really going all-in if you adopt this; and… for what? A bit of cozy tooling around existing standard ways of doing things?
Ok, sure; I like tools, like vite.
…but even for an opinionated tool, this is extraordinarily opinionated. Like next.js
Im skeptical.
The pitch of bringing things together seems strong, but did we go too far here?
Reading reviews of people using this didn't really convince me.
It seems to be running on the coat tails of the vite name, rather than its own merit.
Seen this play out again and again: a tool becomes popular, starts incorporating other tools, including mananging language runtime versions. It wants to become the entire platform, to do everything with this one tool. After people get hooked and adapt their workflows to depend on it, inevitably it starts to enshittify. Repeat cycle with new tool.
That is one thing that makes me at least afraid of being too dependent of the uv in Python.
Can it be used for Node builds or browser-only same as Vite?
It uses Vite so the same limitations as Vite. However, I have been using Vite for my NestJS servers without any problem with `vite-plugin-node`. See example at https://github.com/leosuncin/nest-vite-example/blob/master/v...
Here is my particular incantation for targeting node that is working very well: https://pastebin.com/ynz4B5X0
Essentially you pretend to be a library
I am using Vite+ for CLIs as well, yes. You don't use Vite as dev server then but lint, format, task running and caching is still there!
I think tsdown is much better suited for CLI and library builds. Vite has many web-isms that don't matter for these.
I'd be interested in seeing this implementation if it's publicly available. Do you have a GitHub link? Thanks!
I'm always curious of the use case when someone proposes Node code bundling. What's the advantage? Obfuscation in SEA?
In my experience the bundling isn’t really the important aspect (though it also doesn’t harm anything), it’s more just having an ecosystem of plugins for code transpiling, static asset inclusion (e.g. text files) etc and a configuration format folks are already used to.
Running typescript without compilation is still tricky with plain Node. `vite dev` has amazing DX not available for Node programs. I'm wondering if Vite+ tackles this problem.
Don't we have `tsx` and `nodemon` (or the native Node reloader) for that? What are the DX gaps you see on the server side out of on-the-fly transpilation and reload on watch?
Yes, I use tsx for Node programs. It's not great when sharing the same codebase for both client and server code, they have completely different dev workflows.
One advantage of precompilation is risk reduction. Say tsx gets hacked somehow (hardly unprecedented with Node modules!) you’ve got it running on your production server exposed to the internet. Precompilation on a CI pipeline is still a risk but a significantly lower one.
If only the whole JavaScript wasn't as dependency hell of single function packages....
In theory, typescript doesn't need to be transpiled, you can run ts files using `node --experimental-strip-types file.ts` as long as you don't use any code that needs transpilation (like typescript enums).
Still need tsx to do type checking
No, because of ESM import resolution rules. Typescript suggests extensionless imports, making it incompartible with ESM and therefore Node. Luckly, `node --import=tsx file.ts` handles imports well.
This is especially hairy when making a typescript library that is distributed non-compiled (without dist/) and is supposed to run in both browser and Node.
https://github.com/nodejs/node/issues/46006
https://github.com/microsoft/TypeScript/issues/16577
You can use one of the following:
`allowImportingTsExtensions: true` (https://www.typescriptlang.org/tsconfig/#allowImportingTsExt..., useful if you're running `tsc` in noEmit mode as a linter)
`rewriteRelativeImportExtensions: true` (https://www.typescriptlang.org/tsconfig/#rewriteRelativeImpo..., useful if you're using `tsc` to compile TS files to JS.
This allows you to use fully-specified imports in TypeScript files, which works basically everywhere — NodeJS, TypeScript, bundlers, etc.
The exceptions are browsers (obviously, only normal JS syntax there), and packages inside `node_modules`, which NodeJS will not do any type stripping for. So if you're writing a library, you'll probably still need to distribute the compiled sources, rather than distributing the raw TypeScript files alone. Or you use the JSDoc syntax for TypeScript, which can do everything that .ts files can do, but is more verbose and idiosyncratic.
I transpile for prod, but use --strip-types when running in dev, and all I had to do was to make a 10-line ESM register hook that rewrites .js to .ts if the .js import fails, and then a one-liner import register trampoline script. Not sure I'd do that in prod, but works fine in dev at least.
This way I could just use node --watch instead of tsx or nodemon.
Mind sharing the implementation? I think it's basically what tsx is doing when used in `node --import tsx`.
Sure. No need for --(experimental)-strip-types since I-forget-which-version, but I use Node.js 24.17 here.
usage:@afavour if you need precompilation in CI can't you simply use... tsc?
For me, the main benefit is deployment bundle/artifact size reduction. Mostly from dropping unneeded files from node_modules. Many packages include both esm and cjs builds, sources, docs, TS types, etc. stuff that you don’t need in prod. This matters for lambdas, for example, because deployed code size has limits there.
In my case, for my fullstack framework, I used vite on the server to add my own vite plugin, which can cut client-only code from server code. But it was really needed only when I use my framework with Vite. For example, if we use it with a clean bun setup, then I can do it with bun runtime plugins, which also allow me to modify code on the fly and do it really faster than vite. So I want to say that in server js code we may use vite to modify code during the dev/build process, and I have no idea what else we can use vite for in server/cli code
In cases where startup time matters and you have a slow disk, bundling can drastically reduce the number of filesystem calls you have to make for large dependency graphs.
I’ve found if you want interop ts esm and js cjs you need to compile your code - and then `tsc` doesn’t bundle your dependencies for you and outputs incomplete code.
That "+" is making me really nervous. Is this just a naming quirk, or the start of them trying to monetize Vite? If the latter, this is a dark day for frontend dev.
> Is this just a naming quirk, or the start of them trying to monetize Vite?
VoidZero got acquired by Cloudflare, which gives out insane amounts of free services, I'd be very surprised if vite is the place they try start pinching pennies.
you missed the monetization phase. It was already attempted before they were acquired by cloudflare.
The goal was to sell a tool that integrated all parts of vite and oxc ecosystem (oxlint, oxfmt, vite, vitest, etc) in one place.
That stopped right before official cloudflare acquisition announcement.
Doug McIlroy once said: "Make each program do one thing well".
Then he'd love this. Like Unix, Vite+ is a collection of programs that do one thing well.
Toolchain Grand Vitesse
It’s a great move for Cloudflare to have bought up voidzero.
Can I use Astro with this?
yes, vite+ has full support of vite based tools and astro is built on vite.
Layer on layer on layer on layer on layer.... Web development is just a meme by now
This is just what modern languages have out of box. (Like rust and go.) it’s a true shame that web isn’t actually unified behind a type safe language with a single solid toolchain. It’s a huge pain to manage and I’m curious how much money it’s cost the industry. “Vite+” isn’t a true solution to that. There are many competing toolchains. And no default standardized one.
I'm not very familiar with Rust, but doesn't cargo pull a lot of external dependencies for most projects? I really like how Go can do everything with just the standard library, but I wasn't aware Rust was similar. For typescript we've moved our stuff to bun. It has it's own risk management perspective compared to node, but at least it's now possible to build web services without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them.
Cargo itself doesn't pull the dependencies, but yes to Rust's standard library being much more lean than Go. Bring your own HTTP, text templating, and such, but core data structures are provided.
Go gives you a bunch of goodies in the standard library.
Rust provides things like your build system, testing, and package management all together, which is what I assume OP meant.
> without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them.
How about the dependencies Bun is pulling? How did you ever managed to pass security policies with Bun which has so many segfaults that nobody even bothers to write CVEs for them.
> a type safe language with a single solid toolchain
Been paying the bills for 5.5 years now writing in one that gets a fair amount of stick for being ~6.7 years with no language version releases (one is planned for this summer though that should make it just under 7). There's one compiler, one standard library, one formatter (with no config options), one linter, and two test runners but one is a rust rewrite of the other one so it's chill. The language being on a timeout has led to all kinds of things like compilers for native (consuming the intermediate representation .o files), fullstack un-forks (no change to syntax of language), fullstack actual forks, really a lot of weird but delightful activity.
It's like me and a few hundred other people, so "unified" is the part that's missing, haha.
Vite+ isn't a layer, it's "just" a high-performance suite of excellent tools that work well together to provide a great DX for developers.
Vite+ can improve and simplify what developers are already doing with ad-hoc collections of tools. Vite is already an industry standard, and Vite+ has a good chance of achieving that status as well.
Don't be so negative nancy here!
I have been doing "modern web" things since essentially day zero (you kids with your fancy JIT compiled javascript interpreters!)
SvelteKit, and by extension, Vite, has been the single most productive webstack I have ever used. If this offers anything on top of that, I welcome it with open arms.
Far from being a meme!
I use vp with sveltekit for my personal projects now, and I must say it's a very nice experience.
vp + sv seems to work very well, when I tried it. And oxfmt supports svelte now too!
Deze vuist op deze vuist. Deze vuist op deze vuist. Deze vuist op deze vuist. En zo klim ik naar boven.
You probably need to see a video or gif to get it.
Some barbarian without a grasp of the Dutch language knee-jerked the down-vote button so I'll add a Swedish version which adds an important attribute.
Here's how to interpret this saga of the ever-climbing little spider in the context of web development. It climbs up its tread (klättra upp för trå'n) 'cause that new framework will sure make catching those flies (clicks/jobs/likes/whatevers) easier. And then the rain starts (the CVEs start piling up, the corrupted packages come flooding in) and the hapless spider gets thrown off its web (Pwned!) until the sun comes back and dries away the rain (a new framework, yay, this will solve all problems) upon which the spider climbs up its thread again.the swedish song has an english version: https://en.wikipedia.org/wiki/Itsy_Bitsy_Spider
Pretty much all software is built like that.
I think web development does not need that many layers. Usually there is a clear purpose for each layer. I think most problems in web are self-created.
It's all great to leverage until something breaks in a middle layer and you can't reproduce without submitting your entire project in the GitHub issue.
Is everyone project so simple that it can fit in these "vp check" / "vp dev" commands? Like even for my amateurish web app, I have a custom web server with a self-signed certificate with an "/etc/hosts" domain; and for checks I need to do custom checks for GraphQL and a couple of cloned NPM packages.
[flagged]
[flagged]
Vite pumps out major versions -- that is, breaking changes -- at an incredible rate.
I don't want to be a vite upgrade engineer.
I'll try to pass on this if I can.
I have removed vite because dev build and reload is noticable slower than just esbuild and browser refresh. Vite does nothing for me that an LLM can not just trivially rebuild in a bespoke manner.
YMMV
I am actually pushing our frontend devs to remove more and more dependencies and leverage LLMs to just write the code instead of all the dumbass packages in hellscape of supply chain attacks via node/npm.
You are signing up for another hellscape of unmaintainable slop. Enable package cooldowns and only whitelist internal packages and you are better off than 90%
"Unmaintanable" by who? Vite is on its n-th major revision, yet as a user none of my pain points have been addressed and god-knows-what has been added. If that's "maintenance", I don't want it, because what I need out of Vite is trivially replaced. It's the same for most other dependencies. I need a particularly problem solved, but along with a dependency come the authors who, having solved the problem, continue to invent new problems, because they are emotionally invested in their work. I don't begrudge that, but there is a conflict of interest here.
You act like the existing packages being published in this ecosystem aren’t already slop or quickly getting there.
We already do cooldowns and disable preinstall and postinstall scripts on all packages except for ones that actually require it.
I bet if you looked at 70% of your dependencies pulled in, you would be horrified. I would rather have that capabilities via code in my repos at this point.
How do you bundle web workers that import dependencies? iirc the issue in esbuild for that is still open and users are manually building their workers as separate entry points, which is very fragile.
I build them as separate entry points. And to be clear, esbuild doesn't do everything for me, but the solution is bespoke script, not the whole of something like Vite.