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

51–60 of 229 posts

Re: Why we switched from Webpack to Vite

#51

Post by donjoe »

sunflowerdeath wrote: post #43

I have tried to use esbuild, and over the past 3 months I had at least a dozen times when it has compiled incorrect code that doesn't work or doesn't do what it's supposed to do. So despite the performance benefits, I was forced to go back to webpack, babel, and terser.

Did u try using typescript with esbuild? React + esbuild + typescript is a perfect combination for me. I had the chance to kick off a new project a few months ago and started with this stack. It needed roughly 50 lines of code to get a decent server side rendering development experience set up. Compile time is still below 200ms.

The only issues I had in the beginning was esbuild's compilation of typescript enums: the import order was off from time to time. Besides that, no issues. I am also super glad I do not need to configure webpack any longer.

Re: Why we switched from Webpack to Vite

#52

Post by bastijn »

Thanks for reminding me I'm getting old and corporate.

My first two thoughts were:

* Imagine all the smart people in webdev world would improve the existing tool rather than create a new one. [0]

* "if you do less, it will go faster". I.e. Vite is young and new, supports a subset of Webpack and of course boasts how fast it is. Yet my repos can't use it because it doesn't has the support it needs for my repo sizes with legacy stuff. Of course it is "on the roadmap" and by the time it will be supported Vite is as slow (if lucky) as Webpack. Doesn't matter though as a new tool will be there long before Vite reaches Webpack..

Yup. Getting old and also cynical in the evenings. Dammit!

[0] https://xkcd.com/927/

Re: Why we switched from Webpack to Vite

#53

Post by earthboundkid »

eliseumds wrote: post #46

I literally just spent days trying out Vite and comparing it to Webpack 5, and I can comfortably say that they are in two very distinct leagues. It isn't fair to compare Vite to a CRA build with Webpack. You can greatly improve Webpack's performance by: * Making sure `mode` is set to "development" (don't specify it all if in doubt) * Ditching babel-loader and using esbuild-loader instead * Adjusting build targets and…

If you figure out how to get Webpack to solve all these issues, that makes one working Webpack installation. When Vite solves their issues, all Vite installations will have the issues solved.

Re: Why we switched from Webpack to Vite

#54

Post by judofyr »

JMTQp8lwXL wrote: post #20
amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

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 imports. I often need to look into the webpack.config.js to understand how everything work. After: Use PostCSS and its tooling for CSS. Yes, there's now a separate process I also need to run in order to watch and build CSS. Yes, I can no longer `import "./style.css"` from the JavaScript files. But it's so much easier to reason about! The CSS tooling creates a CSS file; the JavaScript tooling creates a JavaScript file. Do I want to build SVG sprites? Well, that can very easily be a separate script which I can debug independently and _not_ couple into my builder's plugin system.

In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems. Once the successor to ESBuild comes out I will most likely be able to point it at index.js and everything will work.

Re: Why we switched from Webpack to Vite

#55

Post by zellyn »

zellyn wrote: post #5

I was a little surprised that Vite, which depends on esbuild and thus should know better, is written in Javascript. I presume this is a considered choice, and that what Vite does is unlikely to be on the critical path for edit/build/view cycle time…

Hmmm. I knew I was being a bit of a smartass with, “and thus should know better”, but I figured I mediated that in the second sentence, where I presumed they know what they're doing. ¯\_(ツ)_/¯

Re: Why we switched from Webpack to Vite

#56

Post by yepthatsreality »

jupp0r wrote: post #30
yepthatsreality wrote: post #7

> Esbuild is a JS bundler written in Go that bundles dependencies 10-100x faster than JavaScript based alternatives like Webpack and Parcel. A JS library calling a golang js-build tool to get the job done. Too funny.

This might shock you, but webpack runs on node/V8 which is written in C/C++.

Nope.

Re: Why we switched from Webpack to Vite

#57

Post by sjaak »

amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

“Only” 34mb for a hello world project? I can’t tell if you’re being ironic but I hope so!

Re: Why we switched from Webpack to Vite

#58

Post by yepthatsreality »

root_axis wrote: post #21
yepthatsreality wrote: post #7

> Esbuild is a JS bundler written in Go that bundles dependencies 10-100x faster than JavaScript based alternatives like Webpack and Parcel. A JS library calling a golang js-build tool to get the job done. Too funny.

Why is that funny? How is it conceptually different from any of the variety of scripting languages that call out to C bindings or binaries?

It’s funny because in order to compile/minify JS it passes said JS to golang which spits out JS to be run under JS. I’m not allowed to be amused by the circularity? Get a grip.

Re: Why we switched from Webpack to Vite

#59

Post by toddmorey »

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…

I knew someone would bring this comment.

Webdev can be broken, but doesn't have to be. I am currently having fun & feeling productive on both a large team project and some small personal projects.

Re: Why we switched from Webpack to Vite

#60

Post by yepthatsreality »

mavelikara wrote: post #10
yepthatsreality wrote: post #7

> Esbuild is a JS bundler written in Go that bundles dependencies 10-100x faster than JavaScript based alternatives like Webpack and Parcel. A JS library calling a golang js-build tool to get the job done. Too funny.

Many golang webapps use JS as their front-end language. Use the right tool to get the job done etc.

Being on the web it would be difficult not to no?
Post reply on HN