在 2013 年的前端页面里，表单交互经常是最能体现 jQuery 价值的地方。输入提示、即时校验、动态添加条目，这些需求放在一起时，如果代码组织得不好，很快就会出现重复绑定和状态混乱的问题。

GitHub Issues 一开始用起来很简单，谁发现问题谁就开一条，评论、补充截图、贴 commit，都很顺手。可只要项目稍微多一点需求，Issue 一多，列表就会迅速变成一锅粥。到了 2013 年我自己开始比较频繁地用它协作时，最明显的感受就是：Issue 系统如果没有最基础的标签约定，很快就会从“记录问题的地方”变成“堆问题的地方”。

如果把 2013 年前端开发最有代表性的技术拿出来，jQuery 基本很难绕开。那时候很多页面交互、表单逻辑、弹窗效果，几乎都建立在 jQuery 之上。

2013 年做前端时，只要页面上有搜索、列表刷新、局部提交，基本就会碰到 Ajax。jQuery 把发请求这件事做得简单了很多，但真正容易混乱的地方，其实是请求前后页面状态该怎么处理。

很多人刚用 GitHub 时，会把它理解成一个线上代码仓库：能 push、能 clone、能看文件。但到 2013 年，越来越多人开始意识到，GitHub 真正方便的地方不只是托管代码，而是围绕项目的协作信息也能被放到一起。

刚开始接触 Git 时，很多人最自然的提交信息就是 update、fix bug、change 这种短句。我自己早期也这么写过，因为那时候觉得重点是“先提交上去”，信息只是顺手带一句。但真把代码历史翻回来看时，就会立刻意识到这种写法几乎没有帮到未来的自己。

2013 年如果开始认真写代码，GitHub 很容易成为你绕不过去的一个地方。大家从论坛、网盘、压缩包共享代码，慢慢转向更清晰的版本协作方式，Git 的价值也开始越来越明显。

2013 年开始接触 Git 的开发者越来越多，但很多人最初只会在 master 上一路提交。代码虽然也能工作，可一旦同时改两个需求、修一个线上问题，仓库马上就会变得很难整理。