Hacker News Reader

Comment by FinalBriefing | Hacker News Reader

I had no idea so many other frameworks are using Vite as their default. Event server-side frameworks are picking it up!

Has Webpack really been dethroned as the go-to bundler?

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

> Configuring a React project from scratch with Webpack

Why do people do this? I've always used the official way (CRA), and never had any issues with it. If you need to adjust webpack configuration, there are third-party packages that work very well in practice (like craco). Yet reinventing the wheel over and over again seems to be popular.

https://create-react-app.dev/docs/getting-started

The user you replied to gave a reason already:

> Vite is not just way way way faster than Webpack, it's also way simpler.

It's not reinventing the wheel. It's just significantly improving the wheel.

You're answering a question I didn't ask (see the first quoted line). I'm interested in why would anyone waste their time on what's already been done (namely, re-implementing create-react-app from scratch).

I'm not a huge fan of these "managed" frameworks, especially for a larger app. The reason I set things up from scratch is there is alway a fear that in the future a migration away from <MANAGED_FRAMEWORK> will be required for some reason and the effort will be much greater than if we had set it up custom from the getgo.

Nice! Each time I tried out a new bundler (Parcel comes to mind), we hit issues where their configuration hasn't been sufficient for some niche stuff I learned to expect Webpack to handle. I can't think of any specific examples, but I'm sure you've seen something similar.

Vite has been great in the vanilla and Vue projects I've used it for. I didn't think the speed bump would be as noticeable as it was. I'm really happy to hear it is getting more usage in frameworks like Laravel.

I first learned about Vite when Laravel News [0] announced Laravel was switching.

[0] https://laravel-news.com/vite-is-the-default-frontend-asset-...

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

For me using Webpacker with rails was a nightmare in the last two years.

The move to 3->4 was painful as 25% of my projects started to move to 4 and no longer worked with 3. So I was stuck with some legacy packages during a time I was upgrading from Vue 2 -> 3. AFAIK they Rails didn't even get to Webpack 5 in practice by the time I left.

Vite came to the rescue at a perfect time.

I don't think just building JS is slow, I think the issue is that most of the ecosystem is ready to move on to more "no build" scenarios now that ES modules are supported everywhere that matters [0] [1] (Node 12+). Webpack still doesn't seem to have much of an ESM "native" approach/roadmap. Snowpack had a relatively good ESM "native" approach, but appears finished and points to Vite now. Vite isn't entirely ESM "native" yet, but there's more work there mentioned in these release notes and it definitely appears to be in their roadmap/planning horizon. I'm curiously following Vite, but so far it smells to me more of a webpack too much of the kitchen sink "fork" than not still for the "no build"/"targeted build" world.

I've been experimenting with some stuff using esbuild directly in a "targeted" way that builds only a few things with most stuff just Typescript transpilation only (again). I've almost got a feeling the next winner may just be Typescript+esbuild, but not at all because esbuild is fast or written in Go. It may still be Typescript+rollup, given the hints of what's coming in the next Rollup major. (Typescript is still in JS and getting faster every release, with incremental build support for large projects getting better all the time. Rollup is still in JS and still a decent esbuild competitor.) In a "no build"/"targeted build" world it's not really speed that matters but a minimal, targeted API that's easy to automate as you choose targets to build and it may be the case that the time of the "kitchen sink plus a million plugins" builder is over.

[0] https://caniuse.com/es6-module

[1] https://caniuse.com/es6-module-dynamic-import

Webpack hasn't been dethroned, but it certainly has a competitor.

If you start a new project now and use Webpack, I can't understand it.

The only thing other packagers can't win against Webpack is its name.

Otherwise I've been using Parcel without much issues with quite less configuration.

Reply on news.ycombinator.com