How is JavaScript library bloat mitigated with Web Components?

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 😉

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)