JavaScript模块化

最新推荐文章于 2025-03-26 02:15:31 发布

原创最新推荐文章于 2025-03-26 02:15:31 发布 · 289 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#ES6 #AMD #CMD #CommonJs #Js模块化

JavaScript/ES6/NodeJS 专栏收录该内容

79 篇文章

订阅专栏

本文介绍了JavaScript模块化的重要性，探讨了CSS模块化的挑战与解决方案，包括全局污染、命名混乱等问题。接着详细阐述了JavaScript模块化的历程，从早期的代码组织方式到CommonJS、AMD、CMD的发展，最后重点讲解了ES6模块化，它是目前浏览器端最权威的模块化方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这里写图片描述

一、基本介绍

1、模块化解决的问题：

1、文件依赖
2、命名冲突

2、web开发中模块化方案

前端使用ES6模块化
后端使用NodeJS中CommonJS

二、CSS模块化

1、基本介绍
CSS 是前端领域中进化最慢的一块。由于 ES2015/2016 的快速普及和Babel/Webpack 等工具的迅猛发展，CSS 被远远甩在了后面，逐渐成为大型项目工程化的痛点。也变成了前端走向彻底模块化前必须解决的难题。

CSS 模块化重要的是要解决好两个问题：CSS 样式的导入和导出。
灵活按需导入以便复用代码；导出时要能够隐藏内部作用域，以免造成全局污染。

Sass/Less/PostCSS 等前仆后继试图解决 CSS 编程能力弱的问题，结果它们做的也确实优秀，但这并没有解决模块化最重要的问题。

2、css模块化遇到了哪些问题
1)全局污染
CSS 使用全局选择器机制来设置样式，优点是方便重写样式。缺点是所有的样式都是全局生效，样式可能被错误覆盖，因此产生了非常丑陋的 !important，甚至 inline !important 和复杂的选择器权重计数表，提高犯错概率和使用成本。
2) 命名混乱
由于全局污染的问题，多人协同开发时为了避免样式冲突，选择器越来越复杂，容易形成不同的命名风格，很难统一。样式变多后，命名将更加混乱。
3) 依赖管理不彻底
组件应该相互独立，引入一个组件时，应该只引入它所需要的 CSS 样式。Saas/Less 很难实现对每个组件都编译出单独的 CSS，引入所有模块的 CSS 又造成浪费。JS 的模块化已经非常成熟，如果能让 JS 来管理 CSS 依赖是很好的解决办法。Webpack 的 css-loader 提供了这种能力。
4)代码压缩不彻底
主要体现在非常长的 class 名

3、解决方案

使用webpack中的css-loader
composes

三、JS模块化

1、早期代码组织方式
2、js模块化方案概述
Javascript自诞生以来,曾经很长的一段时间内。没有人把它当做一门真正的语言，认为他不过是一种网页小脚本而已。在Web1.0时代，这种脚本语言在网络中主要有两个作用管委流传，一个是表单校验。另一个是网页特效。由于语言的不起眼，在设计之初就没有考虑太多复杂的问题，导致它自身的各种陷阱和缺点被各种编程人员广为诟病。

JavaScript没有模块系统。没有原生的支持密闭作用域或依赖管理。
JavaScript没有包管理系统。不能自动加载和安装依赖
JavaScript没有标准库。除了一些核心库外，没有文件系统的API，没有IO流API等。
JavaScript没有标准接口。没有如Web Server或者数据库的统一接口。

javascript先天就缺乏一种功能：模块！在其他高级语言中java有类文件，Python有import机制，Ruby有require，PHP有include和require。而javascript在html文件中通过<script>标签来引入代码的方式显得杂乱无章。语言自身毫无组织和约束能力（在一个js文件中你是没有办法引入另外一个js文件的。）

基于对模块化的需求，社区不断的涌现出了大量模块化的方案。CommonJS的提出算是最为重要的里程碑了。

大概 09 年 - 10 年期间，CommonJS 社区大牛云集。CommonJS 原来叫 ServerJS，推出 Modules/1.0 规范后，在 Node.js 等环境下取得了很不错的实践。
09年下半年这帮充满干劲的小伙子们想把 ServerJS 的成功经验进一步推广到浏览器端，于是将社区改名叫 CommonJS，同时激烈争论 Modules 的下一版规范。分歧和冲突由此诞生，逐步形成了三大流派：

Modules/1.x 流派。这个观点觉得 1.x 规范已经够用，只要移植到浏览器端就好。要做的是新增 Modules/Transport 规范，即在浏览器上运行前，先通过转换工具将模块转换为符合 Transport 规范的代码。主流代表是服务端的开发人员。现在值得关注的有两个实现：越来越火的 component 和走在前沿的 es6 module transpiler。
Modules/Async 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范。这个观点下的典型代表是 AMD 规范及其实现 RequireJS。这个稍后再细说。
Modules/2.0 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范，但应该尽可能与 Modules/1.x 规范保持一致。这个观点下的典型代表是 BravoJS 和 FlyScript 的作者。BravoJS 作者对 CommonJS 的社区的贡献很大，这份 Modules/2.0-draft 规范花了很多心思。FlyScript 的作者提出了 Modules/Wrappings 规范，这规范是 CMD 规范的前身。可惜的是 BravoJS 太学院派，FlyScript 后来做了自我阉割，将整个网站（flyscript.org）下线了
很有趣的是FlyScript 作者在做自我阉割，将 GitHub 上的项目和官网都清空时，在官网上留下了这么一句话:“我会回来的，带着更好的东西”
CMD规范更多的来自于 Modules/2.0 的观点，但尽可能去掉了学院派的东西，加入了不少实战派的理念。

总结一下：
javascript模块化的概念是在Node（服务端的js）中被提出的，然后慢慢嫁接到浏览器端的。在嫁接的过程中出现了分歧，大致出现了两个不同的理念