如何使用Web组件缓解JavaScript库膨胀？
快乐浪迹天涯海绵宝宝_243 发布于 2023-02-13 16:06作为一个试图找到一种方法来帮助内容作者通过创建(HTML)组件多年来开发和维护大型网站的人,我很高兴看到Web组件在w3c,google和mozilla上获得了关注.但在我看来,在规范中没有针对javascript库膨胀的措施.
假设我开发的组件A具有依赖性underscore.js并且想要使用组件B并且C依赖于lodash.js版本1.*等.
我没有看到任何标记依赖项和库版本的方法.当我们谈论有多个团队和利益相关者的网站时,这可能会导致巨大的图书馆膨胀.
目前的解决方案是在全球范围内对整个网站的批发客户框架进行标准化.当您在不同的服务器端框架LifeRay(如(java),EpiServer(.net),Django(python)等)中投入大量资源时,这很困难,每个框架都有首选的客户端库.
我认为Web组件是将服务器端框架与客户端代码分离的一种手段,但遗漏客户端依赖项处理是令人担忧的.
它是否符合规范,我已经错过了,或者是否有减轻这个问题的策略,我不知道？
[图书馆提到的只是示例.问题与框架,图书馆和服务器端语言无关]
更新 感谢大家回答.我很惊讶没有人提到Mozilla X-Tag或Google Polymer,这些都是最近的炒作.我完全接受了影子DOM,范围样式,自定义元素等的想法,但我没有看到任何关于如何处理JavaScript依赖关系的提及.正如@ Daniel-Baulig正确地写道,HTML Imports根本没有提到JavaScript.我承认这个问题几乎无法回答.但是,当他提到ES6模块时,我认为@ Daniel-Bailig是最接近的.我个人认为我们会在ES6模块和require.js之间找到一个可持续的解决方案.
-
这个问题一直困扰着我,特别是当面对维护许多开发人员触及的代码时.您经常会遇到一个解决方案中包含的多个JS库(其中一些基本上做同样的事情),更不用说在一个解决方案中使用的同一框架的不同版本.
我正在研究的或者更确切地说是"一种"潜在的解决方案是创建一种中介框架.
基本思想是编码"反对"中介(不直接访问/使用js库,但通过中介使用它),从而基本上使代码不可知(与其"父"库分离)并在下面包括中介实现.
这不会解决我/我们的直接问题或膨胀,但无论我编写的任何Web组件都能够运行跨框架.
这是一个小概念证明: Tagger Mediator POC
例如调解员包括:
JQuery(1.9.1)
Mootools(1.4.5)
原型(1.7.1.0)
YUI(3.10.3)
道场(1.9.1)
Ext(3.4.0)
Zepto(1.0)
但没有什么可以阻止任何人创建他们自己的调解框架,"抽象"其他调解员,嗯,所以潜在的东西也可能导致膨胀(使事情变得更糟而不是更好).
我想由你来制定自己的标准;)
2023-02-13 16:07 回答
蓝云2602884825_944 -
在当前的W3C规范中,似乎没有特定的方法来定义依赖关系甚至版本化它们.期望组件不使用任何库/依赖项或与它们紧密耦合.
这意味着每个主要库可能会带来他们自己的一组组件,期望这些库已经加载.
也许ES6模块在这方面提供了帮助,但是他们目前也没有提供任何版本控制机制.
所有人都说这个规格还处于初期阶段并且可能会发生变化.使用规范作者引入依赖关系问题可能会将该主题带到表中,甚至可能在规范固化之前解决.最终,使用不同的库在单个代码库中执行相同的任务一直是并将继续成为软件开发中的问题,无论平台和语言如何.您只需要同意在代码库中使用哪些框架/库,即使这意味着将您锁定在其他框架/库之外.
此外,如果您有兴趣为Web开发独立组件,您可能需要查看React库
2023-02-13 16:08 回答
iuang
京公网安备 11010802041100号