很多人第一次给 Grunt 配任务，会优先想到压缩和拼接，因为这些动作看起来最像“构建”。但如果从每天写代码的体验来看，更能拉开效率差距的其实是另一组能力：保存文件后自动检查、自动重跑任务、自动刷新页面。

2013 年前端工程化还远没有今天这么成熟，但团队已经开始意识到：文件压缩、拼接、编译、监听这些工作，不能一直靠手工做。

Bower 刚流行起来时，很多人最兴奋的是“前端终于也能装依赖了”。但真把它放进项目以后，很快就会碰到另一个更实际的问题：第三方库装到哪里，业务代码放到哪里，Grunt 打包时又该从哪些目录取文件。

刚接触 Grunt 时，很容易因为插件多、示例多，直接把 concat、uglify、watch、cssmin 全塞进一个 default 任务里。命令虽然能跑，但过不了几天就会发现：自己已经分不清到底哪个任务给开发环境用，哪个任务给上线打包用。

Node.js 在 2013 年开始变得越来越热，而 npm 也逐渐从一个附属工具，变成了 JavaScript 开发者必须熟悉的生态入口。

npm 真正开始好用之后，开发者很快就会遇到两个新问题：依赖到底应该装哪个版本，项目命令又该怎么统一。它们看起来像细节，但在 2013 年已经足够决定一个项目是“能复现”还是“只能在作者电脑上运行”。

工具链越丰富，越容易让人产生一种冲动：项目只要稍微多一点脚本和命令，就赶紧引入一层更复杂的构建工具。2013 年我在接触 npm scripts 这套能力时，也有过这种心态，总觉得直接用 scripts 显得有点朴素，好像不上点额外工具就不够“工程化”。

很多人第一次运行 npm init 之后，会把 package.json 看成一个顺手生成出来的文件。可到 2013 年，随着 Node.js 项目越来越多，大家已经慢慢发现：这个文件其实正在变成项目配置和协作信息的中心。

前端开发者刚转到 Node.js 时，经常会在异步这里卡住。页面脚本里也有事件和回调，但放进服务端请求处理后，感受会更强，因为浏览器正在等你返回结果，流程一下就变得更有压力。

2013 年很多前端开发者第一次认真看 Node.js 时，最兴奋的地方往往是“终于可以用 JavaScript 写后端了”。但真正想把它学好，第一步不是写接口，而是先把服务端思维建立起来。