如何使用Web组件缓解JavaScript库膨胀？ [英] How is JavaScript library bloat mitigated with Web Components?

问题描述

作为一个试图找到帮助内容作者通过创建（HTML）组件多年来开发和维护大型网站的方法的人，我很高兴看到Web组件在w3c，google和mozilla上获得了关注。但在我看来，在规范中没有针对javascript库膨胀的措施。

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.

假设我开发的组件 A ，其依赖 underscore.js 并希望使用和 C 的组件，它们依赖于 lodash .js 版本1. *等等。

我没有看到任何标记依赖项和库版本的方法。当我们谈论有多个团队和利益相关者的网站时，这可能会导致巨大的图书馆膨胀。

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.

目前的解决方案是在整个网络的批发客户框架上实现标准化网站，全球。当您在不同的服务器端框架中投入大量资源时很难，例如 LifeRay （java）， EpiServer （。 net）， Django （python）等，每个都有首选的客户端库。

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.

我将Web组件视为将服务器端框架与客户端代码分离的意思，但是省略客户端依赖性处理是令人担忧的。

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]

更新
感谢所有人的回答。我很惊讶没有人提到 Mozilla X-Tag 或谷歌聚合物最近一直在炒作。我完全接受了影子DOM，范围样式，自定义元素等的想法，但我没有看到任何关于如何处理JavaScript依赖关系的提及。正如@ Daniel-Baulig正确地写道， HTML Imports 根本没有提到JavaScript。我承认这个问题几乎无法回答。但是，当他提到ES6模块时，我认为@ Daniel-Bailig是最接近的。我个人认为我们会在ES6模块和require.js之间找到一个可持续的解决方案。

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.

推荐答案

在当前的 W3C规范似乎没有特定的方法来定义依赖关系甚至版本化它们。组件不会使用任何库/依赖项或与它们紧密耦合。

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.

也许 ES6模块在这方面提供了帮助，但是他们目前也没有提供任何版本控制机制。

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.

此外，如果您对开发感兴趣今天您已经可以查看 React library 的独立组件

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

这篇关于如何使用Web组件缓解JavaScript库膨胀？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！