之前写的文章急速 Js 全栈教程得到了不错的阅读量，霸屏掘金头条 3 天，点赞过千，阅读近万，甚至还有人在评论区打广告，可见也是一个小小的生态了；）。看来和 JS 全栈有关的内容，还是有人颇有兴趣的。今天看到的霸屏的，也是讲全栈的，见参考文章 7
接下来要写的是模块。JavaScript Module 真是很讨厌，但是不得不了解的话题。奇葩在于：
它一个非常老的语言，并且使用非常广泛
可是它很多年来也不支持模块。这得厂家当前是多大的心呢
再一个可是，它可以直接用现有的语言机制，实现自己的模块，这个就厉害了，因为它释放了社区的力量。事实证明，社区果然不可小看，这个年代，蚂蚁雄兵胜过大象的
再再一个但是，它的模块还可以有很多型的，这说的是分裂
这么多型的模块，还搞了各自独立的标准出来，这说的是整合
最近的 ES2017，终于在前端也有了媲美后端的模块，但是大家并不准备把它用起来，很多人表示需要继续 Webpack 玩转 ES6 模块。
把 ES6 模块真用的起来，可以不在乎 Webpack 等打包工具带来的加载优化，各种小文件不必打包这点来说，我看还得加上 HTTP/ 2 的配合就好很多了。这也是文章将要介绍的一个主旨吧。ES6 模块的引入，确实有可能对当前主流的打包模式有些影响，参考文章 6 内有所论述
文章自然也不少，但是写作此文的理由还是存在：
我还没有看到一个完整的全览，并且结合 HTTP/ 2 的更加没有看到。
而且，在我看来，即使有了 ES6 模块，也得了解和学习之前拼出来的各种模块，因为社区内的代码还大量的使用这样的模块，其中的一些设计模式，比如 IIFE，也是值得一看的。
看到 JS 社区的热情和推动力，相信 JS 发展的未来是美好的
参考文章不少, 其中模块历史和选型如下：
前端模块化开发那点历史
梳理的还是比较清晰
有点黑客精神的小伙伴，玩的很广谱
介绍 Bower
npm for Beginners: A Guide for Front-end Developers
Es6module 出来了，是否应该重新考虑打包的方案？
前后端分离 Vue + NodeJS(Koa) + MongoDB，从产品到开发，全栈实践没有看过的，不妨去看看。
提到模块，也不得不提到各种模块依赖管理工具，也还有前端工程化的内容。一个前端组件，却常常提到可以使用 npm 安装此组件，可是 npm 是后端的 nodejs 领域的东西啊，所以，这样的提法是有些令人困惑的。比如为什么 NPM 作为后端模块的管理工具，前端也在使用它，有什么优点和缺点，可以在这里了解显示情况：npm、bower、jamjs 等包管理器，哪个比较好用？, 还有这里 npm and the front end,NPM 官方也对 npm 在前端的使用，提出了自己的看法, 捎带着，也有前端自动化, 搜索词是 why a front end component install by npm, 对于喜欢 Google 发现的人来说，这类词很有用。
未来的文章的内容纲要:
最古老的模块加载 <script> 标签
此方法的若干问题
全局变量。全局命名污染和命名冲突
依赖管理。都需要 HTML 管理，而不是分层管理依赖，多文件加载次序非常关键
效率。太多 HTTP 请求，和并行加载效率低下
有问题引发的解决方法
命令空间，匿名闭包、依赖引入
当前主流的模块技术
YUI 方法，YUI Combo 方法
Nodejs 的做法，Commonjs 方案
Nodejs 借鉴，可以借鉴的（接口），不可以借鉴的（同步和异步）
Require.js 实践，AMD 和 CMD，依赖就近原则
从手写模块，到自动编译，Browerify,Webpack,Rollup
刚刚落地的模块技术
ES6 模块，官方发力，对现有技术的影响
弥补 ES6 问题，HTTP/2
最佳实践
写这篇文章，估计耗时 2 周左右。写预告的原因，是希望得到反馈，如果有些人支持的话，我就会写，如果大家兴趣缺缺，我也就不麻烦自己了。毕竟，自己搞懂是不必写作的，写了的话，就是希望可以讨论，可以得到反馈的。
可以通过点赞，来表明你的态度。