为什么要学习前端技术？

前端一直以来是一个颇具争议的领域，有人极其喜爱，有人避而远之，和多数“天下太平”的技术相比，这确实有些令人费解，但我认为这其中的原因至少包括这样两点。

• 第一，某些技术人员或管理者单项技术进步，但思想却依然陈旧迂腐，停留在“前端就是改改页面”这样老旧的思维程度，认为前端没有技术含量且无法创造显著价值。
• 第二，相对于软件领域的通用技术，前端极低的入门门槛，导致号称“懂前端”的工程师技术水准严重参差不齐，这反向影响了整个技术群体的形象。

如果你志在学习全栈工程，前端就自然是你无法避开，且还需努力驾驭的领域。但即便你的长期目标不在此，也应该学习前端技术，因为它能给你带来的好处是多方面，且是别的技术所不可替代的。具体包括这样几个方面。

• 首先，它可以帮助你开阔眼界，为你的思维模式带来新的选项，整个全栈技术都有这样的特点，但是前端技术在这方面尤其明显。
• 其次，它可以帮助你形成快速原型、即时验证和独立展示演示的优势，在迅捷的反馈中设计和编程。(震惊)
• 再次，它可以帮助你建立产品思维。
• 最后，前端技术是全栈工程的必备技能。

遗憾的是，现实中有不少迈入职场没有几年，却已经给自己打上“前端工程师”“后端工程师”等标签的程序员朋友。我觉得他们可能是受到了某些万恶的职业生涯规划鸡汤的影响，这些标签会让他们在面对新技术和新机遇的时候，觉得身处“不属于自己的领域”而选择封闭自己。

因此我的建议是：职业生涯不宜过早做过细的规划，除了技术深度，也需要在技术广度上积累，等到一定程度以后再来选择自己的发展分支路线。而且，某些特定技术领域，在程序员给自己打标签的时候，压根还没有发展成熟，等到发展起来，时机真正到来的时候，只有那些原本“不偏食”的优秀的程序员才能够脱颖而出。

思维模式的转变

应用事件驱动编程

而在 JavaScript 中，在浏览器中，你看到眼花缭乱的效果和变化，却是“假并行”，是一个彻头彻尾的“骗局”。为什么这么说？

具体说来，在整个 JavaScript 的世界里，引起代码运行的行为是通过事件驱动的，并且全部是通过这唯一的一个勤奋的工作线程来执行的。那么当有事件产生的时候，这个工作线程不一定空闲，这就需要一个机制来让新产生的事件排队“等一等”，等当前的工作完成之后，再来处理它。这个机制就是 Event Loop，这个等一等的事件，就被放在一个被称为事件（回调）队列的数据结构中。

console.log("1");

setTimeout(function timeout() {
    console.log("2");
}, 0);

setTimeout(function timeout() {
    console.log("3");
}, 5000);

console.log("4");

于是上面的代码，实际在运行的时候，从事件队列的角度看，是这样的：

image.png

主代码最先被执行，从上往下顺序执行，因此顺序是：

1. 先打印 1；
2. 在遇到第一个 setTimeout 的时候，告知浏览器，请在 0 秒之后往事件队列内放入执行打印 2 的事件；
3. 在遇到第二个 setTimeout 的时候，告知浏览器，请在 5 秒之后往事件队列内放入执行打印 3 的事件；
4. 再打印 4；
5. 主代码执行完毕，Chrome 的控制台打印这段代码的返回值，但因为它没有返回值，于是就打印 undefined。

实际输出:

console.log("1");

setTimeout(function timeout() {
    console.log("2");
}, 0);

setTimeout(function timeout() {
    console.log("3");
}, 5000);

console.log("4");

基于线程与事件驱动的比较:

image.png

• 对于逻辑的触发，基于线程编程需要不断地由监视线程去查询被监视线程的某一个状态，如果状态满足某个条件，则触发相应的逻辑；
• 而事件驱动则通过事件处理器，在事件发生时执行挂载的回调逻辑。
• 不知你是否联想起了 [第 03 讲] 中我介绍的 push 和 pull，在这里，前者正类似于 pull 的形式，而后者则类似于 push 的形式。

基于线程的方式可以阻塞线程，等待时间或某个条件满足后再继续执行；而事件驱动则相反，发送一条消息后无阻塞等待回调的发生。阻塞线程的方式对资源的消耗往往更加显著，因为无论是否执行线程都被占用，但从人直观理解的角度来说，代码更直白，更符合人对顺序执行的理解；而事件驱动的方式则相反，资源消耗上更优，但是代码的执行顺序，以及由此产生的系统状态判断变得难以预知。

另外，需要说明的是，浏览器的 JavaScript 执行是单线程的，但不代表浏览器是单线程的。浏览器通常还包含其它线程，比如说：

• 界面（GUI）渲染线程, 这个线程的执行和上述的 JavaScript 工作线程是互斥的，即二者不可同时执行；
• 事件触发线程，这个也很好理解，我们介绍过有一个神秘人物帮着往队列中放入事件（例子中的回调打印 2 和回调打印 3），这个神秘人物就是事件触发线程。

学写声明式代码

声明式代码和命令式代码一样，都需要设计，且都需要测试。

举例来说，设计页面的时候，要先设计布局，抓住整棵 DOM 树中核心的部分，自上而下地去划分区域，哪些是静态的区域，哪些是动态生成的，并合理设计可重用组件。再比如说，使用声明式代码处理模板中呈现数据的格式转换，使得呈现部分的代码更纯粹、自然，具体请参看 [第 16 讲] 中的过滤器。

培养交互思维

前端工程师必须具备敏感的交互思维。通常来说，前端的代码，兼具着“甲方”和“乙方”的角色：

• 对用户和前端的交互来说，客户是甲方，享受服务；前端就是乙方，提供服务。
• 对和服务端的交互来说，前端就是甲方，从服务端获得数据和服务；服务端就是乙方，提供数据和服务。

和用户的交互要求开发前端的程序员具备产品思维，而和服务端的交互则要求开发前端的程序员具备工程思维。

扩展阅读

• 你可能听过这样一句话，“任何能用 JavaScript 写的应用，最终都会用 JavaScript 来实现。”这句话最初来自 The Principle of Least Power 这篇文章，写于 2007 年。
• 有位工程师做了一个名为 Loupe 的网站，用动画来形象地展示事件循环的过程，本文的例子也可以在它上面运行。
• 为什么浏览器中 JavaScript 代码的执行设计成单线程的，还有一个文中没有提到的原因，就是多线程的 GUI 特别容易死锁。这篇文章 Multithreaded toolkits: A failed dream? 描述了其中的缘由，大致是说 GUI 的行为大多都是从更高层的抽象一层一层往下调用到更低层的抽象、具体工具类实现，再到操作系统；而事件则是反过来，从下往上冒泡。结果就是两个方向相反的行为在碰头，给资源加锁的时候一个正序，一个逆序，极其容易出现互相等待而饿死的情况，而这种情况下要彻底解决这一问题的难度无异于“逆转潮汐”。
• 浏览器的工作原理：新式网络浏览器幕后揭秘，这可能是在互联网上流传最广泛地介绍浏览器工作原理的中文文章，非常推荐。

公众号：码农架构