大公司一如既往地引领着新技术的潮流，据我了解，BAT、360、美团、饿了么等均在自己的技术体系中使用着业界最前沿的东西。然而对于小团队而言，由于技术复杂度产生的维护成本，往往会超出控制范围，以至于对它们累觉不爱，从入门到放弃。所以阿当把这些技术的槽点喷了个遍。
我觉得吧，这事不能一棍子打死，需要有个细分。技术人员中，起码能分出这两种角色：
技术决策者：负责技术选型、项目架构的“架构师”从两者的视角分别看，结论应该是有所差异的。
普通开发者：使用技术栈进行业务开发的“一线工程师”
对于技术决策者，他要对结果负责，所以关心的东西应该更多，比如代码的兼容性、项目组织的难易度、团队开发和谐度、维护成本的高低、新员工学习成本的高低。无论哪一环出了问题，他都是要背锅的。所以当然是求稳。
如果项目非常重要，或者是非常简单，当然没有去冒风险的必要。能写css就不写sass，能用jquery就不用angular。毕竟这些已经稳定的技术，通过一定程度的合理组织，也是能形成一套不错的开发框架的。所以，阿当的理论，对于小公司的技术决策者还是很中听的。
但是，这世界上不光只有架构师啊。对于千千万万一线工程师，我们该何去何从，难道抱着jquery用一辈子？所以我在此处抛出我的观点：从「利己」的角度出发，我们要拥抱新技术。
首先最现实的一个问题，我们要找工作啊。如果你不会sass，没用过mvvm，对gulp/grunt一无所知，你去一线互联网公司面试看看。不光是大公司，很多创业公司也都是用的新技术体系，你现在还是只会jquery那两招，换工作根本没人搭理的。
其次，历史总是向前发展的，现在的一些解决方案哪怕有瑕疵，那也是这个历程中的一部分。一线工程师也是要逐步成长的，你错过了这个历程中的某一环，将来就对接不好下一环。这我是有切身体验的，下面分技术来细说一下。
先说js框架，早在2013年的时候，我就开始研究angularjs，并写了一系列博客。然而由于公司项目的原因，我一直没有在实际项目中用过angular。这么一看，差不多是白学了。
事实上是这样吗？并不是。我学到了mvvm的开发思想，之后在新公司pc段用knockout，移动端用vue，我都能很快上手，就是得益于之前的学习。
对于模块化开发（AMD/CMD/commonjs）也是这个道理，你可能暂时不用，或者说有些东西未来会被淘汰，但是你也需要在合适的时间把它学会。现在业界大多用commonjs规范在开发，未来肯定全部用ES6的模块化标准，但是你也得知道AMD和CMD它们是什么东西，有哪些特性，为何会没落。你才能更好的了解未来的模块化方式的优点。
再说构建。以前是没有前端工程化的，直到grunt开始风靡，大家都用它来构建项目。grunt目前基本被gulp给替代了，尽管很少有人知道grunt今年才发布了1.0版本。gulp的风头也渐渐不行了，后来有了browserify，现在大家又开始用webpack了。
这么频繁的更迭，总是有他的原因的，后者肯定是解决了前者的痛点，或者说是提供了全新的解决方案。每一个工具的出现，总有他的思想包含在里面。比如webpack的理念就是以模块为核心的构建。未来很多还有有新的构建工具出现，如果你在那之前已经对这些思想有所掌握，上手就会很快，不至于知识断层。
还有一块是预处理，常用的如babel编译ES6以及sass/less的预编译。环境的搭建是有点麻烦，不过是一次劳动终身受益的，还能接受吧。就算你不喜欢预编译这件事，那也还是要学的，毕竟这是历史进程的一个环节，你明白它不爽的地方，将来有新方案出来就能更快理解。
再有就是nodejs。在搭建前端构建环境的时候，nodejs是多多少少要写一些的。开发项目可以用express，我们搭建环境本地也会起express，所以并不是不用nodejs写项目，你就一点也用不到它。
尽管对于大多数前端，离nodejs还是有点距离的，这取决于你公司的项目架构，不把nodejs用到业务代码上，我们写的nodejs代码还是很有限的。但我还是那句话，代码可以写的少，但是不能不去了解它，重要的是掌握思想，为以后的新技术接轨。
我的看法差不多就是这些啦！正如我上面说的，作为千千万万一线程序员中的一员，不说别的，先从利己的角度考虑就行了。我平时面试到的一些前端，工作三四年了，还是只会jquery，立马就pass了。这都是事实，换别的公司也一样。
来源：医小生与程序猿
/3 
