Vite 4.0

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&#x27;s upgrade hell.<p>Ruby ~Rails~ found the middleground where major&#x2F;minor versions[1] typically land in December. Rails[2] typically follows which gives users ample time to upgrade along with a migration guide<p>1 - <a href="https:&#x2F;&#x2F;www.ruby-lang.org&#x2F;en&#x2F;downloads&#x2F;releases&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ruby-lang.org&#x2F;en&#x2F;downloads&#x2F;releases&#x2F;</a><p>2 - <a href="https:&#x2F;&#x2F;rubygems.org&#x2F;gems&#x2F;rails&#x2F;versions" rel="nofollow">https:&#x2F;&#x2F;rubygems.org&#x2F;gems&#x2F;rails&#x2F;versions</a>

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.

Can someone explain or point to something about what vite is?<p>Is this very niche or something every web developer should be interested in?<p>Tried this <a href="https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;why.html" rel="nofollow">https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;why.html</a>, and the comparisons page and it&#x27;s all buzzwords.<p>&quot;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.&quot;<p>Corp PR speak is not the pinnacle, there is no reason to emulate it. To &quot;Address&quot; a problem means you haven&#x27;t solved it. &quot;Leveraging&quot; just means &quot;using&quot;.

On the <a href="https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;why.html" rel="nofollow">https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;why.html</a> page Parcel is mentioned under &quot;The problems&quot; section, suggesting that Vite improves on Parcel.<p>Yet in the <a href="https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;comparisons.html" rel="nofollow">https:&#x2F;&#x2F;vitejs.dev&#x2F;guide&#x2F;comparisons.html</a> page Parcel is not mentioned.<p>So as someone familiar with Parcel and not familiar with Vite I don&#x27;t know why I should take a deeper look at Vite...or maybe I shouldn&#x27;t?

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

CSS sourcemaps, being a basic assets in frontend tooling for many years, are still unsupported in Vite(<a href="https:&#x2F;&#x2F;github.com&#x2F;vitejs&#x2F;vite&#x2F;issues&#x2F;2830" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vitejs&#x2F;vite&#x2F;issues&#x2F;2830</a>). Being an open issue for that long, while sourcemaps are supplied for free with tools like ESBuild &amp; 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(&lt;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&#x2F;Vuepack&#x2F;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.

Everytime I try a JS framework, the process is... see that there isn&#x27;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.

Last time tried to build standalone &quot;library&quot; 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.<p>Hope this story could improve.

Isn&#x27;t it too early to drop Safari 13 support by default?