好文啊，绝大多数观点非常赞同。的确，企业内部人员流动使得内部开源工具很难长久健康发展。

不过文中提出的“Browserify 的不足”中的第一点：

工程项目里的前端页面必须对 Seed（KISSY Seed 或者 jQuery） 有依赖，这种依赖不能在构建的时候复制多份（特别是在 H5 离线包 中，为了控制离线包体积，必须要去重），npm 中的模块物理上都是复制存储的。

应该可以通过 webpack multiple-bundles 和 browserify multiple-bundles 来解决吧（我也只是初步了解 😄）。

说到底还是历史包袱啊……
新东西总有新东西的玩法，迁移才是最麻烦的

其实除了构建工具之外，厂内 UI 层的库同样也有这个问题：
大量新框架层出不穷，MV*/Vue/React，但是厂内还是 Zepto+YUI 风格的 KISSY 系，吸收不了开源世界的新东西。更惨的是大量基础 UI 建立在 KISSY 生态上，根本没法迁移。之前去啊也实践过一段时间的Angular，后来听说又 drop 掉了。

现在@玉伯 团队全面拥抱 React， @勾股 开始尝试 Vue，不知道航旅这边有什么想法

其实KISSY EDGE的时候，KMD就已经是CommonJS书写方式了，还是省了不少事情的，如果不是人员变动，Browserify和KISSY最后谁更容易被接受未可知。

经历过三家公司的变动，对5的两点深有同感，@勾股 。

关于6的种种问题，虽然看起来是通用场景下的需求，但是实际上都和业务相关了，使用者会是自己团队的小伙伴，那么软性约束是可以愉快解决的，尤其是1、2；3，4使用类似@不四 他们做的事情，做个cBrowserify（私有Browserify），同样还能解决5，另外，既然使用了npm的方式来进行管理，不管是符合dry的理念抽象一个团队使用的team-config.json来统一保存内容，还是直接就在package里开辟一个字段储存内容都是可行的，不需要纠结配置需要保存多份的问题。

还有一点，原po没有提到，内部百花齐放的原因和类库/工具/组件没有强制的数据交互约束也有关系。而做了这一点的，我记得只有 @鬼道 的RAP，如果能早点达成共识就好了。

ps:chap. 4似乎无视掉了小马团队的事情。

一大早起来通过拔赤周报辗转来到这里，看到文里提到的各种现状，最有感触的关于 npmmodule和browserify/webpack的一段。手淘前端从什么队都不站，纯依赖ml.x.taobao.net的简单的基础库cdncombo的工具把库引用，依赖管理这件事情走到现在。回头看看，感觉是略有心酸，五味杂陈。但是即使到今天经过讨论觉得是时候探探路站站队了，也对这件事情并不那么着急。原因是从现状看，大家对于“组件入库”，“引库使用”这件事有痛点，但单纯这个点上痛点没那么大，更多的痛点是混杂在其他地方，开发流，图片处理，预编译，构建，调试，发布等等一系列。

回到刚才说的module的引用方式，加上browserify或者webpack。开始讨论这件事情在团队内部也就上个月的事情。最开始的初衷是为了解决业务代码和基础代码中缺少模块依赖关系处理这个问题。过程中依然百花齐放，有同学业务模块自己browserify处理，基础库因为历史原因用bower管理，也有人在尝试ES6+webpack的module处理方式，还有人自己做过一个套件，包装了一个类CommonJS的依赖引用方式，可以在不改变现有基础库代码（没有模块范式）的前提下也能正常使用。

当时有个简单的讨论，大家想在上面提到的方式中选一个或者组合一个然后去挖。首先完全自造轮子的方式没必要，也有风险，放掉。ES6+webpack的方式大家相信应该会是面向未来的最好的选择，但是面临两个问题，一个是polyfill对业务来说可能太重，另一个是担心步子一下迈太大团队成员跟不上。所以当时的讨论回归到npmmodule和browserify。

说到正题，拔赤说道的前端组件npmmodule化和browserify/webpack 难担大任的问题。我们当时也心有戚戚。

1. npmmodule化之后，组件引用从云共享变成代码实体引用。这并不是一个好的方式，至少在当前大环境下是。
   所以我们的考虑肯定是不能直接使用现有的browserify，而是是否能基于它包一层，比如my_browserify，以此来做到开发时本地依赖，但是基础库的部份在构建阶段解成线上依赖（动作有点大，感觉为了解决一个问题引入另一个更大的问题）
2. css在browserify中没有直接的解法，在webpack中也只能换成js动态注入，显然也不是当前环境想要的结果。还好当时我们的基础库和功能控件涉及css的不多。当时就直接放掉了这块的讨论，css暂时还是老老实实刀耕火种吧，除非也是像1一样在自己包的my_browserify中解决。

3和4. 多源和多组织的问题，如果真打算淌这淌水，那么npm和bower理应只选择一个。而两个的各自优点让人放不下，比如bower灵活的依赖源支持，扁平的文件结构可能更适合前端的文件组织方式，但npm天生有更强的依赖引用和处理能力。
这种情况下选择就意味着放弃，关键就是权衡轻重的问题。要么就大家都不选，维持现状
npm源和gitlab源两处发布的问题，一样，如果真想淌这水，通过搭中间服务，接hook，或许也能解决一部分。也是性价比和轻重的问题

回过头来看关于前端组件依赖处理的问题。如果想在这个点上站队，随便做一点说我用了browserify或者webpack，没问题。但是想做通，把拔赤说的几个点都打通。要挖的坑或者说性价比可能并没有那么高。尤其是针对团队通用，而不是项目通用。

所以我们虽然在尝试这件事情，但我依旧持保守态度，同时也在兼容并包看待百花齐放，兼容并包。包括最近勾股一直在实践的vuejs+vueloader+webpack的方式，或者是ES6+webpack的方式。

到现在为止，现状都在，问题都在，大浪淘沙，谁剩下了，谁就是金子。在手淘前端团队里也是这样。

@hongru ES6 其他特性的 polyfill 可能的确是太重了，但是仅从模块化方案上来看，webpack 的 overhead 其实够轻了 -> http://webpack.github.io/docs/comparison.html 所以模块化规范尽早迁移到 ES6 Module 其实没太大问题的。
另外，关于 npm/bower 二选一的方案，不知道你们是否考虑过 jspm？国内很少看到这方面的对比，个人不是很明白 jspm 有什么很不好的地方么……？

@soulteary NPM 包规范在通常情况下是ok 的，但在夹杂了demo演示、本地运行环境、css 引用等情况是，复杂度会陡增，还是很纠结 npm 包规范太“服务端”而不够“前端”

@hongru webpack 的不足很少，但对css的处理是一个短板，我们也没想好太好的办法来hack

@jayli 个人认为，该走规范的走规范，该走约定的走约定，demo/runtime本身和代码关联相比较代码实现部分就不是特别强，应该遵守团队约定。

运行环境对于每个项目可能都有特殊性，厂内不是有daily环境可以玩么，或者结合在线mock服务，也能整一套『通用的运行环境』，个人比较倾向自己搞开发机或者本地虚拟机来实现这些Pantimos。

demo演示，前端demo除了UI展示的需求外，还有交互类型的，后者一般和接口相关，如果约定使用固定的mock库把在线接口转离线，或者根据参数、配置把代码里的接口转mock服务的接口，也是没啥问题的。

资源引用，应该是代码管理的事情。如果不存在依赖，那么应该用工具约束成方案吧。

周末参加深JS一直没时间回，有几个地方想再补充一下我的看法：

1. 对 npm 本身已注册的包来说，修改/维护/发布的成本高这个确实如此，不过所幸 npm 还可以通过 npm install githubname/reponame 的方式直接安装任意 github 的包的任意版本，所以，在 npm 的方案里，原文中提到的“线上组件出了问题，bugfix 升级成本很高（因为你要 at 组件作者去修复）”的问题其实并没有那么麻烦，每个人可以自行 fork 或创建自己业务的 branch、tag 或 repo 解决现实问题，并在合适的时机争取 merge 回主仓库的主分支。所以现实问题 npm 是有解的，而后续问题不是工具可以单方面解决的，是需要人解决的。
2. “物理代码分散”这在我看来并没有任何问题，前端的代码本来就是应该通过相互依赖的关系解耦的，如何在业务中把握好“物理代码分散”的问题恰恰就是如何上面修改/维护/发布 npm 的问题，而不能把它转换成“物理代码应该聚合”的问题
3. 如果底层组件或库需要频繁维护和改动，我觉得首要问题是提升代码质量、版本控制和抽象设计，不然什么辅助工具也无法高效支撑在这样的基础上高效完成上层开发。
4. Browserify 和 webpack 对 CSS 的记载时机确实也是我自己很介意的地方，是我希望大家可以一起借助 browserify/webpack 和社区的力量推动解决的，正如原文第 5 点的我的观点 (文中的 @勾股 就是我 😄 )。另外 CSS 加载实际上早已经变成了个综合问题，实际上你会发现，如果我只先加载了 CSS 而 template 还没有被 JavaScript 初始化，那这些样式并没有更早于 JS bundle 发挥价值。我更觉得，如果我们需要从用户感知上给加载提速，做好拆分包并按需加载是很重要的——而不是把 CSS 拆出来。
5. npm 去重的问题前面有评论提到了，表示支持，我自己也是这么实践的，不多做赘述
6. npm 的依赖关系同时写在了 package.json 和代码中的 require()，这个问题已经有工具在解决，那就是 duo 也许是我们更喜欢的，duo 主要的问题是现成配套的周边东西还是偏少，目前我对此持观望态度，也许近期就会试试看
7. 关于 seed 依赖信息，如果我没理解错的话，这里面有两层面“去重”的需求，第一个是在完整的 bundle 里，在多处通过 package.json 依赖的包会被打入多次，这个问题前面已经有解法了；第二层含义是我们可能需要在特定的情况下动态决定要补充请求哪些组件，比如我现在随着用户的操作进入一个新的界面场景，还缺组件 A，但是组件 A 又依赖组件 B 和 C，可这时候需要知道页面是否已经加载过 B 或 C，然后才能去重，再请求回正确且最小集合的代码。手机淘宝的业务中有些场景是这样的，套路无非是 3 种
   1. 第一种显然是丧心病狂的不管重复的引入完整的 A B C
   2. 第二种是中心化管理 seed 依赖信息，每次类似的请求之前先在浏览器做好去重再向服务器请求结果
   3. 第三种是把已加载的所有模块借请求的机会传给服务器，由服务器去重再返回结果

似乎各有各的好处，但也都不完美，算是再抛出一个我自己的问题吧 (这个问题我周末还跟 不四 @dead-horse 聊到，但暂没有结论)，希望楼下可以继续

另外其实我挺喜欢 bower 的，bower 有很多优点，只是 npm 的社区更好同时有 browserify 和 webpack 令其如虎添翼，并且 npm 不是没有前端资源库的最佳实践。综合考虑我今天可能还是会选 npm 吧…… (我也不想把 bower “黑”成什么样)

问题2：
在bower和npm都开源了几个项目，总体感觉开发者这边其实还是挺方便的，痛点主要在没有足够的精力去后续维护，而且前期使用场景有限，开发维度上比较欠缺。
作为插件使用者使用bower和npm上，感觉npm还是比较受欢迎，nodejs直接支持，而且bower的依赖是走平行依赖，npm是项目内深度依赖，虽然npm包大了，但是很多二次开发上不会太担心其它的依赖问题。
目前的项目是2者都用，没啥不好的
问题3：
项目立项初比较轻，后期逐渐变重，这个几乎是没办法去避免的。只能通过模块化的方式，让部分相对比较固化的地方尽可能的固化，只允许核心的人员允许编辑，并且一定保持向后兼容。与业务强偶尔的代码可以通过相关的开发工具（grunt、gulp等）去整合开发。总的来说问题3，感觉是一个通病，目前没有找到什么好的方式去解决，只能尽可能的去缓解吧。
问题7：
前端未来一定是会走大前端的路线，目前很多朋友（包括自己）开发的项目，都已经走向服务器端了。关联的问题也越来越多，es6后面感觉肯定火，这个只能大家共勉了。

前端这是要逆天了哈，非常感谢分享

说说关于 npm / webpack 的一些问题：

1. 模块重复：npm3 自带模块去重。只要依赖的 semver 版本不冲突就只会安装一份。
2. CSS 样式处理：webpack 的 ExtractTextPlugin 可以将整个包里依赖的 CSS 模块抽取成一个文件用于单独加载，并不是无解。Browserify 整体上对于很多工程化问题都欠考虑，依赖社区，但是社区工具 hack 很多，质量参差不齐。
3. 代码分散。既然用了 webpack，最理想的就是全面拥抱 CommonJS （或者直接上 babel-loader，全面 ES6 模块化）。bower 是个历史包袱，能去掉最好。
4. npm 包大多自带 devDependency 和构建脚本，这其实是好事，每个包都应该能够单独调试、测试、看 demo。大部分小组件根本不需要 grunt/gulp，直接 webpack + webpack-dev-server + npm script 就足够。纠结一个包 “看上去不前端” 是毫无意义的。
5. package.json 声明的是包和包之间的联系，不是文件模块之间的依赖。文件模块的依赖关系就应该在文件内通过 require/import 自然形成，需要手动指定是画蛇添足。

以上，我的看法就是 npm 很好。

另外，Duo 已经是个 dead project 了。如果想要类似的方案不如看看 System.js，但我的看法是现阶段（在全面 HTTP/2 化之前）不如 Webpack.

同 @yyx990803 的看法，npm 很好。

@yyx990803 文中提到的几个问题其实已经困扰了我们很久，最大的问题就是设计规则，用最小的成本换来团队内优秀代码的流通，所以有时候不得不取舍。webpack 的确和 CommonJS 是强关联的，全新的 PC 项目用起来会很合适，前提是所有的东东都必须很规范才行。像我们这种整天脏手摆弄代码的，整天为了赶工期净搞一些quick & dirity 勾当的厂内码农，webpack的消费成本略高，为了保持一切都很“整洁规范”，所消耗的不仅仅是工程的工期，可能还有很多过渡设计的成本。

@jayli 嗯... 有历史包袱的过渡总是会复杂许多，这个我也深有体会。不知道你们厂内具体情况是怎样的，不过制定清晰的规范后在新项目里面小范围试点，如果好用再慢慢推广呢？

@yyx990803 会小范围试一下，新东西和旧业务之间总是需要一个磨合，呵呵

稍微有点历史的厂，债务就已经不可估算了。。。与开发人员数量成正比。。。
基本还不清啊，还不清

http://webpack.github.io/docs/ 官方的拼写是 webpack, 总之 P 不大写~

“为了便于 widget 代码携带 Demo，需要一个本地环境，将源码（src）构建出目标代码（dist）以便运行起来，所以包内必须携带 grunt 或者 gulp 之类的构建脚本”

what？真的要带在同一个npm package里面吗？这不是给自己找茬么，分开不就好了？slider，slider-minmax-demo，这样。

@iuyanghejerry 包代码的构建问题说来话长，你可以看下 kissy 提供的模块，为了方便直接在代码里载入这些包（无需其他配置），所以包里都携带了构建好的 dist 代码，用起来极其方便（直接代码里 use 模块名字即可）。在 PC 项目中这种模式在阿里基本上甩不掉了。这样搞的缺陷是修改起来很麻烦。

赞同 @yyx990803 对于npm/webpack的看法。

统一使用npm托管公共模块，它意味着前后端采用同一种模块化标准开发，不用去理解现存的各种标准（CMD、AMD、CommonJS等），其开发和维护成本何止是加倍这么简单。

但是因为前端和Node.js的运行环境实在是有差异，npm如果能够在package.json有意识地对前端和后端做区分就更好了，比如增加target字段，其中前端模块的依赖可以借鉴bower扁平化的约定。退一步讲，即使npm不这样规定，模块开发者也可以有意识地人为地进行约定。

至于构建工具，目前相对理想的应该就是webpack了。

进一步讲，阿里业务的发展实在太快，无线化对研发模式带来极大的冲击，从天猫、支付宝、淘宝等前端团队变化来看，从作为支撑角色的前端，会逐渐强耦合业务，就又加剧了前端技术的多元化和去中心化的大趋势。所以我们经常开玩笑，百度的前端业务得多简单，一个 FIS 就可以支撑百度绝大多数前端业务了。

并不是百度业务简单，而是FIS找到了支撑不同业务类型（从PC到移动，从web到native）之间共性的解决方案，没有凭借其他行政力量而支撑百度大部分前端业务，我想其原因应该是FIS定制的极简规则真正打动了百度前端工程师，否则早就会被挑剔的工程师所抛弃了。

关于组件生态和组件复用，我觉得是不是对（某些）前端场景来说是一个伪命题？虽然看似能提高生产力，但仔细想想其实有不少问题。

前端有两类产品，一种是CRUD类的产品（XX管理系统，XX后台），这类产品交互行为高度一致，具有“可成套复用组件库”的基础；而形如淘宝、天猫、阿里航旅等对外的服务型产品，业务与也业务之间的组件可复用度就应该大打折扣了吧。

借助制造业的概念来类比这两类产品，前者可以实现“减材制造”，就是给你一套功能齐全的组件库，通过删减其中的功能实现业务；而第二类产品，通常都是“增材制造”的过程，这些产品有各自的定制需求，彼此之间可复用的可能性并不高，为了长期维护考虑，一般都选择从0开始建设。

扩大一点，对于GUI软件来说，古往今来，组件生态的概念有真正广泛的成功过么？

有现成的 util.inherits不用,做个 Function.prototype.derive 做甚~第一眼看不下去

@magicdawn 在js中，用派生的语义来构造一个类是没有问题的，甚至由于js语言的特殊性，派生会比继承更直观好用一些，也有项目采用了派生的语义来做OO，比如 WinJS。

derive和inherits的用法比较就不贴了，离本主题太远，况且纯属个人喜好。

看不下去什么的多少还是偏见在作祟吧，无解。

browserify 大法好~
https://github.com/magicdawn/predator-demo

npm完全胜任管理前后端依赖，项目中运用nodejs+react+redux搭建了整个应用，通过webpack+ babel 的组合方式编写es6代码，不需要关心模块化问题，gulp管理整个预处理任务， 至于文中提到的css问题，webpack是可以编译成单独的文件，所以实际使用的时候并没有觉得纠结，反而会暗爽~~

@xuheng

是外部服务还是内部系统，有没有可访问地址看一下？

@xuheng
npm 是如何安装多版本 jquery 的，比如项目同时使用 jquery@1.11.2 和 jquery@2.0.0

@nimojs 我比較好奇的是，什麼狀況會使用到兩個 jQuery 版本？

一个系统直接依赖 jQuery 两个版本是想干啥

@appleboy @magicdawn 可能选用了两个生态中的组件，而这两个组件依赖了不同的jquery版本吧，并不一定是开发者自己想找别扭。。。

@fouber 外部系统，已经提测了，开发整体来说比较顺利，有一些小坑不过都能解决，这里有个简单的介绍http://cnedwan.com/2015/08/22/%E5%9F%BA%E4%BA%8EReact%E6%9E%84%E5%BB%BAspa%E5%BA%94%E7%94%A8.html

@nimojs 用npm管理前端代码，还是看项目有没有需要，不一定非要使用，比如我们用npm管理前后端代码，是因为用了react、redux等一些现代框架，顺理成章我们就用了es6编写前端业务，接着用了es6的模块化， 因为es6的模块化兼容node_module这种方式，所以我们就采用了npm管理前后端代码

@xuheng 等上线了再看看吧

所以那就不是直接了, 间接引用两个版本, 这不就是每个module都有自己的node_modules初衷么

@magicdawn

@jayli(作者)：npm不爽，每个module都有自己的node_modules，物理上都是复制存储的
@yyx990803：npm3 自带模块去重
@nimojs：去重前提下，如果选了两个依赖不同semver版本jquery的生态组件怎么搞？
@magicdawn： 这不就是每个module都有自己的node_modules初衷么？
...
@jayli(作者)：npm不爽，每个module都有自己的node_modules，物理上都是复制存储的

是要这么循环讨论下去么。。。

@appleboy
@magicdawn
这里的 jquery是举得一个例子，比如某个业务模块在产品中应用了 dialog@1.0.0 版本，因为新增了需求这个业务模块更新到了 dialog@1.0.1 ，我希望以后新的页面都用dialog@1.0.1。但是我希望老页面还是用 dialog@1.0.0 ，因为更新组件是有出错的风险的（或者将老页所有相关页面都测试一遍）。

所以会存在一个组件存在多个版本。

@nimojs

如果是我的話，把舊的頁面升級，或許會是比較快的方式。對我而言，如果拆成兩套，一來不好維護，二來在上線時，要跑的 job 或多出許多。通常而言，把 jQuery 的 Chnage log 看完，理論上就可以直接升級，除非寫法差異很大。

拥抱变化，持续发展。前端正在慢慢撑起半边天。

通篇看下来，里面提到了

生产环境只支持静态 HTML

在我看来，这样能最大层面上保证页面 “秒开” 。

同时，也多次提到 css 的优先加载。但目前来看，基于 React 的 SPA 大行其道。

只先加载了 CSS 而 template 还没有被 JavaScript 初始化，那这些样式并没有更早于 JS bundle 发挥价值

这完全适应于 React 的场景。那此种情况下，如何才能保证其渲染或者加载速度，达到 “秒开” 呢？

全明星团队打造的 ant.design ，其官网的打开速度在我看来也不是非常的理想。

@alcat2008 网站部署在美帝，国内肯定慢。

@afc163 是的，仔细看过整个项目，知道它是 gitpage。

ant.design 打开就是一个很炫的 loading 动画，之后要等待一个 1.6M (gzip 515k) 的 index.js 加载完成页面才会真正开始渲染，可以脑补下网速稍差时的等待情形。

基于 React 的 SPA 应用，都会有一个大 jsbundle。即使通过 require.ensure 之类的方案进行 trunk，依然会有较为长时间的加载等待时间。相比静态 HTML 页面还是有劣势。

主要是想了解： 如何才能保证其渲染或者加载速度，达到 “秒开” 呢？

目前能解决首屏速度问题的只有服务端渲染了，后续 https://github.com/benjycui/bisheng 会探索在静态站点进行服务端渲染的方案。

@afc163 服务端渲染还需要对现有项目进行调整，不是理想的 “前端” 方案。

之前看 bisheng，只看到其构建能力。持续关注，希望能爆出惊喜。