A halving of build time, for even a medium volume project, could be a big cost reduction. If those builds were much longer than 30sec, compounding through a CI pipeline with many changes, leads to much shorter cycle times, faster time to prod, faster to find and fix defects, which translates to much more than just infra cost reduction benefits. I created a visualization once, of the release pipeline for a big project, showing the feedback loops that exist and the compounding effects of small improvements like that. It was eye opening for me, and everybody.

Build time isn’t the only benefit, but consider that the author is from ByteDance and how large their projects are.

Another important callout is how in Vite, native ESM modules are used in dev which makes it very slow for large apps with thousands of modules. So cold start of dev can be important too.

In practice HMR is mostly what you need and Vite has it covered. But slow tends to accumulate slow.

I kinda prefer how vite handles things in dev by not bundling files. I work remote to my server, and I'd much rather download the few changed files vs a multi-deca-megabyte file.

How can a project have 2166 modules? Sounds more like a problem in software architecture than in tooling.

Don’t know what to tell you. This is an actual web application that has seen four years of development, a migration from vanilla Vue.js 2, to Nuxt, then an integration of Vuetify 2 (which is about the worst library I have ever had the misfortune of working with, and has a giant amount of runtime dependencies).

I wouldn’t say it’s too many modules. We heavily use code splitting, so most of the time, users will fetch only a few of these, and pages load quickly. Plus, there’s some dependencies we cannot get rid of that are quite heavy.

From my personal experience though, it’s nothing unusual really.

Do you have an idea of what kind of functionality all of those deps provide? It would be interesting to see a breakdown of where dep bloat typically comes from.

Yes, I just cannot share the flame graph publicly, but I can describe parts of it. A big chunk is taken up by the Mapbox GL SDK (Vector maps, 35%), Sentry (Telemetry and monitoring, 14%), and Vuetify (component framework, 10%). The rest are small dependencies and application code.

I'm happy I never did that planned Vuetify rewrite of my Vue 2 app, dodged a bullet there.

Sure did. We're completely locked in because Vuetify encourages you to use their components for everything from layouts to buttons, their styles are written in sass and depend on an outdated version of dart-sass, and use a half-assed version of Tailwind utility classes that creates conflicts on every level. And since they rewrote the framework completely for Vue 3, and took special care to make sure that every single darn prop is different, a migration is pretty much impossible without touching absolutely everything.

The only way out for us will be to get rid of vuetify components, one at a time, and introduce Tailwind with a prefix, until we can finally remove that mess.

The biggest recommendation I have is to stay away as far as you can from that library. I think that has been the worst technical decision I ever made at my job.

> Vue.js 2, to Nuxt, then an integration of Vuetify 2 (which is about the worst library I have ever had the misfortune of working with, and has a giant amount of runtime dependencies).

This is my experience with Vue overall, not just it's shitty ecosystem and libraries.

Heh... I'm just helping out on a TS project with 50k files/modules (over 1.5M lines), not counting the 200+ external dependencies (or their subdependencies).

That's not particularly high for a large scale web application where every file is a ES module, especially so if it includes dependencies.