谈谈前端『新』技术

对待新事物的态度问题

我这个人在技术讨论的时候信奉很简单的一个道理：没有研究过就没有发言权。对于我不懂的东西，我要么闭嘴，要么去研究、试用之后再开口。在我看来，这是进行技术讨论的一种基本涵养。技术这个行当，永远会有新东西出来，不进则退。更关键的是，前端比起整个软件工程乃至计算机科学体系来说，是个相对新生草莽的领域，近年来前端生态的发展其实都是在向其他领域吸收和学习，不论是开发理念、工程实践还是平台本身（规范、浏览器）。所谓的『根正苗红』的前端，不过是整个发展进程中探索的一个阶段而已，那个时代的最佳实践，很多到今天都已经不再适用。过往的经验固然有价值，但这些经验如果不结合对新事物本身的了解，就很难产生正确的判断。这里需要强调的是，学习新事物并不是为了不考虑实际需求的滥用，而是为了获取足够的信息从而作出更靠谱的判断。在这一点上，某人的态度是不停强调自己过去的八年资历，强调『经验和观察』的重要性，却对新事物本身采取蔑视和抗拒到了夸张的程度，宁可在微博上撕逼，也不愿意花一两个小时翻墙了解一下外面的世界。举例来说，他在批评 Angular/React 的时候是以『就是把服务器 MVC 那一套搬到了前端』这样的预设去批判的，完全鸡同鸭讲；在阐述他自己那套 Widget + OO 的时候，也压根不了解这套思维和现在基于组件的新框架的共通点。这样偏颇的思维方式，如何做得出靠谱的决策？作为一个技术负责人简直可以说是不负责任。盲目跟风不可取，盲目抗拒也不可取，要有自己的判断，但是这个判断要建立在足够的一手信息量基础上。

为什么要用『新技术』？

说完态度，我们来深入谈谈为什么这些『新技术』会有市场。首先明确一点：任何技术都有针对的适用场景取舍。在对一个技术进行评估后发现不适合，这很正常，比如项目的类型、规模、历史包袱，以及团队的学习能力，都是制约技术选型的因素。但这并不妨碍我们分析一项技术本身解决了什么问题，以及我们的实际需求中是否存在这些问题。接下来我们一项项分析：

1. CSS 预/后处理器甚至可以抽象出常用技巧的混入，比如一个混入解决垂直居中，大大加强 CSS 代码的书写效率和可维护性。@import 引入其他文件会产生过多的请求，而预处理器可以直接合并成一个文件，在文件组织上不再有顾虑。

2. JavaScript 编译器

3. 模块化/构建工具RequireJS, SeaJS现在已经渐渐式微了，那为什么要有后面这三个？其中一个核心价值在于基于模块规范的包管理方案。由于对于 Node 包格式的兼容，使得后面三个方案都可以利用 npm 作为包管理的机制。有了包管理器，你可以将跨项目的基础库进行细粒度的单独封装，通过 semver 版本保证 API 兼容性，在多个项目中按需复用代码逻辑，还可以直接使用发布在 npm 上的海量第三方库。更进一步，配合下面要提到的组件化框架，更可以实现 UI 组件的跨项目复用。SeaJS/spm 和 Arale 其实有这个愿景，但是玉伯明智的发现了社区的方向而选择了避免重复的努力。

4. 组件化框架在大型应用里，还要考虑如何让一个事件的后果能够被清晰的理解，让一个开发者可以迅速理解另一个人的代码的意图，让应用不会随着规模的增长而失控？这则是 Flux Redux 这样的状态管理方案试图解决的问题。其核心在于让副作用可控，最终目的也是可维护性。