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

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