How is JavaScript library bloat mitigated with Web Components?

Question

As someone who has tried to find a way to help content authors develop and maintain big web sites by creating (HTML) components for years, I\'m really excited to see web compone

Answer 1

IMHO the issue you described always exists in frontend and not directly related to web components, but web components do make this even worse.

Say if you rely on component A and B which all relies on lodash, unless A and B both set lodash to peer dependencies (which makes them look like plugins like most jquery plugins do), then you can include one copy of lodash, otherwise, A and B are meant like black box to you. Though bundlers may do some post-build processing like tree shaking/dead code elimination to help mitigate this, but this could never 100% work, e.g. A and B both rely on two different versions of lodash.

Why web components make this even worse? the goal of WC is to provide a framework agnostic way to reuse UI components, say if i use vue and a bunch of vue components, my bundled js ends up with these components and a single vue runtime cuz vue is a peer dep in these components. Now if i use WC and a bunch of WC components, i will most likely end up with a larger bundled js. For example, can create a simple lit-element WC component with a simple button, then build the project and see how the bundle js is much larger. Some framework may take a different approach, vue for example, still requires you to add vue as an external framework to run vue based WC, which doesn't save you one byte if you switch vue to WC. Also, sharing styles is another problem in WC in terms of reducing bundle size.

My company uses bootstrap and react, our app is bundled with 1 bootstrap, 1 react and many external react components, which already ends up to be 3.5mb js/css, i doubt we can do the same thing in WC in 3.5mb.