Como o bloat da biblioteca JavaScript é atenuado com os Web Components?

Como alguém que tentou encontrar uma maneira de ajudar os autores de conteúdo a desenvolver e manter grandes sites criando componentes (HTML) por anos, estou realmente empolgado em ver os componentes da web ganhando espaço no w3c, no google e no mozilla. Mas parece-me que, não há medida contra o inchaço da biblioteca javascript nas especificações.

Diga que eu desenvolvo componentesA que tem uma dependência paraunderscore.js e quer usar componentesB eC que tem dependências emlodash.js versão 1. *, etc.
Eu não vejo nenhuma maneira de sinalizar dependências e versões de biblioteca. Isso pode levar a um enorme inchaço na biblioteca quando falamos de sites com várias equipes e interessados.

A solução atual é padronizar em uma estrutura de cliente por atacado para todo o site, globalmente. Isso é difícil quando você investiu recursos substanciais em diferentes estruturas do lado do servidor, comoLifeRay (Java),EpiServer (.líquido),Django (python) etc. cada um com bibliotecas preferenciais do lado do cliente.

Eu vejo os componentes da web como um meio de dissociar as estruturas do lado do servidor do código do lado do cliente, mas a omissão do tratamento de dependência do lado do cliente é preocupante.

É nas especificações e eu perdi isso, ou existe uma estratégia para mitigar esse problema, que eu não conheço?

[AS BIBLIOTECAS MENCIONADAS SÃO APENAS EXEMPLOS. A QUESTÃO É AGNÓSTICA PARA O QUADRO, BIBLIOTECA E LINGUAGEM DO LADO DO SERVER]

ATUALIZAR Obrigado a todos por responder. Estou surpreso que ninguém mencioneTag X do Mozilla ouGoogle Polymer que tem sido todo o hype ultimamente. Eu compro completamente a idéia de sombra DOM, estilos de escopo, elementos personalizados etc. mas em nenhum lugar eu vejo qualquer menção de como lidar com dependências de JavaScript. Como @ Daniel-Baulig escreve corretamenteImportações HTML não menciona JavaScript em tudo. Eu reconheço que esta pergunta é quase impossível de responder. No entanto, eu acho @ Daniel-Bailig veio o mais próximo, quando ele menciona módulos ES6. Pessoalmente, acho que encontraremos uma solução sustentável em algum lugar entre os módulos ES6 e o ​​require.js.

questionAnswers(7)

yourAnswerToTheQuestion