Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

依赖与生态圈

  很多控件库都声称自己是无依赖的,比起「基于 jQuery 的控件库」听起来要厉害得多。但无依赖的东西真的就比有依赖的好么?显然不见得!实际上很多所谓无依赖的库并不是真正的无依赖,而是内置一套轻量级的依赖,这种做法比外部依赖还凶残。
  对于控件库这种东西,里面总是充满了 DOM 操作。无依赖就意味着必须手写兼容的 DOM 操作,或者自带一套 DOM 操作的封装。然而每个不同的「无依赖」控件库作者都有一套自己的 DOM 操作兼容方案。如果一个项目中引入了 10 个不同作者开发的「无依赖」控件就可能会引入 10 套 DOM 操作兼容方案。这就造成了大量的代码冗余。
  代码冗余还不是「无依赖」最大的坑,如果仅仅是冗余,勉强还是能接受的。最大的坑在于每个作者提供的 DOM 操作兼容方案都不完美。至少和 jQuery 那「兼容 IE11 的 IE8 模式下的 xxx 问题」这种程度的兼容是没法比的。也不是说 jQuery 这么丧心病狂的兼容就是好,其实它自己也因此损耗的很多性能。但至少从我的经验看来,「无依赖」的库很容易出问题。
  其实「依赖」并不会阻碍通用性。假如一个项目中已经有了自己一套完善的 DOM 操作兼容方案,那么只要将这套方案包裹上一层 jQuery 风格的 API 即可兼容基于 jQuery 的各种插件。但我不太推荐这么干,因为绕的弯太大了。而且 jQuery 插件一直是我反感的东西,或者说是 jQuery 的生态圈太乱了。前几年 jQuery 大行其道的时候,满大街都是一些连原生 DOM 操作都没搞明白的群体搞出的低质量 jQuery 插件。整个 jQuery 生态圈因此变得非常混乱,同一个功能有一大堆轮子被造出来,然而却没一个能用的。
  如果有一个好的生态圈,即使有「依赖」又如何?整个项目基于某个生态圈是非常自然的事情。「原生」实际上也是个生态圈,但是「原生」的操作大多是在 DOM 上扩展的,而 DOM 扩展本身因为兼容性问题而无法完美模拟,所以原生这个生态圈目前几乎是无法使用的状态。如果不考虑兼容性问题,我确实更喜欢「无依赖」的东西。但现实总是不会让我如愿,至少在 IE8 还占国内市场 25% 的今天是如此。
网名:
34.203.213.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^