Web前端开发相关工具整理

[hax]

https://github.com/codylindley/frontend-tools

目前所选择的工具：

Workflow/Builds/Assemblers/Task-runners/Dev Opts

gulpjs 在用 grunt 基本否定 broccoli 感觉不成熟

yeoman 熟悉中

Browser Package Managers

npm bower 有一些问题，不建议，但因为流行，库要发布到bower component 否定（转向其他） jspm.io 待研究

normalize 观察中

总体 package management 的最佳实践可能会受到 loader 影响

Testing Frameworks

intern 有待尝试

Code Complexity & Reports

escomplex 注：parser要用eslint/espree或acorn，原本的esprima太严格

[yujiangshui]

可否咨询一下前辈为什么基本否定 grunt ？

在最初学习 gulp 和 grunt 的时候，我也是偏向 gulp 的，感觉它的语法更符合 JS 开发的习惯，但使用起来感觉还是 grunt 好，我的当时体验是这样的（比较早版本的 gulp，不知道现在新版会不会已经改良了）：

gulp 插件杂乱无章，因为大都是个人开发，用法灵活但使用不当会出现很多错误，为了一个功能往往发现两三个实现同样功能的插件，不知道选择哪个，有的使用起来还出错。而 grunt 的插件，有一部分最常用的插件是官方开发的，测试可靠、文档标准规范，用起来就觉得放心。而这类工具最重要的就是扩展插件吧。所以虽然 gulp 速度比 grunt 快的多、语法简洁易懂，但是我还是愿意使用 grunt。

虽然说这类东西，按个人意愿使用即可，不过前辈用了基本否定这种词，所以我想请教一下前辈的看法，看看自己是否有必要更新一下。

[SiZapPaaiGwat]

@hax @yujiangshui 插件乱确实。我现在更倾向于自己直接使用gulp插件依赖的底层库，然后自己写。

[hax]

@yujiangshui

最初不喜欢grunt最主要原因是写出来的配置代码又臭又长，还不如直接写命令行脚本或者Makefile。深层问题则是它仅仅是一个task runner，对build应该怎么做本身没有约束。

gulpjs有几个很好的地方。 第一是有一个基于流和管道的模型，符合unix工具组合的传统。基于这样的模型，使其能形成互相协作和有序竞争的插件生态。 第二是代码的写法比基于配置的grunt要简洁和一致。 第三有性能优势。当然这一点broccoli有不同意见。

这些优势非常明显，以至于在grunt已经那么火的情况下，gulp出来没多少时候就可以跟grunt分庭抗礼，并且绝大部分功能都有对应插件——这一点broccoli就比不上（刚出来时蛮火的，但发展势头似乎现在有些停滞）。

@simongfxu 插件杂乱无章这个事情我不是特别同意，整个nodejs的生态就是这样的，同样的事情可能会有很多modules。 第一，有竞争是好事。 第二，相对来说gulp由于模型的限制和其社区的严苛到变态的要求（看看有多少插件被以不符合gulp的理念而被干掉），所以每个插件的功能都相对单一，其竞争是相对有序的（只拼单一功能），所以会很快收敛到一个最多几个共存。有几个共存的原因往往是因为其底层实现确实不同，这是很正常的。 第三，gulp确实存在一些问题（比如错误处理），我们使用中也遇到，不过这些问题应该在下一个大版本4.0会解决，尽管4.0迟迟不出来也是个问题，但是就目前而言我还是愿意再耐心等待下。

如果需要的是开箱即用，那么grunt也许还是一个ok的选择，但是对于我来说，开箱即用不是我的主要目标，所以会选择架构上看更好的gulp。

[yujiangshui]

@hax tks