Why we switched from Webpack to Vite

>Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed.

Well they can't get worse than now... 234mb for a friggin hello world app

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?

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

I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.

> Very few fields work like this.

Quite the opposite; I would argue that webdev is basically rediscovering the whole shebang, but decades later.

Modern webdev with transpilation, linking, pruning, compilation to WASM etc. starts to dreadfully look like the classical native development paradigm.

> you also have your build code, oddly dictating the organization of your source code

It... really doesn't? You generally have an entry point file - which can be any file, you just have to specify it to your build system - and import statements are followed from there on. If anything you could argue the JS build ecosystem is too flexible (which is one of the things esbuild is pushing back against). I've never heard someone criticize it for being too opinionated.

> For extra fun, some libraries don't build with build system a, others require build system b

I've literally never encountered this problem. Library authors virtually always ship least-common-denominator JS that will work without using a build system at all, and then build systems know how to handle lots of different variations of JS and converge them into a single representation. Compatibility is not an issue that exists in my experience.

> The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all.

Now you're just airing your own personal beef which doesn't actually have anything to do with the original topic.

For personal projects I just use plain javaScript, ES5 even, without any compile steps, everything loads instantly and runs on every browser that supports JavaScript, and the development can be set up in any environment/OS without headaches. I do use minification for production but that is not really necessary if the browser supports loading JS-script tags async (all major browsers). The bundle gets very small without any frameworks attached. Debugging is easy with the browser built in dev-tools - with small error messages that always have the correct line (eg. no source maps). I'm currently working on a 100,000+ line JS project that uses the plugin pattern with script tags and it's very manageable, adding new features is fast and fun. There are of course trade-offs, I can't just "npm install react-x-y-z", but the browser API's are extensive, you can do just about anything on the front-end with just the native browser components and API's.

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.

I see you have never worked on a C/C++ project.

I find it useful to have my vendor dependencies compiled and watched for debugging. There are always bugs in deps or poor error messages, and sometimes the dev tools debugger doesn’t work properly, so being able to modify a dev is nice.

Of course it would prob be better if this was a toggle.

I think webpack module federation may improve this situation too. I used webpack all plugin previously to speed up vendor dep compilation.

Thing about webpack though is it’s so complex how all this works that I always have to revisit it every few months to jog my memory.

We need simpler abstractions on top. Next is nice but still, if you need to dive deeper it’s painful.

I think in like 20 years time we will probably be able to get rid of all of this tool chain and the new kids will never know the pains we went through.

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

Oh god, this is a giant red flag. This is precisely one of my biggest gripes with Quasar (a Vue framework), which, on top of webpack/vue adds its own config that are intermingled with vue's and webpack's, and its honestly a mess, and oftentimes just straight up makes problems harder to solve.

I am obviously not railing against config dedicated to a single tool in a toolchain, but the way you described it rings a bell, especially the "unpredictability".

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

This also seems to confirm my and other's suspicion, that the tool isn't really "deliver-grade".

>If you hit a wall, install speed-measure-webpack-plugin to get some help.

But on the other hand, this is at least the fifth plugin I have heard someone recommend, dedicated just to profiling Webpack.

What do you think about the time difference shown in the article? I sort of feel it's a bit disingenuous since the test included a lot of other variables, but it seems hard to argue against it if it's this plain. Is this a config issue, or a "most commonly used loader" issue...?

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.

> 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 handle a set of use cases you have.

Generally I think this is good advice for tools--stick with the mature thing. But my former company's webpack builds were 30+ minutes for a relatively simple site. No doubt something was misconfigured, but you really have to be a webpack expert to get any sort of insight into where the time is going, and even then it may not be especially actionable (or at least not obviously so). In our case, we were using a monorepo and we didn't have something like Bazel, so this was painful for backend engineers, data scientists, etc--not just frontend engineers.

Maybe our case was pathological, but we would have saved a ton of time moving to esbuild and building whatever additional features we needed from scratch.