JS land really needs to take some notes on how Rust and Go handle major versions, i.e. avoid them if possible. Breaking changes may be progress for tooling but for end users it's upgrade hell.

Ruby ~Rails~ found the middleground where major/minor versions[1] typically land in December. Rails[2] typically follows which gives users ample time to upgrade along with a migration guide

1 - https://www.ruby-lang.org/en/downloads/releases/

2 - https://rubygems.org/gems/rails/versions

> Rails typically follows which gives users ample time to upgrade along with a migration guide

FWIW, this is the norm for Vite and other well-managed JS frameworks as well. Vite 2 is still available, Vite 3 will presumably be available for another year or two, and you can see from the migration guide that the Vite 4 migration process is minimal: https://vitejs.dev/guide/migration.html

With December being the month of code freezes, so engineers have time to do technical upgrades. Smart.

A core piece of tooling like this going through four major versions in two years really makes me hesitant to use it: it tells me that the authors of the tool don’t care about breaking changes and I’ll have to do a lot of maintenance work to keep up with the latest release.

> …it tells me that the authors of the tool don’t care about breaking changes…

They sure seem to. The 4.0 changelog starts:

"This major is smaller in scope compared to Vite 3, with the main objective of upgrading to Rollup 3. We've worked with the ecosystem to ensure a smooth upgrade path for this new major."

From "Compatibility":

"The modern browser build now targets safari14 by default for wider ES2020 compatibility (#9063). This means that modern builds can now use BigInt and that the nullish coallessing operator isn't transpiled anymore. If you need to support older browsers, you can add @vitejs/plugin-legacy as usual."

Surely this is a side-effect of semantic versioning? Any breaking change means a new major version number. That doesn't necessarily mean a ton of maintenance work.

For example: the base version of Safari being targeted is now the version from 2020 instead of 2019. That's a breaking change. For the vast majority of people it is going to require zero work but for a minority of people (specifically targeting old iPad versions, perhaps) it's not something they can be automatically opted into.

In practice, it doesn't really matter. Every breaking change increases risk as an end user and reduces the likelihood that I'll upgrade at all, instead of switching to something else more stable.

Then again, the number of times I've been bit by a "minor" breaking change causing massive headaches during upgrades has made me somewhat jaded on the topic. No matter how great the tool, I will always prefer something more stable for real, production work.

> Every breaking change increases risk as an end user and reduces the likelihood that I'll upgrade at all, instead of switching to something else more stable.

I understand this perspective and don't wish to sound negative but with this approach it's possible that web development simply isn't for you. The volatility in these tools is a reflection of the volatility in client browsers: they're upgraded constantly with new features that benefit the end user. I'm sending images to clients using WebP instead of PNG because the bandwidth savings are huge. That was a "breaking change" to my publishing pipeline but it was worth the investment.

At the same time you can keep using Vite 3. I've dug out old projects using old versions of Webpack and they've still functioned fine.

I think if you read the release notes for each version you'll see a different picture:

Vite 2 was a big architectural change, but Vite 3 and 4 have been driven by external changes -- node EOL, major rollup release, browser releases.

The amount of actual code churn is fairly low and dropping.

Are they making breaking changes? I'll admit I don't frontend and I have no idea what niche Vite fills, but I briefly glanced at the release notes and I don't see a section talking about anything breaking even though this release marks a major revision. Maybe they're not using semver the way we're expecting.

The migration guide looks simple enough: https://vitejs.dev/guide/migration.html

The biggest breaking change I see is just dropping compatibility for older browsers, you can however still enable it with a plugin.

There’s a bunch of custom rollup config you can do. If rollup made breaking changes between 2 and 3, those would be breaking for Vite too.

Interesting, "webpack" and "easy to use" are two words that I've never seen in the same sentence before.

Maybe Laravel Mix made it easy to use.

Or maybe I just learned it and dislike being forced to learn this new thing.

You are totally right, Laravel Mix really does make Webpack a breeze to use. But at that rate, you're using Mix and not Webpack :)

there are breaking changes, but pretty much any intended behaviour changing has automated codemods

This is the normal, widely accepted pace for “hot” web frontend frameworks! ;-) Nobody’s forcing you to use it. I’m sticking with boring old Angular for my SPA needs…

Angular has had 13 semver major bumps in the past 5.5 years

And there have been more than a few in those 13 that were pretty decent breaking changes too. There are many good things about Angular for sure, but it has the same "issues" as any other frontend project.

Sure. But they feel more like minor releases to me. Migrating from one version to the next is usually not a big deal.

Just like this new version of Vite..?

Can someone explain or point to something about what vite is?

Is this very niche or something every web developer should be interested in?

Tried this https://vitejs.dev/guide/why.html, and the comparisons page and it's all buzzwords.

"Vite aims to address these issues by leveraging new advancements in the ecosystem: the availability of native ES modules in the browser, and the rise of JavaScript tools written in compile-to-native languages."

Corp PR speak is not the pinnacle, there is no reason to emulate it. To "Address" a problem means you haven't solved it. "Leveraging" just means "using".

Vite is something every web dev should be interested in.

Say you want to create a new React frontend? Should you make directories, package.json, wire up the .html to ReactDOM, and all the other little things? Most likely not. Just 'npm create vite' and select React.

It can be used for other JS like Vue, Svelte, and Preact.

For example, if you wanted to quickly make a UI, you don't need to fiddle with webpack and other crazy build steps. This guy had just run 'npm create vite && npm install && npm run dev' and starts creating UI right away: https://youtu.be/A0BmLYHLPZs?t=68

Think "webpack + webpack dev server" but better.

Vite aims to provide a excellent dev build & HMR experience and use it's build config to generate prod bundles.

Yes, every web developer should care about frontend build tools. Those who don't use Vite, Webpack, or similar tools ends up with multi megabyte websites that are a mess.

It's a build tool that converts your JS authoring environment into code your browser will understand.

The tl;dr is webpack but better.

I'll admit I was cynical too, reinventing front-end build tools is the current day reinventing front-end frameworks, but after using it, it really is a hell of a lot better and easier to manage than webpack hell, I'd give it a try if it's the sort of thing that interests you.

On the https://vitejs.dev/guide/why.html page Parcel is mentioned under "The problems" section, suggesting that Vite improves on Parcel.

Yet in the https://vitejs.dev/guide/comparisons.html page Parcel is not mentioned.

So as someone familiar with Parcel and not familiar with Vite I don't know why I should take a deeper look at Vite...or maybe I shouldn't?

If you are satisfied with parcel, you should stick with parcel.

Otherwise, there is no harm in playing around! I think Vite is on track to become a major player, so it is worth checking out

Vite is much faster; that's the main difference for me.

i really like vite, my biggest complaint with it previously was that it used the incredibly slow babel in development. i'm very happy to see it's moving to swc, this will hopefully make large sveltekit projects not use all of my battery with hot reload

It's not possible to just switch to SWC, all the Babel plugins that you use would need to be rewritten for SWC also. As far as I know there's only one Svelte compiler and it's written in JS.

ahh well, guess i should've read it more carefully. joke's on me i guess

CSS sourcemaps, being a basic assets in frontend tooling for many years, are still unsupported in Vite(https://github.com/vitejs/vite/issues/2830). Being an open issue for that long, while sourcemaps are supplied for free with tools like ESBuild & SCSS, are perhaps an indication of too much complexity in Vite? About build performance; ESBuild(and SWC as well) happily build large projects within reasonable time(<200ms). I doubt that skipping bundling all-together, by using ES-Modules during development, is worth the extra hassle in tooling. It made sense during the Webpack/Vuepack/Parcel 1 era, but not that much anymore since ESBuild happened. Spending some extra time in writing a custom buildscript (ESBuild + SCSS + simple async task manager + Chokidar + Tinylr or something similar) pays itself back really quick when a project gets larger.

If I had the decision between Vite without CSS sourcemaps and anything else or worst at all a custom build script I'd choose Vite any day of the week.

Same it’s a worthy trade off for the disaster that is Webpack. I had multiple deploys break from Webpack and now have had zero problems since.

Everytime I try a JS framework, the process is... see that there isn't a compiled release, determine that I need to use yarn (or npm), pull in 1000 dependencies with multiple vulnerabilities and wait 30 seconds or more, go back to Go or Rust.

Try 'npm create vite --react && npm install && npm run dev'. There should be like 30 final dependencies and runs in under a second, with code changes immediately being reflected on your browser UI.

You use Go and Rust for frontend development?

No I use HTML, CSS and JS or TS with esbuild.

Last time tried to build standalone "library" to embed in another application but failed with vitejs (Parcel worked instead). Imagine bundle all application into a bundle.min.js, a bundle.min.css file.

Hope this story could improve.

Isn't it too early to drop Safari 13 support by default?