2013 年前端开发已经越来越离不开浏览器开发者工具了。页面一出问题，如果不会用 DevTools，很多排查只能靠猜。

样式问题最容易让人陷入一种低效循环：改一处 CSS，刷新页面，看不对，再回去改下一处。尤其是接手别人留下来的页面时，选择器层级多、覆盖关系杂，如果只在源码里猜，很快就会迷路。

浏览器里出现白屏、按钮没反应、数据不显示时，很多人的第一反应还是回编辑器里盯代码。但真到项目节奏快的时候，这种做法经常会让人越看越散。Chrome DevTools 真正有用的地方，是它能先帮你把问题范围收住。

刚开始做响应式时，很多人会先去搜“iPhone 多宽、iPad 多宽、常见安卓机多宽”，然后把这些数字直接写进媒体查询。这样当然能快速起步，但做几个页面之后就会发现，只按设备型号设断点，维护起来很容易僵。

到了 2013 年，很多网站已经不能再只盯着桌面浏览器了。手机和平板访问越来越多，页面如果还是固定宽度、固定结构，用户体验会立刻掉下来。

响应式设计讲起来可以很大，但真落到一个老页面改造时，最先让人头疼的常常不是整套布局，而是几个特别显眼的元素：一张固定宽度的大图，或者一排在桌面端很自然、到手机上立刻挤爆的导航。

响应式设计刚开始被大量讨论时，很多教程都会先让你加上一行 viewport。代码看起来很简单，但如果只会照抄，不理解它在手机浏览器里到底改变了什么，后面布局一出问题还是容易手忙脚乱。

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

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

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