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 components gaining tracction at w3c, google and mozilla. But it seems to me that, there is no measure against javascript library bloat in the specifications.

Say that I develop component A which has a dependency for underscore.js and want to use components B and C which have dependencies on lodash.js version 1.*, etc.
I don't see any way to flag dependencies and library versions. This could lead to huge library bloat when we talk about web sites with multiple teams and stake holders.

The current solution is to standardize on a wholesale client framework for the entire web site, globally. This is difficult when you have invested substantial resources in different server-side frameworks like LifeRay (java), EpiServer (.net), Django (python) etc. each with preferred client-side libraries.

I see web components as a mean to decouple server-side frameworks from client-side code, but the omission of client-side dependency handling is worrisome.

Is it in the specifications and I have missed it, or is there a strategy to mitigate this issue , that I'm not aware of?

[THE LIBRARIES MENTIONED ARE JUST EXAMPLES. THE QUESTION IS AGNOSTIC TO FRAMEWORK, LIBRARY AND SERVER-SIDE LANGUAGE]

UPDATE Thanks to all for answering. I'm surprised no one mention Mozilla X-Tag or Google Polymer which has been all the hype lately. I completely buy into the idea of shadow DOM, scoped styles, custom elements etc. but nowhere do I see any mention of how to deal with JavaScript dependencies. As @Daniel-Baulig correctly writes HTML Imports doesn't mention JavaScript at all. I acknowledge this question is almost impossible to answer. However, I think @Daniel-Bailig came the closest, when he mention ES6 Modules. I personally think that we will find a sustainable solution somewhere between ES6 Modules and require.js.

Answer 1

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 ;)

Answer 2

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