7 ms·

Vite 4.0

132 points by jonifico 4y ago

fiddlerwoaroof 4y ago
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.
- alex_suzuki 4y ago
  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…
  - jamescostian 4y ago
    Angular has had 13 semver major bumps in the past 5.5 years
    - jmondi 4y ago
      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.
    - alex_suzuki 4y ago
      Sure. But they feel more like minor releases to me. Migrating from one version to the next is usually not a big deal.
      - mb7733 4y ago
        Just like this new version of Vite..?
- philsnow 4y ago
  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.
  - byhemechi 4y ago
    there are breaking changes, but pretty much any intended behaviour changing has automated codemods
  - explodingcamera 4y ago
    The biggest breaking change I see is just dropping compatibility for older browsers, you can however still enable it with a plugin.
  - austinpena 4y ago
    The migration guide looks simple enough: https://vitejs.dev/guide/migration.html https://vitejs.dev/guide/migration.html
  - 22289d 4y ago
    > I have no idea what niche Vite fills Using it with Laravel, it seems to fill the niche of 'Webpack was easy to use and working just fine, let's add this shiny toy and make things a lot more complicated' I love Laravel but I dislike their tendency to do this with new shiny toys.
    - jmondi 4y ago
      Interesting, "webpack" and "easy to use" are two words that I've never seen in the same sentence before.
      - 22289d 4y ago
        Maybe Laravel Mix made it easy to use. Or maybe I just learned it and dislike being forced to learn this new thing.
- CharlesW 4y ago
  > …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."
- afavour 4y ago
  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.
  - RussianCow 4y ago
    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.
    - afavour 4y ago
      > 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.
      - Semaphor 4y ago
        I feel like it depends on who you users are. At work, we cared a long time about IE users. Nowadays we don't, we would care about safari, but as that browser is untestable, we don't. So you either use chrome or Firefox LTS+ or the newest safari. Nothing else matters now.
- tln 4y ago
  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.
byhemechi 4y ago
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
- fabiospampinato 4y ago
  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.
  - byhemechi 4y ago
    ahh well, guess i should've read it more carefully. joke's on me i guess
olingern 4y ago
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/ https://www.ruby-lang.org/en/downloads/releases/ 2 - https://rubygems.org/gems/rails/versions https://rubygems.org/gems/rails/versions
- qprofyeh 4y ago
  With December being the month of code freezes, so engineers have time to do technical upgrades. Smart.
- CharlesW 4y ago
  > 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 https://vitejs.dev/guide/migration.html
revskill 4y ago
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.
joshe 4y ago
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 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".
- pupppet 4y ago
  It's a build tool that converts your JS authoring environment into code your browser will understand.
- rk06 4y ago
  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.
- o_m 4y ago
  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.
- worble 4y ago
  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.
- reducesuffering 4y ago
  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 https://youtu.be/A0BmLYHLPZs?t=68
thunky 4y ago
On the https://vitejs.dev/guide/why.html 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 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?
- rk06 4y ago
  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
- akvadrako 4y ago
  Vite is much faster; that's the main difference for me.
encryptluks2 4y ago
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.
- reducesuffering 4y ago
  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.
- dmix 4y ago
  You use Go and Rust for frontend development?
  - encryptluks2 4y ago
    No I use HTML, CSS and JS or TS with esbuild.
jvanveen 4y ago
CSS sourcemaps, being a basic assets in frontend tooling for many years, are still unsupported in Vite(https://github.com/vitejs/vite/issues/2830 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.
- 5Qn8mNbc2FNCiVV 4y ago
  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.
  - dmix 4y ago
    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.
clementmas 4y ago
Isn't it too early to drop Safari 13 support by default?

132 points by jonifico 4y ago

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.

alex_suzuki 4y ago
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…
- jamescostian 4y ago
  Angular has had 13 semver major bumps in the past 5.5 years
  - jmondi 4y ago
    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.
  - alex_suzuki 4y ago
    Sure. But they feel more like minor releases to me. Migrating from one version to the next is usually not a big deal.
    - mb7733 4y ago
      Just like this new version of Vite..?
philsnow 4y ago
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.
- byhemechi 4y ago
  there are breaking changes, but pretty much any intended behaviour changing has automated codemods
- explodingcamera 4y ago
  The biggest breaking change I see is just dropping compatibility for older browsers, you can however still enable it with a plugin.
- austinpena 4y ago
  The migration guide looks simple enough: https://vitejs.dev/guide/migration.html https://vitejs.dev/guide/migration.html
- 22289d 4y ago
  > I have no idea what niche Vite fills Using it with Laravel, it seems to fill the niche of 'Webpack was easy to use and working just fine, let's add this shiny toy and make things a lot more complicated' I love Laravel but I dislike their tendency to do this with new shiny toys.
  - jmondi 4y ago
    Interesting, "webpack" and "easy to use" are two words that I've never seen in the same sentence before.
    - 22289d 4y ago
      Maybe Laravel Mix made it easy to use. Or maybe I just learned it and dislike being forced to learn this new thing.
CharlesW 4y ago
> …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."
afavour 4y ago
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.
- RussianCow 4y ago
  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.
  - afavour 4y ago
    > 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.
    - Semaphor 4y ago
      I feel like it depends on who you users are. At work, we cared a long time about IE users. Nowadays we don't, we would care about safari, but as that browser is untestable, we don't. So you either use chrome or Firefox LTS+ or the newest safari. Nothing else matters now.
tln 4y ago
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.

byhemechi 4y ago

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

fabiospampinato 4y ago
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.
- byhemechi 4y ago
  ahh well, guess i should've read it more carefully. joke's on me i guess

olingern 4y ago

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/ https://www.ruby-lang.org/en/downloads/releases/ 2 - https://rubygems.org/gems/rails/versions https://rubygems.org/gems/rails/versions

qprofyeh 4y ago
With December being the month of code freezes, so engineers have time to do technical upgrades. Smart.
CharlesW 4y ago
> 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 https://vitejs.dev/guide/migration.html

revskill 4y ago

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.

joshe 4y ago

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 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".

pupppet 4y ago
It's a build tool that converts your JS authoring environment into code your browser will understand.
rk06 4y ago
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.
o_m 4y ago
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.
worble 4y ago
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.
reducesuffering 4y ago
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 https://youtu.be/A0BmLYHLPZs?t=68

thunky 4y ago

On the https://vitejs.dev/guide/why.html 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 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?

rk06 4y ago
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
akvadrako 4y ago
Vite is much faster; that's the main difference for me.

encryptluks2 4y ago

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.

reducesuffering 4y ago
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.
dmix 4y ago
You use Go and Rust for frontend development?
- encryptluks2 4y ago
  No I use HTML, CSS and JS or TS with esbuild.

jvanveen 4y ago

CSS sourcemaps, being a basic assets in frontend tooling for many years, are still unsupported in Vite(https://github.com/vitejs/vite/issues/2830 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.

5Qn8mNbc2FNCiVV 4y ago
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.
- dmix 4y ago
  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.

clementmas 4y ago

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