Why we switched from Webpack to Vite • Hacker News Board

Re: Why we switched from Webpack to Vite

#41

Post by temuze » Wed, Apr 28, 2021, 8:02 PM UTC

TurningCanadian wrote: post #4

For people already on webpack, there's esbuild-loader ( https://github.com/privatenumber/esbuild-loader )

We recently switched from ts-loader to esbuild-loader. It was super easy and it halved our build time with zero complications. Highly recommend.

Re: Why we switched from Webpack to Vite

#42

Post by kall » Wed, Apr 28, 2021, 8:03 PM UTC

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…

Have you seen the android build system? I mean what the hell is a gradle wrapper. At least js tools are configured in .json or .js files not in a special purpose programming language.

I don‘t mean to discuss which system is too complicated and which is not just to point out a lot of real world build systems are on that level.

Re: Why we switched from Webpack to Vite

#43

Post by sunflowerdeath » Wed, Apr 28, 2021, 8:04 PM UTC

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.

Re: Why we switched from Webpack to Vite

#44

Post by uhhhhhhhhhhhhhh » Wed, Apr 28, 2021, 8:04 PM UTC

jupp0r wrote: post #26

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 see you have never worked on a C/C++ project.

Yeah this appears to be more or less the essential complexity of build+link

Re: Why we switched from Webpack to Vite

#45

Post by vijaybritto » Wed, Apr 28, 2021, 8:07 PM UTC

I recently ported a microfrontend based frontend to webpack 5 and replaced babel/terser with esbuild and the builds are 50%-60% faster now. I couldnt replace webpack because I am using Module Federation which is not available in other bundlers. Would recommend this approach if not possible to fully replace webpack.

Re: Why we switched from Webpack to Vite

#46

Post by eliseumds » Wed, Apr 28, 2021, 8:08 PM UTC

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 making sure polyfills are not added in development

* Making sure you don't import the entirety of libraries like Lodash and MomentJS (prefer date-fns)

* [FUTURE] We'll soon be able to tell Webpack to output ES modules just like Vite [1]

Vite still has many problems:

* It just isn't suitable for proper server-side rendering, we'd need access to chunk names at build time

* It has a weird mix of own and Rollup config settings that seems somewhat unpredictable

* Many open issues regarding module imports, for ex, when a CJS module imports an ES one [2]

Our current bottleneck with Webpack is actually sass-loader, taking at least 70% of the time during a fresh build, and we'd have the same problem with Vite.

Something else that is worth pointing out is the ecosystem: Webpack's community has built tons of plugins for basically any use case you can imagine, and version 5 supports module federation, persistent caching, externals (very handy when doing SSR), customizable filename generators, performance hints, etc etc. Totally different game.

Try to keep your build config simple, avoid too many loaders, plugins, and you should be fine 99% of the time. If you hit a wall, install speed-measure-webpack-plugin to get some help.

[1] https://github.com/webpack/webpack/issues/2933

[2] https://github.com/vitejs/vite/issues?q=is%3Aissue+is%3Aopen...

Re: Why we switched from Webpack to Vite

#47

Post by krapp » Wed, Apr 28, 2021, 8:09 PM UTC

napsterbr wrote: post #25

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…

> The webdev ecosystem is so broken Allow me to correct this statement: The Javascript ecosystem is so broken. Working with Clojurescript and Elm is an experience that will make most developers fall in love with web development again.

Hate to break it to you but Clojurescript, Elm and the whole paradigm of "compile to JS" languages are part of what is broken about the javascript ecosystem. So much unnecessary complexity and energy wasted making javascript pretend to be something it isn't and to make it do things it was never meant to do, pressing a small, simple and powerful scripting language into the service of the profane eldritch abomination that is Enterprise Development.

Re: Why we switched from Webpack to Vite

#48

Post by jitl » Wed, Apr 28, 2021, 8:09 PM UTC

We just switched from TypeScript/ts-node to esbuild for server-side code at Notion; it's been great. Would love to see the same kind of speed wins for our clients :')

Re: Why we switched from Webpack to Vite

#49

Post by ballenf » Wed, Apr 28, 2021, 8:10 PM UTC

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.

Any specific scenarios where it fails? We're using it across a wide codebase and several teams and I haven't seen or heard that issue.

Re: Why we switched from Webpack to Vite

#50

Post by Kaze404 » Wed, Apr 28, 2021, 8:12 PM UTC

the_gipsy wrote: post #40

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…

Then also make unit, integration, and e2e work with all the transpiling. Good luck with sourcemaps!

You enable sourcemaps on Webpack with `devtool = "eval-source-map"` in your config, and I'm not sure how you expect transpiling to be a problem with testing considering your tests are also transpiled.