Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we switched from Webpack to Vite

blog.replit.com

Post reply on HN
Print view View original

171–180 of 229 posts

Re: Why we switched from Webpack to Vite

#171

Post by TameAntelope »

larrymyers wrote: post #35

I tried out both snowpack and esbuild recently, and while the approach of using es modules was neat, these tools are still wildly immature compared to webpack. Need to handle non-js assets in your bundle? Need to integrate into both node and browser environments? You should stick with webpack. Any time you lose waiting for webpack to run you will get back 10x over by not fighting with your tooling because it doesn't…

I paired snowpack and webpack together and got something that I can use to mostly get a build pipeline going.

Snowpack's latest releases have been... troublesome, but we've stuck with 3.0 and it's been good enough. It completely doesn't support some libraries, but other than that it's been tolerable. Knowing what I know now I probably wouldn't have invested in Snowpack quite yet.

Really hoping Snowpack stabilizes a bit more, or we'll probably just fall back to webpack (or maybe Vite?) again.

Re: Why we switched from Webpack to Vite

#172

Post by EvanYou »

nogridbag wrote: post #136
EvanYou wrote: post #127

Author of Vite here. I see many people evaluating Vite as a webpack replacement, so I want to clarify the goal of the project here: It is NOT Vite's goal to completely replace webpack. There are probably a small number of features/capabilities that some existing webpack projects rely on that doesn't exist in Vite, but those features are in the long tail and are only needed by a small number of power users who write b…

Evan, thanks for your work on Vite. We adopted Vite early on for a large Vue project. My main concern is the testing story. Any ETA on when we'd see official support for something like Jest?

Proper Jest integration is blocked by async transformers (https://github.com/facebook/jest/pull/9889) which should land as part of Jest 27, so we are mostly waiting on that.

In the meanwhile, you can also consider:

- @web/test-runner (https://modern-web.dev/docs/test-runner/overview/)

- Cypress (both e2e and unit testing via its component test runner https://www.cypress.io/blog/2021/04/06/introducing-the-cypre...)

- Check out https://github.com/sodatea/vite-test-example for an example using the above.

Re: Why we switched from Webpack to Vite

#173

Post by rk06 »

joshwa wrote: post #145

Ah, the classic build tool evolution cycle! 1. Become frustrated with complex build tool 2. Write a new tool that is dead simple, opinionated (your opinions), convention over configuration, etc 3. Post to HN 4. Achieve adoption 5. As more people use the tool, feature creep ensues 6. In order to satisfy diverse use cases, make everything modular and configurable! 7. Tool slows and becomes impossible to manage 8. GOTO…

That's quite a leap there. Vite has a different strategy to overcome webpack's slowness, mainly using ES modules and build on demand.

So, even if it were to support more features, it will still be a net gain over webpack.

Not to mention that vite uses esbuild which is 10-100x faster than next best

Re: Why we switched from Webpack to Vite

#174

Post by desireco42 »

simlevesque wrote: post #111
desireco42 wrote: post #62

Earlier quoted context omitted.

You still need webpack for production build :). So all is good.

Why can't you use esbuild for production builds ?

Yes you can, my bad/ But some people have webpack configs, so the easiest for them is to keep those and can use Vite for development. Like if you are not doing new project.

Re: Why we switched from Webpack to Vite

#175

Post by rk06 »

Palmik wrote: post #71

How do people using Vite deal with Common JS dependencies? As far as I tried, there were issues with those when using "vite dev". Sadly, at this point, I can't get rid of those (e.g. protobufs+grpc-web generated code).

The right way would be to raise an issue with this dependencies to support ES modules.

I believe vite does support cj's dependencies, you would need to file an issue on vite repo on why you are getting the error

Re: Why we switched from Webpack to Vite

#176

Post by jeswin »

judofyr wrote: post #54
JMTQp8lwXL wrote: post #20

Earlier quoted context omitted.

As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes browserfied node libs as needed). Beyond node libs, there's a long tail of niche things that need to be taken of... am I trading coverage of that long tail for speed?

Previously I've been a heavy user of Webpack + plugins, but I've now moved over to ESBuild for all new projects. This means letting go of many fancy features, but the overall complexity is so much reduced and I'm a lot happier. Before: Chain together style-loader, css-loader, postcss-loader and the MiniCssExtractPlugin in some weird way. So complicated to understand which PostCSS plugins interacts with resolving impo…

This is excellent advice. There's something I really dislike about import "./style.css" into JS files - it just seems meaningless especially if you've worked with other languages/ecosystems. A great many tutorials default to this style, so it'll likely live on for a while.

As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app (our CRA equivalent) takes 3-4 seconds, and running it is instantaneous. Faster builds actually change the way developers write code.

Re: Why we switched from Webpack to Vite

#177

Post by jabo »

jimmaswell wrote: post #148
EvanYou wrote: post #127

Author of Vite here. I see many people evaluating Vite as a webpack replacement, so I want to clarify the goal of the project here: It is NOT Vite's goal to completely replace webpack. There are probably a small number of features/capabilities that some existing webpack projects rely on that doesn't exist in Vite, but those features are in the long tail and are only needed by a small number of power users who write b…

If someone is already comfortable with webpack or something else and has no complaints or issues with it, how would you sell them on trying vite?

I’m not related to the project, but what stood out to me is the fast reloading between changes, and the optimizations that went into making that happen. Today with webpack, sometimes changes take a full 1-2 seconds to be reflected in the browser and while that’s not terrible, having something refresh in 100s of milliseconds is a game changer at least for me and my frontend workflow.

Re: Why we switched from Webpack to Vite

#178

Post by Shorel »

jupp0r wrote: post #159
Shorel wrote: post #119

Earlier quoted context omitted.

I have done both. C++ is miles better in comparison.

Maybe you can enlighten me how to easily add a dependency (the equivalent of "yarn add lodash") in a platform-independent way.

I have used CMake.

I added the dependency by writing about three CMake lines.

And after that, it just works, for years.

I may have to add from 2, to 5 dependencies for a project, instead of the myriad of dependencies in JS. And they don't become obsolete and need an update each week.

It's a difference of some orders of magnitude, both in number and in upgrade frequency. This is a huge part of dependency management for me.

And there are C++ package managers like Conan, which solve your requirement of adding a dependency by just using the command line.

I will probably use Conan if I have to write C++ again.

Re: Why we switched from Webpack to Vite

#179

Post by viklove »

jeswin wrote: post #176
judofyr wrote: post #54

Earlier quoted context omitted.

Previously I've been a heavy user of Webpack + plugins, but I've now moved over to ESBuild for all new projects. This means letting go of many fancy features, but the overall complexity is so much reduced and I'm a lot happier. Before: Chain together style-loader, css-loader, postcss-loader and the MiniCssExtractPlugin in some weird way. So complicated to understand which PostCSS plugins interacts with resolving impo…

This is excellent advice. There's something I really dislike about import "./style.css" into JS files - it just seems meaningless especially if you've worked with other languages/ecosystems. A great many tutorials default to this style, so it'll likely live on for a while. As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app…

One great problem it solves is namespacing all of your styles. I don't have to worry about classname collisions because the bundle handles it all for me. Instead of having one massive global stylesheet, I have a bunch of small, modular stylesheets that fit entirely on my display without scrolling, and I can reason about the output much easier than before.

Re: Why we switched from Webpack to Vite

#180

Post by manigandham »

MintsJohn wrote: post #22

Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…

It's more the JS ecosystem than web, because of where it started and how it's evolved organically. It's rather surprising we got this far.
Post reply on HN