> But is it a reasonable alternative to build an alternative to webpack yourself? Before code-splitting, yes, it was quite easy (not much harder than building

> But is it a reasonable alternative to build an alternative to webpack yourself? Before code-splitting, yes, it was quite easy (not much harder than building a makefile). Webpack is difficult and complex because it has to cater to literally thousands of tools (https://www.npmjs.com/search?q=webpack%20plugin https://www.npmjs.com/search?q=webpack%20plugin). An individual project can choose to use a simple js-only bundler and a copy command for static assets. There was nothing to release there, however - we just wrote the equivalent of a makefile. It was not a big engineering project at all. Would I do the same thing today? No, because of code splitting and because there are simpler, faster bundlers out there already (esbuild). > Will the improvements in devex really outweigh the engineering hour investment? IME the answer is almost always no, what usually happens is you get a half-baked, non-documented/tested system, and reading through this thread, I'm not sure any of the anti-framework people have shown convincing examples where they did better than an OTS framework. This is, where I think we differ. I think much more often than not, we already have half-baked, poorly documented systems which we insist on trying to use, even if the team is quite capable of building something better. This is also one of the reasons we have JS fatigue - its not because the language or even the browser somehow prevents something better from being built, its because we keep insisting on using poorly designed tools or tools designed to solve problems that large companies have but we don't really have.