01 前世今生：前端全链路的演进历程
你好，我是三桥。
我们在开篇词说过，前端全链路能够在发现问题、定位问题、判断链路问题、解决问题这4个方面帮我们解决效率上的困境。
这么好的解决方案是怎么发展出来的呢？这就需要我们先回顾一下前端技术的发展历程了。
这节课，我会带你了解前端全链路每个关键时期的演变节点。相信通过这节课的学习，你会更了解前端工程师的职责，更能深刻理解全链路的意义，在工作中找到解决项目问题的思路和方法。
在前端全链路真正被广泛应用之前，前端技术经历了4个重要时期：Ajax和jQuery的页面生态、前后端分离、前端工程化和大前端时代。
不过这次，我们要再往前一点，从“页面仔”这个前身说起。
前身：为什么叫我“页面仔”？
1990年，第一个Web浏览器诞生。1991年，世界上第一个WWW网站实现。Web的出现最早是为了解决信息共享和交流的问题。当时Web还不存在JavaScript和CSS语言，主要以纯静态页面存在，即只有极其简单的HTML页面，没有任何交互动效。
后来，随着互联网迅速发展，出现了许多不同的浏览器，新的编程语言被开发出来，HTML也逐渐升级、完善。这些发展都给前端技术提供了最佳的环境基础。虽然浏览器提供的Web能力还是很基础，例如有限的HTML标签，还有只用10天就设计出来的JavaScript语言，但这些已经为前端实现动态交互页面提供了基本条件。
不过，还有一个问题。当时设计出来的JavaScript语言缺陷非常多，加上浏览器厂商之间竞争激烈，不同浏览器没有完全按照规范去实现支持（特别是IE浏览器），导致网页的实现需要兼容多种不同浏览器场景。
总的来说， 这时期的Web还在萌芽阶段，不存在前后端分工的概念。 基本上只要是负责编程的开发，就会涉及Web技术的开发，可以说此时基本上是混合式开发。
为什么这个时期的前端开发者被认为是“页面仔”？就是因为，每一个页面都是基于现有HTML和JavaScript来实现的，而且还不存在读取后端接口数据的逻辑。即使出现PHP/JSP/ASP等动态语言，也不存在真正意义的前后端分离。基于这样的场景，前端只需负责好页面的展示即可，不存在和其它端的协助关系。
在解决用户问题的时候，这个阶段的开发同学会面临2种限制。一个是Web技术能力受限，一个是浏览器场景兼容。
但也正是在这个时候，动态语言开始发展。 此时Web页面的全链路问题排查、调试和优化，基本上都以解决浏览器页面兼容问题、处理脚本错误、结合动态语言调试等页面优化为主。 就算和动态语言结合在一起，整体的全链路优化都是以服务器渲染数据为主要判断依据。
虽然这个时候还不存在全链路的概念，但是，前端同学处理的问题主要就是4种类型， 兼容、 数据、 交互、性能。这4种类型 基本上形成了前端全链路最核心的问题维度。 其中，兼容维度是这个时期最核心的问题。因为浏览器兼容问题很突出，所以这是占据前端同学最多时间的工作。
基础：Ajax与jQuery的诞生
在经历了前端页面兼容浏览器的痛苦后，大量国外开发者和浏览器厂商都在想尽办法统一前端的技术标准。因此，W3C正式成立，它专注于为Web提供发展方向，通过标准协议，促进Web生态的发展。
后来，又出现了两个技术生态让前端的技术生态蓬勃发展。一个是Ajax，另一个则是在当时几乎统治Web开发的框架jQuery。
Ajax的诞生
Ajax的出现解决了前端开发的核心问题：页面需要更新状态或数据时，必须重新请求页面。由于Ajax的优势非常突出，所以无论是浏览器厂商还是W3C组织，都在全力支持这项技术。现在，页面几乎无需刷新，就能获取服务端的数据，还能局部更新页面。
不过微软的IE浏览器仍然依据自己的技术标准去支持Ajax，由于IE浏览器的市场份额很高，导致开发Web页面时兼容性的问题非常突出。这样的变化其实对于前端同学来说是加大了开发难度的，因为天生缺陷的JavaScript需要对页面DOM不断做添加、更新、删除等各种操作，降低了复杂页面的开发效率。
jQuery统治整个Web生态
jQuery的出现，解决了过去种种前端开发过程的3个核心问题。
- 解决了多年来前端开发使用JavaScript操作DOM的各种问题。jQuery以DOM为中心，研发出Sizzle选择器引擎，这也是它最大的优势。
- 解决了浏览器兼容性的问题，大大提升开发效率。
- 内置支持了Ajax技术，和服务器之间的通讯更加轻便。
正因为jQuery的发展，其扩展性得到了社区的认可，所以，周边插件也呈现了百花齐放的局面，各种UI组件也不断涌现。此时的前端已经能实现很多很酷炫的页面，甚至开始逐渐替代Flash，成为动画效果的首选。
但随着页面复杂度的提升，jQuery开发效率逐渐出现问题。正好，社区也出现了一些AMD或CMD的模块化开发模式，希望降低代码复杂度，提高开发效率。
再到后来，Node.js诞生，越来越多前后端程序员逐渐认可前后端分离的开发模式，甚至包括一些原本在后端领域的程序员，都放弃了原本熟悉的编程语言，转移向Node.js发展，一起推动前后端分离的技术。
经过这一波的技术更新，在全链路的4个维度中，数据维度和交互维度一下子发生了很大的变化，我们通过这张图来看一下。
数据维度的问题分析几乎不再需要前端参与了，底层数据的业务流转直接可以交给服务端的同学来跟进。前端同学只需要解决 从浏览器向服务器端请求接口数据的链路过程问题，做好状态维护，保障数据的准确性就可以了。
雏形：前后端分离和雅虎34条军规
在不刷新的情况下，JavaScript脚本就能够和服务端不断地传递信息，并不断地改变页面的数据、动画、界面。基于这样的特性，前端开发的逻辑变得更加复杂。说到这，就不得不提两个概念，前后端分离和雅虎34条军规。
前后端分离，意味着前端和后端的职责逐渐变得更加清晰和独立。前端开发的功能频繁地和服务端通讯。但是要知道，用户的真实网络环境和操作方式是非常复杂的，经常会出现各种不可预估的异常情况。此时，用户体验逐渐成为前端工程师不可忽略的要素。
要实现更好的用户体验，就需要我们结合前端全链路分析用户的操作过程，确保前后端数据流转的准确性以及维护页面的状态变化。
比如一些你几乎天天都在思考的发起请求问题，用户有没有接收到服务端返回结果，脚本出错或者白屏问题。遇到这些问题的时候，就需要结合链路日志和实际发生的问题去解决，同时还要复盘如何避免重复发生。不断循环这种解决问题的工作流程，是前端全链路优化里最常见的工作。
我们来看看一次用户表单提交的前后端链路大致流程。
用户每一次完成页面的所有事项，都会形成上图所示的一条唯一链路。只要把每一个环节通过一定机制关联起来，那么这条链路就能做到可溯源、可追踪。
前后端分离，是前端全链路最核心的链路环节之一，关联了4个维度中的数据维度和交互维度。其中，数据维度确立了一套开发联调、生产链路日志的问题解决公式，即使到现在，这条公式依然不变。
在交互维度方面，前后端同学只需提前协商好数据的协议、字段类型和字段值，就能让前端同学提前基于数据来实现各种页面交互逻辑，俗称“使用Mock数据做页面”。
在这种分工模式下，一个特别重要的效率提升点是减少前后端同学之间的协调和沟通成本。一旦接口协议协商完毕，前后端开发人员就可以分别安排开发计划，无需相互等待，只需简单地进行联调即可完成任务。这种效率提升已经成为现今研发团队中最常见的协作方式之一。
再说说雅虎34条军规。 在这个时期，Web页面加载慢成为大部分前端开发核心的问题之一。雅虎发现，影响Web性能的问题大部分都是前端引起的，加上早期的浏览器的性能有限，因此，雅虎给出了优化网站加载速度的34条军规，直到现在，大部分军规仍然适用。
不过，不管什么样的军规，既要Web性能好，又要减少各种文件和数量，一般都是很难平衡的。因为优化实际上就是让产品功能和性能之间相对平衡，确保优质的用户体验和交互。
这种时候就要综合考虑了。在全链路的4个维度中，兼容维度和性能维度在雅虎34条军规里更像是一个经过约定的技术规范，通过规范约束前端同学，这样就不会出现问题了。
好，总结一下。Ajax的诞生以及jQuery生态的发展使得前端全链路中的前后端日志得以关联，形成可追溯的链路。通过链路日志和数据，我们能够快速定位数据维度方面的问题。另一方面，随着前端交互逻辑逐渐复杂，许多性能问题需要前端开发人员解决。雅虎的34条军规恰好为我们提供了解决前端性能问题的最佳参考。这么一看，全链路已经初具雏形。
变化：进入前端工程化阶段
随着谷歌浏览器（Chrome）在浏览器大战中崭露头角，逐渐成为主流浏览器，Web开发以及Web技术栈迎来了新的格局。像jQuery这种工具类的JavaScript框架逐渐落下帷幕，基于MVVM的前端开发模式逐渐成为主流。
至此，前端的发展正式进入工业化阶段，也就是我们常说的 前端工程化。
我们复盘一下当时的情况。当时的前端工程师并没有统一的规范和标准。随着前端项目的功能越来越多，代码越来越庞大，前端模板以及JavaScript业务逻辑尤其臃肿，任何一个前端同学接手历史前端项目，都会非常痛苦。
试想一下这样的场景。在一个前端营销活动落地页项目里面，经历过一年的迭代后，活动页面多达100个以上，每个活动页面都有一个目录，里面全是HTML、JavaScript、CSS目录结构的代码。只要产品提一个新活动需求，那就要参考某个历史活动的功能。很多初中级前端工程师可能就是直接复制活动目录，然后再基于复制后的代码进行修改。一个项目的所有落地页历史放在一起，代码就非常臃肿。
那MVVM是怎么解决这个问题的呢？
MVVM最大的特点是有效地分离Web应用的页面逻辑和业务逻辑。这种分离模式的背后是由组件化和模块化的开发模式提供的强大支持。这样的开发模式让我们开发出来的代码变得可维护、可测试、更加灵活。
其中最具代表性的MVVM开发框架是Facebook的React和开源的Vue.js。这两套前端开发框架让组件化和模块化的开发模式发挥到了极致。
正因为前端的工作从开发页面变成开发组件和模块，我们才能通过前端全链路去维护组件和模块之间相互调用的链路。每当发生故障时，我们就可以查询这些链路日志，快速定位问题。
又因为出现了大量开源UI组件库，前端同学实现前端复杂交互页面变得更加简单，所以交互维度的重要性在这个阶段里逐渐在降低。而随着前端功能复杂度的提升，加上后端业务数据开始出现了画像特性，数据维度在这个阶段变得极为重要。
百花齐放的技术框架，让前端一下措手不及。不过，无论前端框架如何变化，始终离不开W3C定义标准协议，离不开前端技术的三个底层技术，HTML、JavaScript和CSS。
成熟 ：大前端时代
自从Vue和React流行后，这两套框架已经成为前端同学技术选型的首选框架。它们周边的技术生态发展得也很快，比如前端工程化、工具库、UI组件库、SPA页、SSR前后端同构、协同和效率等等。
就这样，前端的工作和职责一下子变得越来越重要，以前被人称为页面仔的前端，现在可以完成大型Web应用的开发，有属于自己的工程化和规范，还能承担封装各种UI公共组件。
所谓的大前端到底是什么呢？
从分工角度来说，职责越来越细分，有的只需负责工程化和规范，有的负责设计和开发公共UI组件，实际上负责一线业务的还是占大部分。从满足用户端这个角度来说，大即“全面”。这个时期的产品非常多样，加上前端是站在最前线的研发，所以，保障用户端的业务流程和交互就是最重要的职责。
这个职责和全链路又有什么关系呢？
- 业务的变化
因为Vue和React最大的优势是组件化和模块化的开发模式，再加上浏览器性能的提高，所以前端逐渐承担了大量的业务场景。
以前的业务逻辑大部分都是在服务器端完成，再交给前端页面渲染的。现在却反过来，服务器只需维护少量业务数据，其余业务逻辑和交互逻辑都交给了前端实现。结果，前端大量业务都在用户侧完成。那用户发生问题了，我们根本了解不到用户的问题场景和交互情况，没法第一时间了解用户行为。
不过，前端全链路的作用就是追踪用户的交互行为，所以我们只需要在项目中记录用户的实际业务流程就好。
- 技术标准的升级
随着前端技术标准的升级，前面提到Ajax技术逐渐被Fetch标准替代。两者虽然最终的效果是一样，但Ajax更偏底层一些，要真正使用它还需要一定的封装。Fetch不一样，它更接近标准接口。所以，现在越来越多项目用到了Fetch。
从前端全链路的实现来说，我们是需要在链路中关联前后端接口之间的链路的，而通过Fetch标准更容易实现。
- 生态
首先，小程序。我们都知道，自微信小程序诞生以来，各个平台都推出了自己的小程序生态圈，例如支付宝小程序、抖音小程序、京东小程序、百度小程序等等。
由于各平台的小程序底层实现存在差异，所以对于前端同学来说，在一套代码里兼容多端的小程序就是最强烈的需求。后来诞生的Taro和Uni-app小程序框架，就是为了解决多端编译的问题。
虽然小程序框架解决了多端小程序的问题，但往往用户在使用小程序时遇到的问题，我们都无法准确定位，甚至提前发现。特别是某个用户在某端小程序下登录不了这种问题，要真正定位排查问题，非常痛苦。
如果能够利用前端全链路的方案，去记录每个用户使用的是哪一端小程序，记录用户的操作日志，行为日志，登录日志。那么排查定位问题，就相对更简单了。
除了小程序，还有另一种场景： PC端。我们所认知的传统PC端开发都是基于C/C++、Python、C#、Delphi、VB、Java等编程语言。
但自从谷歌发布了Electron框架后，基于Electron技术架构的PC软件成为最受开发欢迎的技术选型，要知道Electron也是内置Webkit内核的应用程序框架，其上层应用的实现方案都是使用Web技术栈（HTML、CSS、JavaScript）实现的PC应用。而且，Electron提供的能力比浏览器更强大，并且提供了很多底层能力，比如读取文件的能力，与本地设备通讯的能力。
这么多的用户行为交互发生在用户端，万一用户在使用过程中出现问题，如果没有前端全链路，那就很难基于个例用户进行定位。特别是Electron版本很多，有些版本甚至在某些电脑配置上特别容易出现不可预知的缺陷。
有了前端全链路，至少能还原用户行为场景，通过链路日志重现步骤快速定位问题根源。
除了PC端，前端的能力还延伸到了 App端。在前端圈子里面有2种特别的技术栈，分别是React Native和Weex。它们都是基于React和Vue框架延伸出来的一套实现原生App的框架。实际上，他们的最终目的都是希望利用一套前端代码实现支持iOS和安卓两端的App。
但从前端全链路角度来说，跟小程序和PC端的道理一样，大量业务逻辑在用户侧使用端底层能力，这就会被用户设备和网络等多种因素影响，如果没有从全链路的视角去做埋点和分析，我们很难快速定位用户问题和提升用户体验。
最后，还有多屏和大屏 的问题。 5G的发展，带动了物联网、车联网、工业互联网、人工智能、智能家居等其它行业发展。这些行业场景非常特殊，既有触摸类的交互，也有语音、动作、按键等其它交互形式。这些行业还有一种特点，就是有一种或多种屏幕存在。
例如电车领域，每一台电车都自带有一个大屏幕和一个声控硬件，通过声音传送到硬件，再到屏幕；还有工业互联网，每一个接入工业流水线里的硬件都会自带一套可视化监控大屏，用来监控流水线操作的实时情况。
这些屏幕所展示的所有界面，基本上都是由前端实现的。由于屏幕大小、交互方式多样化，前端同学遇到问题时，很难做到快速定位问题。要是有了前端全链路，我们就能通过监控提前发现问题，而不是等到客户反馈。
从大前端时期到现在，前端技术能带来的价值已经不是一个普通页面那么简单，是一个实实在在的专业领域。而且，交互维度和性能维度是前端同学经常关注的核心问题。
现阶段，前端技术的核心价值是满足用户端交互多样化的能力，而前端全链路，就是保证用户交互操作出现异常时能够及时反馈到研发团队并优化的重要基础。
小结
本节课，我们讲到了前端技术发展的几个重要时期。
早期前端页面的主要作用是展示页面信息以及简单的交互，这个时期的前端虽然还不存在全链路的概念，但给将来的前端全链路优化提供了4个基础核心维度： 兼容、 数据、 交互、性能。
随着Ajax和jQuery迅速发展，前端和后端分离的开发模式开始发展。就这样，前端全链路的概念也正式进入前端领域。直到MVVM模式以及大前端时代，前端的开发模式已经进入成熟阶段，此时的前端全链路已经具备了全链条问题排查的能力。
前端全链路这项技能，需要我们不断实践、反复强化，锻炼好自己的编程能力，学会兼容技能、数据分析技能以及性能优化等一系列综合素质能力，相信学完这套课程的你，一定会大有不同。
思考题
在你过往的前端开发经验里面，有没有哪些工作、哪些问题的解决困扰着你呢？还有哪些问题自始至终你都没办法定位和解决呢？
还有，你在使用其他产品的时候，有没有遇到过前端的问题呢？你又会如何看待其他产品前端解决问题的质量和速度呢？
不妨带着这样的问题，往下继续学习下一节。欢迎你在留言区和我交流。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！