Why we switched from Webpack to Vite

Core team on Marko and author of Solid. Vite is exactly the sort of project we've been looking for.

Sure I love coming up with the perfect Rollup setups to produce the smallest application bundles. But Vite closed the loop we were looking for in terms of offering low config client/server applications with both ease of use and great flexibility.

You can see the focus and care put into Vite to make it easier to address the complexity of configuration. We still have plugins/starter templates for Webpack and Rollup, but for the average developer getting started with these frameworks Vite just gives so much out of the box. It really gives the ease of something like Parcel, with the ability to expand. This makes it far superior to solutions like CRA which forced monkey patching or ejection.

We've already seen through meta-frameworks like Next that there is a big desire here, and what at one point seemed like a huge undertaking for a historically single developer project like Solid, is suddenly becoming a reality. And others have the ability to build and share these setups as well.

Evan and the rest of those working on Vite have my thanks and my gratitude.

Hi Evan!

I just wanted to thank you for your contributions to frontend development. Vue has had a huge positive impact on my day-to-day work. For me it’s truly a joy to work with and I am in debt to you and all Vue contributors. Vite makes me exited about tooling in a way that hasn’t happen in quite a while. Speed is indeed a feature.

So thank you for the great work you are doing and keep it up!

First of all thank you for writing so many useful open-source software.

Anyway since you are here is there any reason why Vite won't run with Vue 2.x? I tried Vue 3 with Vite and I was blown away how much dev time it saves. No startup time, no compile time.. but we have thousand and thousands of line of Vue 2 that isn't going to be ported to V3 anytime soon and it kills me that I have to waste so much time looking at webpack compiling all the vue files everytime I load it.

Is this technically impossible to make Vite work with Vue 2 or is it because the community has moved away from V2 and don't want to spend any time on V2 tooling? Thanks.

Well said – everything new does not need to be a replacement for something else. Options/choices are good, especially because each one can lean into a different solution space.

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?

>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

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.

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

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

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.

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.

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

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

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

You can at later rollup hooks (it doesn't make sense to access chunks that don't exist yet).

Actually, there are SSR frameworks being built on top of Vite such as SvelteKit [1] or vite-plugin-ssr [2] (vite-plugin-ssr is not a framework but gives you a similar DX than Nuxt/Next.js; I'm its author), and many people are implementing custom SSR solutions.

Join our Discord #ssr channel and ask us questions https://discord.gg/PkbxgzPhJv ;-).

[1]: https://github.com/sveltejs/kit

[2]: https://github.com/brillout/vite-plugin-ssr

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.

Apropos of that, Yarn allows use of Prolog to ensure constraints across dependencies

I believe that SICP handled these sentiments very early on in the book.

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

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.

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