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 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.
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.
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).
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.
> 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.
> 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!
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 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.
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.
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.
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.
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.
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!
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.
> 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.
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.
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.
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.
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.
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.
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 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.
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.
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 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...
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).
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.
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/
Essentially you pretend to be a library
Still need tsx to do type checking
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
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.
"It is fully open source under the MIT license"
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!
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.
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.
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.
You probably need to see a video or gif to get it.
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!
> 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.
YMMV