原题
我对模块化的发展有一些了解，不少文章都做了介绍。我对其的理解简而言之是：
我们在浏览器端需要模块化方案，后端已经有
node.js的CommonJS模块化方案；但是这套方案是同步的，
require进一个模块后再使用，服务器端的文件读写速度允许这样做，但是浏览器端的网速是有限制的，我们不能直接把符合CommonJS的包拿来用，于是从CommonJS规范中分离出了AMD异步规范，require.js是这个规范的实现，异步加载模块；但是不能把大量的
NPM里的CommonJS的包拿来用实在很不爽，而且NPM是个很棒的包管理器，如果能把那些包拿来用在浏览器端（很多包都有NPM版本），很大程度上可以实现前后端包的复用，于是有了browserify这个神器，帮助我们在浏览器端使用CommonJS的包。
于是我就有一个问题了，很多文章都提到不能直接使用 CommonJS 规范的包的原因是浏览器端加载速度和服务器端不可比，所以不能采用同步模式，那么是不是意味着 browserify 处理依赖关系后产生的那个文件本质上是一种异步方式加载呢? 不是的话它本质上解决同步问题的原理是什么呢?
我看到现在讲解 browserify 原理最详细的是腾讯 Alloyteam 的这篇，里面提到生成什么 AST 树，然后实现一遍 export 和 require 方法，然后根据依赖字典加载模块。坦白讲虽然文章写得很详尽但是本菜还是不能透彻理解，但是似乎可以肯定的是这种方案不是一种异步方案。
于是结论就是，browserify 采用了一种非异步也非同步的方案使用了 CommonJS 形式的 NPM 包并处理了它们的依赖? 那么也就是说原来：
不能采用
CommonJS同步方案的原因是因为浏览器端和服务器端加载速度不可比
这是一个扯淡的说法么?
鄙人前端刚入门，望知情的大大可以用稍微通俗一点的说法解释一下，谢谢。 0 0
2015.08.21 19:46更新
呃....我感觉自己犯了一个低级错误，好吧，可能这对我来说也不算低级错误，之前没写过 Node.js。 = =
大概明白自己理解偏差在什么地方了。就像 @leftstick 说的
browserify和CommonJS一样是同步的。
但是它们两者还是有区别，这也是我理解偏差的地方。Node.js 是属于代码运行时实时加载模块的，也就是它不需要像 browserify 一样去提前打包依赖，因为服务器端文件读写速度够快，而浏览器端就不行了，所以需要 browserify 提前打包依赖，搞成1个文件(或多个，其实本质一样)。而 require.js 因为是异步的，所以它可以提供一个实时加载器，每次加载代码的时候都要带上 require.js 一起。
感觉是一个理解上很囧的问题。 = =
我说的土坯一点，browserify做的事情是允许你的前端代码里使用CommonJS规范，譬如：可以允许require关键字加载模块。
要注意的是，require关键字在浏览器里其实是不存在的，这点同意吧？那代码是如何在浏览器里运行的？
其实就是你提到大牛讲的那些天书。我们暂且不管，那通俗讲browserify做了什么？
他遍历你的代码，寻找里面的require关键字，把require的模块，合并到当前代码的前面，保证里依赖顺序。
也就是说，通过browserify之后的代码，其实就一个文件(当然高阶使用也可以打包多个文件)，里面的代码都是同步的，没异步什么事了。