How is JavaScript library bloat mitigated with Web Components?

I've had similar misgivings about web-components myself, but then I started working with third-party React components. They have the same problems in that they bring along all their own dependencies. But worse than that, because React doesn't like living with other versions of React, React components must list React as a Peer Dependency. This means that you are forced to use the same version of React as your third-party components.

So my conclusion is that this is in fact a feature of web-components! Every Custom Element can have it's own dependencies entirely independent from the rest of your app. I consider third-party components to be the main use-case for Web Components; where the consumer wants to be able to use a component with as little friction as possible. Sure there will be some duplicate code, but the component consumer doesn't need to know or care. I think that component authors will deal with this is by using smaller modules in their components. For example, instead of using React they could use something like Snabbdom.

If you are building an entire application out of web-components that you control, you can still use a bundling tool like Browserify or WebPack to manage your dependencies. These will allow you to override certain modules so that you can even force third-party components to use the same versions as the rest of your app (see: https://www.npmjs.com/package/aliasify). That might break some modules, but that's life.

In the current W3C spec there does not seem to be a specific way to define dependencies or even version them. Components are expected to not make use of any libraries/dependencies or to be tightly coupled with them.

This means that each major library will probably bring their own set of components with them that expect those libraries to have been loaded.

Maybe ES6 Modules provide help in this regard, but then again they currently also don't provide any versioning mechanisms.

That all said the spec is in a pretty early stage and is likely to change. Bringing the dependencies issue up with the spec authors might bring that topic to the table and might even solved before the spec solidifies. In the end using different libraries to perform the same task within a single code base has always been and will continue to be a problem in software development, regardless of platform and language. You will just have to agree upon which frameworks/libraries to use within your codebase, even if that means locking you out of others.

Also, if you are interested in developing independent components for the web already today you might want to take a look at the React library

This is an issue that's been bothering me as well for a while, esp when faced with maintaining code that's been touched by numerous developers. You often encounter multiple JS libraries (some of which essentially does the same thing) included in one solution, not to mention even different versions of the same framework used in one solution.

The or rather "a" potential solution that I am looking at is to create a type of mediator framework.

The basic idea is to code "against" the mediator (never accessing/using a js library directly, but using it via the mediator), thereby essentially making the code agnostic (decoupled from its "parent" library) and including a mediation implementation underneath.

This wont address my/our immediate problem or bloat, but whatever web component I write will be able to run cross framework.

Here is a little proof of concept: Tagger Mediator POC

E.g. mediators included for:

JQuery (1.9.1)

Mootools (1.4.5)

Prototype (1.7.1.0)

YUI (3.10.3)

Dojo (1.9.1)

Ext (3.4.0)

Zepto (1.0)

But nothing stops anyone to create their own mediation framework, which "abstracts" other mediators, hmmm, so potentially something that can contribute to the bloat as well (making things worse rather than better).

I guess its up to you to set your own standards ;)