My experience with Vite 3 has been great so far (during the alpha/beta). Any issues I had that came up during the beta were fixed or responded to in less than 12 hours. The momentum behind getting this released was pretty impressive. Patak's coordination and contributions have really pushed things along!
> Has Webpack really been dethroned as the go-to bundler?
At this point yes. I'm sure there are still some things that you will need Webpack for, but in my experience I have yet to find one of those instances. Vite is not just way way way faster than Webpack, it's also way simpler.
Configuring a React project from scratch with Webpack is an undertaking, especially if you're not seasoned with Webpack configurations. Vite on the other hand is super simple to setup, I typically don't even reach for the starters that vite offers because it's just as easy to do an `npm init -y` and then install it manually.
I work for a web dev agency and we have migrated all of our existing projects to Vite, and advised any new projects to not use Webpack unless there is a very specific reason and other solutions have been exhausted.
Webpack really messed up IMO -- v5 took a really, really long time to drop because they were making huge changes ostensibly for performance... and then when it came out it actually made performance worse for many projects. I think they've fixed that now, but the damage is done.
I think building js in js is just not fast enough anymore, everyone is moving towards compiled languages for building their apps. The next winner in the space will be something like vite that uses a compiled language under the hood (vite uses esbuild, which is written in Go).
A dev server with hot reloading is the big thing vite adds IMHO, at least for your day to day use. It also adds rollup and a more uniform plugin system for your production builds but really the dev server experience is where vite excels.
> While esbuild is blazing fast and is already a very capable bundler for libraries, some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling. For the time being, Rollup is more mature and flexible in these regards. That said, we won't rule out the possibility of using esbuild for production build when it stabilizes these features in the future.
In my experience, Vite offers a better onboarding process and has a more straightforward configuration format compared to ESBuild. You also get most of rollup's plugin ecosystem and a large amount of community tools made specifically for Vite (Vitest, ViteBook, vite-plugin-pwa, etc...). Also, I might be wrong about this but I don't think ESBuild has HMR, which really speeds up development.
Overall, ESBuild feels like a much lower-level tool than Vite. It's great for smaller projects or projects that require absolute and complete control over their builds, but it takes more time to setup in most cases and often requires writing your own build scripts.
The landing page of Vite claims "Next Generation Frontend Tooling" but then go on to describe features that already have been existing for a good while (multiple years).
What exactly is the "next generation" part here? The composition? That's also not new, so I think I'm either missing something very obvious, or they need to do a better job explaining how Vite is actually different.
React Context HMR still has problem. Due to this problem, I think nextjs still the better choice for react dev. Maybe vite supports too many frameworks, do not have enough time to handle the react problems.
Vite is framework agnostic. Framework specific work is spearheaded by framework specific community or core authors in some cases (solid, astro)
React falters because there are not many community contributing towards react integration.
Note: Vite team has done their job for react, but react itself has many concerns particularly due to commonjs that a dedicated person (or team) is needed for react
That issue is disappointing. It's an important issue for making React work, it's been open for over a year, and there isn't any comment from someone who works on vite or the plug-in.
I know that this is all about Vite but if you like Vite, I want to give a shout-out to Parcel[0] as well. Its a very similar philosophy, built on top of SWC[1] and has its own set of great optimizations. I've regularly gotten smaller overall bundle sizes with parcel than with Vite (though that gap is very narrow now) in my experience. I wish Parcel got more mention, especially in the React community (where it shines the most). It really is very very fast and I think has really cool integrations (like file system resolution) out of the box.
Parcel has been praised on here many times when it originally came out. I was an avid user but the nail in the coffin was the horrid and long release of v2 which took forever, the docs were in disarray, and overall just left a bad taste in my mouth. I also think there was some common issue where v1 didn’t support some version of postcss for quite some time and I and many others jumped ship to vite.
I really like the defaults Parcel comes with, it is very quick to get started with Parcel.
However, the promise of zero config is made possible in part by "magic" (strange conventions), and by having configuration spread across multiple files (package.json, . parcelrc, custom plugins which for some grave reason you can't use until you publish them to npm)
I really wish Parcel had sane configuration — I want to like it so much, but alas, it falls pray to the pendulum effect.
Not to be unnecessarily dismissive, but installing Parcel makes me a 201MB node_modules folder. That's more dependencies/code than I'm comfortable relying upon.
Vite's really gaining traction, from the chatter I'm seeing. Seems pretty good in my initial trial of it - I'm hoping it spurs other tools to improve performance and dev experience.
Question: Is Vite really a serious tool built for production apps? The design decisions don't give me confidence.
As your app starts to grow, you'd definitely not want 1000s of modules loading in your browser.
Seems like something that gets you from 0-60 quickly, and becomes a pain after.
Similarly, the different choice of bundlers in development and production would well lead to difference in behaviour / hard to catch bugs.
Shopify is using it with React. Lavarel now adopted it. It's the default for Vue projects going forward (given it's made by the person who made Vue).
Plenty of serious support behind it.
Not sure how you'd end up with "1000s of modules in your browser", unless you have some mega-project with an unwieldy package.json. I have a pretty complex Vue project app and it loads <100 .js files async and the vast majority are 100b and 95% will cache on the first load and never change. It's really not that big of a deal for modern browsers to load lots of tiny js files from your local machine in development.
I've found it to be way faster than Webpack for dev build times which is all that really matters to me.
Yes. Currently using it in production and couldn't be happier.
The individual modules are only served during development, but even then startup/load is faster than our previous webpack setup by an order of magnitude. When you build for production, you still end up with a bundle like you had previously.
It serves unbundled for development and bundled in production. In practice this works pretty well as long as you do decent code splitting (and you should be doing code splitting!)
Edit: lol I should have read your post more closely. Yes, the different strategies can cause bugs; there's much more shared between the two pipelines than there used to be so this situation is improving. We actually had really bad compatibility with problems six months ago and it was still easily worth the trouble for the performance improvement.
I am currently using WebPack to package a multi-page web app. Build times are relatively quick, and when developing I am using a feature that does an incremental rebuild when files are changed and that's quite fast at this point.
This being the case, I am not sure I'd really have a reason to migrate over to Vite on this project.
if build times are quick and you’re not getting tooling issues there is no reason to switch.
the only reason i switched to Vite was that in my experience with Webpack build times were not quick and i got annoying JS bundling issues like syntax errors (!). That’s really the main difference I saw between the 2. But it was a while ago and maybe webpack has gotten better again, in which case they’re both very similar.
Don't switch if its pleasent to work with already. Vite is very nice, but it lets your browser load each module individually in dev mode (not like webpack, that creates chunks that combine lots of modules), so if you have a big project, you may end up with pages where your browser has to resolve and load 100 modules, which may be slower then webpack serving you 3 chunks.
I'm in that same situation in an MPA Fastify + Svelte project. Honestly, it takes more time for the app to reconnect to the DB than for Webpack to do an incremental rebuild.
I've been considering switching to Vite because it should make the SSR + hydration config much simpler and I would get HMR (hot module reloading) which will probably speed my iteration times if it works as expected.
The funny thing is that I hate changing tech at the backend, but still love many of the innovations at the frontend.
I know, it still seems crazy what's happening at the frontend ... but Vite brings substantial advantages compared to the old standard. Same thing with the next-gen frameworks like Svelte, SolidJS or Vue 3 (composition API) that are substantially better than the old ones (mainly regarding DX). Another welcoming example are the quite new E2E testing frameworks like Cypress or Playwright.
Yep agreed. For me it's welcome because this latest generation of churn feels like it has leveled up DX considerably. The churn in between Backbone up until ~ Angular 1 brought a lot less value in my experience at least.
> Vite is powering a renewed innovation race in Web frameworks.
Wait what, again? I thought we all silently agreed to use the mature/legacy frameworks React and Angular until the proper WASM arrives so that we could burn all of JS/CSS/HTML...
HMR is nice, but the added complexity seems to make basic stuff like sourcemaps support difficult. Would be nice to have something that adds HMR with the flexibility of a custom build stack(esbuild + a better livereload)
[+] [-] invisible|3 years ago|reply
[+] [-] FinalBriefing|3 years ago|reply
Has Webpack really been dethroned as the go-to bundler?
[+] [-] _fat_santa|3 years ago|reply
At this point yes. I'm sure there are still some things that you will need Webpack for, but in my experience I have yet to find one of those instances. Vite is not just way way way faster than Webpack, it's also way simpler.
Configuring a React project from scratch with Webpack is an undertaking, especially if you're not seasoned with Webpack configurations. Vite on the other hand is super simple to setup, I typically don't even reach for the starters that vite offers because it's just as easy to do an `npm init -y` and then install it manually.
I work for a web dev agency and we have migrated all of our existing projects to Vite, and advised any new projects to not use Webpack unless there is a very specific reason and other solutions have been exhausted.
[+] [-] basilgohar|3 years ago|reply
[0] https://laravel-news.com/vite-is-the-default-frontend-asset-...
[+] [-] ForSpareParts|3 years ago|reply
I think building js in js is just not fast enough anymore, everyone is moving towards compiled languages for building their apps. The next winner in the space will be something like vite that uses a compiled language under the hood (vite uses esbuild, which is written in Go).
[+] [-] twstdzppr|3 years ago|reply
[+] [-] mekster|3 years ago|reply
Otherwise I've been using Parcel without much issues with quite less configuration.
[+] [-] skybrian|3 years ago|reply
[+] [-] qbasic_forever|3 years ago|reply
If you just want esbuild + hot reloading then dev-server-esbuild might be a good option: https://modern-web.dev/docs/dev-server/plugins/esbuild/ But really vite isn't much more complex or opinionated compared to it.
[+] [-] b0afc375b5|3 years ago|reply
https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
> While esbuild is blazing fast and is already a very capable bundler for libraries, some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling. For the time being, Rollup is more mature and flexible in these regards. That said, we won't rule out the possibility of using esbuild for production build when it stabilizes these features in the future.
[+] [-] tropix126|3 years ago|reply
Overall, ESBuild feels like a much lower-level tool than Vite. It's great for smaller projects or projects that require absolute and complete control over their builds, but it takes more time to setup in most cases and often requires writing your own build scripts.
[+] [-] capableweb|3 years ago|reply
What exactly is the "next generation" part here? The composition? That's also not new, so I think I'm either missing something very obvious, or they need to do a better job explaining how Vite is actually different.
[+] [-] enw|3 years ago|reply
Isn’t this exhausting?
Is it impossible to design good contracts without having to break compatibility every year?
In most other language ecosystems it would convey incompetence.
[+] [-] wener|3 years ago|reply
[1]: https://github.com/vitejs/vite/issues/3301
[+] [-] rk06|3 years ago|reply
React falters because there are not many community contributing towards react integration.
Note: Vite team has done their job for react, but react itself has many concerns particularly due to commonjs that a dedicated person (or team) is needed for react
[+] [-] gedy|3 years ago|reply
(With that said, I'd love to see Next use Vite, but iirc the webpack dev works for Vercel [Nextjs parent] now)
[+] [-] nilsbunger|3 years ago|reply
[+] [-] no_wizard|3 years ago|reply
[0]: https://parceljs.org/docs/
[1]: https://swc.rs/
[+] [-] JoshGlazebrook|3 years ago|reply
[+] [-] pastelsky|3 years ago|reply
However, the promise of zero config is made possible in part by "magic" (strange conventions), and by having configuration spread across multiple files (package.json, . parcelrc, custom plugins which for some grave reason you can't use until you publish them to npm)
I really wish Parcel had sane configuration — I want to like it so much, but alas, it falls pray to the pendulum effect.
[+] [-] fabiospampinato|3 years ago|reply
[+] [-] pier25|3 years ago|reply
[+] [-] barbinbrad|3 years ago|reply
[+] [-] creamyhorror|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] pastelsky|3 years ago|reply
As your app starts to grow, you'd definitely not want 1000s of modules loading in your browser.
Seems like something that gets you from 0-60 quickly, and becomes a pain after. Similarly, the different choice of bundlers in development and production would well lead to difference in behaviour / hard to catch bugs.
[+] [-] dmix|3 years ago|reply
Plenty of serious support behind it.
Not sure how you'd end up with "1000s of modules in your browser", unless you have some mega-project with an unwieldy package.json. I have a pretty complex Vue project app and it loads <100 .js files async and the vast majority are 100b and 95% will cache on the first load and never change. It's really not that big of a deal for modern browsers to load lots of tiny js files from your local machine in development.
I've found it to be way faster than Webpack for dev build times which is all that really matters to me.
[+] [-] rickbergfalk|3 years ago|reply
The individual modules are only served during development, but even then startup/load is faster than our previous webpack setup by an order of magnitude. When you build for production, you still end up with a bundle like you had previously.
[+] [-] ForSpareParts|3 years ago|reply
Edit: lol I should have read your post more closely. Yes, the different strategies can cause bugs; there's much more shared between the two pipelines than there used to be so this situation is improving. We actually had really bad compatibility with problems six months ago and it was still easily worth the trouble for the performance improvement.
[+] [-] hahamrfunnyguy|3 years ago|reply
This being the case, I am not sure I'd really have a reason to migrate over to Vite on this project.
[+] [-] armchairhacker|3 years ago|reply
the only reason i switched to Vite was that in my experience with Webpack build times were not quick and i got annoying JS bundling issues like syntax errors (!). That’s really the main difference I saw between the 2. But it was a while ago and maybe webpack has gotten better again, in which case they’re both very similar.
[+] [-] sod|3 years ago|reply
[+] [-] pier25|3 years ago|reply
I've been considering switching to Vite because it should make the SSR + hydration config much simpler and I would get HMR (hot module reloading) which will probably speed my iteration times if it works as expected.
[+] [-] simlevesque|3 years ago|reply
[+] [-] WuxiFingerHold|3 years ago|reply
I know, it still seems crazy what's happening at the frontend ... but Vite brings substantial advantages compared to the old standard. Same thing with the next-gen frameworks like Svelte, SolidJS or Vue 3 (composition API) that are substantially better than the old ones (mainly regarding DX). Another welcoming example are the quite new E2E testing frameworks like Cypress or Playwright.
[+] [-] radus|3 years ago|reply
[+] [-] WhitneyLand|3 years ago|reply
https://vitejs.dev/guide/why.html#the-problems
[+] [-] dannyphantom|3 years ago|reply
[+] [-] arthurcolle|3 years ago|reply
[+] [-] philliphaydon|3 years ago|reply
[+] [-] microSnowball|3 years ago|reply
https://vitejs.dev/guide/migration.html#automatic-https-cert...
[+] [-] 202206241203|3 years ago|reply
Wait what, again? I thought we all silently agreed to use the mature/legacy frameworks React and Angular until the proper WASM arrives so that we could burn all of JS/CSS/HTML...
[+] [-] jvanveen|3 years ago|reply
[+] [-] kriro|3 years ago|reply
[+] [-] rk06|3 years ago|reply
Hopefully, they will update soon
[+] [-] benmccann|3 years ago|reply
[+] [-] cosmiccatnap|3 years ago|reply