webpack到底好在哪里

#1

###看社区朋友都在用webpack实在不知道webpack好在哪里…

亲手实验了一下，方法弄ok了，不过还是不大习惯。

###1.首先按照官方解释，其好处有
a.支持commejs规范和amd规范等
b.有很多插件和loader
c.可以将codebase变为chunk首屏优化（不大理解）
d.可以和webwork和nodejs混用
e.可以缓存一大堆优化bla bla bla

###2.本人不才只试用了一下webapp的方式…有几点不适应
a.看的出来webpack是以对js进行编译的方式将文件的依赖形成一个加了N多内容的文件，以首文件加入页面中
b.这种方式可以保证js像是一个很大的模块基本上和页面完全解耦，但是入口也得多加一个文件不是写在js中。
c.每次想看效果，得用gulp的watch和其他，中文文档也不全，配置比较多…学习成本高。

###3.由于webpack不是很方便（最好有大大能指点迷津告知项目中好在哪里）
所以经过一系列尝试还是决定用fis，这个工具集成了gulp和webpack功能强大。
a.webpack的commonjs方式完全可以用fis的jswrapper插件来完成
b.首屏渲染cache这种东西对于fis来说太小儿科，我想优化csssprite和image-set目前我仅仅发现只有fis有。
c.fis可以不断修改改成更符合项目结构的方式。

所以最后我还是选型用fis来处理打包，不知道好不好。

还有flux，有说reflux好，flux好还有其他方式吗？个人感觉差不多…用法不一样而已

我最近准备弄一个开源项目，最终的选型是
fis->aviator->requirejs->flux->react
还请大家提点建议或者说说自己项目的选型，为什么这样选?

#2

个人要求至少要能加载yaml之类的吧
主要看重它自定义能力比较强
不过必须要看英语文档就是了

#3

fis里面也有关于fis react的插件的可以加载妥妥的

#4

Webpack可以在编译时自动生成require信息，然后就可以写这种代码：

{div, p, Button, App} = require 'elements'
{UserStore, CommentsStore} = require 'stores'

没用过FIS倒是

#5

哦，多谢了，感觉不同的社区确实是接触的技术有差异，fis可以自动生成map.json的依赖图也很方便~

#6

Webpack 也能生成 assets.json 的配置的, 只不过要用插件的写法.

FIS 我试了一下没用过, 感觉不像是 Node 社区的产品, 跟社区的配合也不够好.

Webpack 搭配 React 的代码热替换, 不知道 FIS 有没有做.
我当时从 Gulp 切换到 Webpack 主要的原因之一就是 HMR 这项技术.

Webpack 的模块化设计得很棒. 之前用 Gulp 什么都要自己写, 很容易弄出问题.
如果说开发, 上线, 多个环境的配置都没什么问题, 是好是坏大概就不重要了, 毕竟场景都回不一样.

#7

感谢指点，fis有https://github.com/fouber/fis-parser-react 这个插件可以进行热替换所以才考虑用这个…也许webpack我还用的不深入，webpack还得继续学习下。主要fis的css sprite和imageset的方式是其他打包工具我现在还没看到过的独特功能

1 Like
#8

能介绍一下那两个功能吗？说不定在用webpack的同学也有同样的需求

#9

很简单，就是分散的图片，打包的时候会集成到一个图片上，用css sprite的方式载入，减少请求。甚至必要的情况下可以以base64方式插入，而无需修改任何代码，图片的位置定位都完全由打包生成。第二个是由于现在很多手机需要配多个图片来适应不同window.devicePixelRatio，而代码里写一遍，打包会帮我们自动修改属性来自适配。我暂时用到的是这两个比较牛逼的方式，其他什么的coffee，less等的编译和其他打包都大同小异。还有其他的组件我也没研究的太深入

#10

打包工具太多了,没一个实用的,经常是解决一个旧的问题,引出五个新的问题

#11

目前了解到的 Webpack 的 url-loader 对应图片, 采取的是保持文件和读取为 Base64 DataUrl 两种策略.
大致是小图用 Base64 插入, 大图独立文件这样的.
至于合并图片的功能, 目前没遇到过… 估计插件没人做.

#12

简单，易用，模块化。

#13

对我来说，webpack 和 browserify 都能解决问题，我对 amd，cmd 的具体实现不了解，等到需要研究这块的原理时，可能就有区别了。之前我使用的是 browserify。

webpack 我认为配置相当复杂，相当 low level 的 API。我选择使用 webpack 和 使用 gulp，和使用 browserify 一样，就是因为社区里已经有人整理出常用的模板出来。而且代码量相对不多，可以维护。

webpack 主要还是因为所谓的性能问题被大家热捧，其他一些优势具体可以看 Pete Hunt 的视频 OSCON 2014_ How Instagram.com Works; Pete Hunt 里面主要提到了一句话：
把所有 javascript 都打包成一个大的 js，减少 http 请求数是最佳实践吗？ 不是，所以，browserify 不适合，但是 webpack 可以拆分 js。

我现在是参考 este 的 webpack 的配置，但是例如 production 使用的几个插件，必须要看 webpack 的文档才能熟悉作用，并且实在已经熟知各个配置项的含义的前提下。比如 eval eval-source-map，cheap-source-map 这些很少会接触到的概念。

附上我整理的webpack。HMR挺好用的，同时配置了 browser-sync，方便兼容性测试。当然，现在是和 webpack-dev-server 分开的。猜测可以将 browser-sync 的 proxy 配置成 webpack-dev-server 就可以合并了。之后尝试下。

而且现在使用了 webpack 后，很多人就放弃了 gulp 之类的 task runner，使用 npm scripts。我依旧使用了 gulp，毕竟 gulp task 不是我写的，常用的都已经有了 example。我不认为 gulp 社区已经完全放弃，但是github上的新项目，的确 browserify 使用的人相对较少了。

1 Like
#14

感谢说的这么详细，案例不错。值得学习，还有好的些案例吗？

#15

CSS Sprites 可以使用 compass，这是我一直推崇的一个预编译库

#16

@tablecell

打包工具确实比较多，有些是为了磨平前端模块化组件之间的差异的，有些是专门由模块化框架提供出来方便做合并的，比如 require.js 的 r.js 或者国内 seajs 的 spm。

那么这些打包工具的出现，是因为满足模块化开发的需求；拆分模块是为了更好的维护和复用，模块化框架是为了搞定拆分后的组件的加载以及组件之间的依赖管理。（通俗点说）

那么一个适用的打包工具必然是需要一个固定的模块化方案。理论上来说一个项目或者团队应该只用同一种模块化开发方案，只有这样这个打包工具才会体现无可衡量的价值。

那么我们进一步的说，接受一种模块化方案就是接受了一种开发模式，同一个团队应该只有一种开发模式下开发。

所以，特定的打包工具是为了处理特定的模块化开发的需求，并无法做到通吃，通吃往往带来的就是维护上的困难和优化上的不便利。按照自己的需求去选择一个打包工具才是正确的选择。

#17

@楼主 及其 各位

选择 FIS ，定能让整个事情简单起来。

#18

哈哈，你也看好fis，不过fis是属于通吃型的喔,fis支持require和seajs的效果并不是 特别理想，不过写插件很容易，还比较方便，架构和扩展性不错，比较喜欢

#19

@guowei

当然了，FIS 现在是我在负责维护，我应该标明利害关系的。

其实 FIS 不是通吃的，FIS 本身定位是面向前端的工程构建系统，它并不强制依赖某个模块化方案。只是当用户用 FIS 打造某种特定解决方案的时候才会去依赖某种模块化方案。

另外，之所以对 AMD、seajs 等做支持为了表明在某一种特定模块化开发需求下，通过组装和扩展 FIS 是可以搞定这类需求，而不是通吃~

2 Likes
#20

webpack 能为静态资源添加版本号吗？