Node.js 的出现，让 JavaScript 脱离了浏览器的束缚，进入了广阔的服务端开发领域。而 Node.js 对 CommonJS 模块化规范的引入，则更是让 JavaScript成为了一门真正能够适应大型工程的语言。
在 Node.js 中使用模块非常简单，我们日常开发中几乎都有过这样的经历：写一段 JavaScript 代码，require 一些想要的包，然后将代码产物 exports 导出。但是，对于 Node.js 模块化背后的加载与运行原理，我们是否清楚呢。首先抛出以下几个问题：
本篇文章，就会结合 Node.js 源码，探究一下以上这些问题背后的答案。
阅读全部
AMD 为浏览器端开发带来了诸多好处：模块声明、异步加载、依赖管理、bundle等，已经成为很多团队应用开发的标配。在正确的代码下，一切看起来都还好，但是当问题出现时，追查过程通常会令人头疼，此时Loader的提示信息对错误的追查非常关键。ESL 是熊厂应用得比较多的 AMD Loader，本篇blog试图对 ESL 的错误场景与信息提示策略，以及如何追查错误，进行简单的介绍。主要涉及以下3个方面：
先厚脸皮求关注。
首先，建议大家在开发中追查错误时，使用 chrome 浏览器的开发者工具。因为它对 re-throw 错误的 stack 跟踪与查看支持得比较好。
阅读全部在大部分单页式应用中，前端代码都是以 MV* 的结构来组织的，好处自然不必多说。在开始一个项目时，我们往往会将项目的业务功能纵向切分成多个子业务功能， 以模块的形式分配给团队各个开发人员，以达到最大的并行开发。随着业务的发展，新的项目也越来越多，我们会发现很多新的项目和现有的项目是有不少功能交集的。
从业务角度来看，一个项目就是由各个模块组合而成：A 项目由 m1, m2, m3 组合而成， B 项目则可能由 m1, m3, m4 组合而成。
在业务上将各个功能拆分明确后，很明显的 m1, m3 两个功能在 A 项目都是存在的，从工程角度来说，开发 B 项目的时候如果能够直接将A项目已经开发完毕的 m1, m3 直接复用， 那么必然是能够带来很明显的人力节约。
接下来就是从技术上去实现功能的复用，对于后端来说，通常的做法是服务化接口，而对于前端来说，我们目前的方案正是前端模块化：将功能打包为模块，发布至内部中央仓库， 使用方通过自己的方式（如：npm, bower, link[import], 百度的 edp, fis 等）导入模块包使用。
按照前端模块化的思路，开发新项目时，开发人员的工作从原来的开发所有功能变为：接入已有的功能模块，开发不存在的功能模块。
阅读全部为了不被喷得太惨，给标题加了这么多的限制定语也是相当不容易的了。此文讨论的是我所处的环境下对JavaScript构建的一些简单探索，因此有相当多的前提限制。
首先，何为大型。从我们的系统来看，20多个业务模块，近100个页面组成的单页系统，对应的业务源码代码量如下：
ESL 是一个浏览器端、符合AMD的标准加载器，适合用于现代Web浏览器端应用的入口与模块管理。
通过右键另存的方式可以下载ESL:
今天，ESL release 了 2.0.4。到这里本应该完了，不过好像内容少了点。为了凑数，还是多扯几句吧：
阅读全部理由很简单，因为太大了。RequireJS 经过语法压缩和 GZip 后，体积超过了 6k。RequireJS 最新版本已经降到了 6.1k，在 2012 年底时候的版本是接近 7k。由于下面的一些期望，让我们觉得这个体积比较大：
既然这个体积比较大，那多少合适呢。当时我们拍了脑袋，一个 Loader，各种流转与依赖处理，两种 require，URL 查询，再加上异步的插件机制，就算看起来比较复杂，GZip 后 3k 应该没问题。开发时间我们规划了一个月，主要还是为编写测试用例留出一些时间。
后来...后来，事情远远超出了想象。我们开发了 AMD Loader: ESL，包括前前后后的一些改进和 new feature，开发过程持续了一年半多。现在虽然是一个特性稳定版本，但是仍未结束，可预见的未来还有 shim 的支持需要添加。至于体积，我们也没控制住，在每个我们觉得无法或缺的 feature 中，它的体积最终是 3.4k。如果你觉得所有的错误信息你都不需要，那么可以选择 min 版本，体积是 3.1k，超过最初的梦想并不太多。可见男人的承诺多半不靠谱。