精读 js 板块化发展

  • 时间:2018-06-06 01:54 作者:freefish 来源:freefish 阅读:198
  • 扫一扫,手机访问
摘要:1 引言如今,Javascript 板块化规范非常方便、自然,但这个新规范仅执行了2年,就在 4 年前,js 的板块化还停留在运行时支持,10 年前,通过后台模版定义、注释定义板块依赖。对经历过来的人来说,历史的板块化方式还停留在脑海中,反而新上手的同学会更快接受现代的板块化规范。但为什么要理解 J

1 引言

如今,Javascript 板块化规范非常方便、自然,但这个新规范仅执行了2年,就在 4 年前,js 的板块化还停留在运行时支持,10 年前,通过后台模版定义、注释定义板块依赖。对经历过来的人来说,历史的板块化方式还停留在脑海中,反而新上手的同学会更快接受现代的板块化规范。

但为什么要理解 Javascript 板块化发展的历史呢?由于凡事都有两面性,理解 Javascript 板块化规范,有利于我们思考出更好的板块化方案,纵观历史,从 1999 年开始,板块化方案最多维持两年,就出现了新的替代方案,比原有的板块化更清晰、强壮,我们不可以被现代板块化方式限制住思维,由于现在的 ES2015 板块化方案距离发布也仅仅过了两年。

2 内容概要

直接定义依赖 (1999): 因为当时 js 文件非常简单,板块化方式非常简单粗暴 —— 通过全局方法定义、引使用板块。这种定义方式与现在的 commonjs 非常神似,区别是 commonjs 以文件作为板块,而这种方法能在任何文件中定义板块,板块不与文件关联。

闭包板块化模式 (2003): 使用闭包方式处理了变量污染问题,闭包内返回板块对象,只要对外暴露一个全局变量。

模版依赖定义 (2006): 这时候开始流行后台模版语法,通过后台语法聚合 js 文件,从而实现依赖加载,说实话,现在 go 语言等模版语法也很流行这种方式,写后台代码的时候不觉得,回头看看,还是挂在可维护性上。

注释依赖定义 (2006): 几乎和模版依赖定义同时出现,与 1999 年方案不同的,不仅仅是板块定义方式,而是终于以文件为单位定义板块了,通过 lazyjs 加载文件,同时读取文件注释,继续递归加载剩下的文件。

外部依赖定义 (2007): 这种定义方式在 cocos2d-js 开发中普遍用,其核心思想是将依赖抽出单独文件定义,这种方式不利于项目管理,毕竟依赖抽到代码之外,我是不是得两头找呢?所以才有通过 webwpack 打包为一个文件的方式暴力替换为 commonjs 的方式出现。

Sandbox模式 (2009): 这种板块化方式很简单,暴力,将所有板块塞到一个 sanbox 变量中,硬伤是无法处理明明冲突问题,毕竟都塞到一个 sandbox 对象里,而 Sandbox 对象也需要定义在全局,存在被覆盖的风险。板块化需要保证全局变量尽量干净,目前为止的板块化方案都没有很好的做到这一点。

依赖注入 (2009): 就是大家熟知的 angular1.0,依赖注入的思想现在已广泛运使用在 react、vue 等流行框架中。但依赖注入和处理板块化问题还差得远。

CommonJS (2009): 真正处理板块化问题,从 node 端逐步发力到前台,前台需要用构建工具模拟。

Amd (2009): 都是同一时期的产物,这个方案主要处理前台动态加载依赖,相比 commonJs,体积更小,按需加载。

Umd (2011): 兼容了 CommonJS 与 Amd,其核心思想是,假如在 commonjs 环境(存在 module.exports,不存在 define),将函数执行结果交给 module.exports 实现 Commonjs,否则使用 Amd 环境的 define,实现 Amd。

Labeled Modules (2012): 和 Commonjs 很像了,没什么硬伤,但生不逢时,碰上 Commonjs 与 Amd,那只有被人遗忘的份了。

YModules (2013): 既然都出了 Commonjs Amd,文章还列出了此方案,肯定有其独到之处。其核心思想在于用 provide取代 return,能控制板块结束时机,解决异步结果;拿到第二个参数 module,修改其余板块的定义(尽管很有拓展性,但使用在项目里是个搅屎棍)。

ES2015 Modules (2015): 就是我们现在的板块化方案,还没有被浏览器实现,大部分项目已通过 babel 或者 typescript 提前体验。

3 精读

本次提出独到观点的同学有:@流形@黄子毅@苏里约@camsong@杨森@淡苍@留影 精读由此归纳。

从语言层面到文件层面的板块化

从 1999 年开始,板块化探究都是基于语言层面的优化,真正的革命从 2009 年 CommonJS 的引入开始,前台开始大量用预编译。

这篇文章所提供的板块化历史的方案都是逻辑板块化,从 CommonJS 方案开始前台把服务端的处理方案搬过来之后,算是看到标准物理与逻辑统一的板块化。但之后前台工程不得不引入板块化构建这一步。正是这一步给前台开发无疑带来了诸多的不便,尤其是现在我们开发过程中经常为了优化这个工具带了很多额外的成本。

从 CommonJS 之前其实都只是封装,并没有一套板块化规范,这个就有些像类与包的概念。我在10年左右使用的最多的还是 YUI2,YUI2 是使用 namespace 来做板块化的,但有很多问题没有处理,比方多版本共存,因而后来 YUI3 出来了。

YUI().use('node', 'event', function (Y) {

YUI3 的 sandbox 像极了差不多同时出现的 AMD 规范,但早期 yahoo 在前台圈的影响力还是很大的,而 requirejs 到 2011 年才诞生,因而圈子不是使用着 YUI 要不就自己封装一套 sandbox,内部用 jQuery。

为什么板块化方案这么晚才成型,可可以早期应使用的复杂度都在后台,前台都是非常简单逻辑。后来 Ajax 火了之后,web app 概念的开始流行,前台的复杂度也呈指数级上涨,到今天几乎和后台接近一个量级。工程发展到肯定阶段,要出现的必然会出现。

前台三剑客的板块化展望

从 js 板块化发展史,我们还看到了 css html 板块化方面的严重落后,如今依赖编译工具的板块化加强在未来会被标准所替代。

原生支持的板块化,处理 html 与 css 板块化问题正是以后的方向。

再回到 JS 板块化这个主题,开头也说到是为了构建 scope,实则提供了业务规范标准的输入输出的方式。但文章中的 JS 的板块化还不等于前台工程的板块化,Web 界面是由 HTML、CSS 和 JS 三种语言实现,不管是 CommonJS 还是 AMD 包括之后的方案都无法处理 CSS 与 HTML 板块化的问题。

对于 CSS 本身它就是 global scope,因而开发样式能说是喜忧参半。近几年也涌现把 HTML、CSS 和 JS 合并作板块化的方案,其中 react/css-modules 和 vue 都为人熟知。当然,这一点还是非常依赖于 webpack/rollup 等构建工具,让我们意识到在 browser 端还有很多本质的问题需要推进。

对于 css 板块化,目前不依赖预编译的方式是 styled-component,通过 js 动态创立 class。而目前 css 也引入了与 js 通信的机制 与 原生变量支持。未来 css 板块化也很可可以是运行时的,所以目前比较看好 styled-component 的方向。

对于 html 板块化,小尤最近爆出与 chrome 小组调研 html Modules,假如 html 得到了浏览器,编辑器的板块化支持,未来可可以会取代 jsx 成为最强大的板块化、模板语言。

对于 js 板块化,最近出现的

最新发布的资讯信息
【系统环境|】WEB前端学习:JS实现中文简体繁体切换(2019-08-22 12:38)
【系统环境|服务器应用】前台开发入门到实战:HTML5语义化元素你真的用的正确吗?(2019-08-22 04:16)
【系统环境|服务器应用】Vue仿微信app页面跳转动画(2019-08-22 04:16)
【系统环境|服务器应用】webstorm使用快捷键快速修正单个文件的style(2019-08-22 04:16)
【系统环境|服务器应用】程序员从学生到阿里经历的5次蜕变:海阔凭鱼跃,天高任鸟飞(2019-08-22 04:16)
【系统环境|服务器应用】var、let、const的区别(2019-08-22 04:16)
【系统环境|服务器应用】mini-ui加载框Indicator 被遮挡问题(2019-08-22 04:15)
【系统环境|服务器应用】【对讲机的那点事】玩对讲机,对于对讲机的亚音你理解吗?(2019-08-22 04:15)
【系统环境|服务器应用】前台中高级面试,内功心法(上)(2019-08-22 04:15)
【系统环境|服务器应用】17、改进轮播图之功能封装(2019-08-22 04:15)
手机二维码手机访问领取大礼包
返回顶部