阿里妹导读：尽管大部分前端的工作并不涉及 server，但最近半年 serverless 这个词汇以及其引发的热烈的讨论，深深触动了阿里巴巴高级前端技术专家伐薪。作为接触前端十余载的老开发，伐薪认为 serverless 可能会是接下来引起前端领域革命性变化的技术之一。
今天，伐薪将为大家梳理 serverless 的历史发展进程以及对前端的影响，希望对前端工程师有所启发。
上图是 serverless 这个词最近 5 年在 google 的搜索趋势，可以看到最近半年已经达到巅峰。
历史上前端领域的重要技术革命
Ajax 的诞生
先来回顾一下前端技术领域的重要历史节点，第一个节点是 2005 年，google 的 Jesse James Garrett 发表了一篇文章——《Ajax：Web 应用程序的新方法》，首次发布了 Ajax 这个新的词汇（准确说并不是新的技术，只是新的词汇），当时我还在读大二，虽然 ajax 不是什么新的技术，只是对 XmlHttpRequest 等技术的包装，但是这个技术被 google 宣传之后成为全球 web 开发的标杆，间接促进了富客户端应用（RIA）和单页应用（SPA）的流行，这些应用大都具备丝滑般的体验（局部刷新），并一直伴随着 web 2.0 的发展，ajax 的深入人心，使得前端 js 的工作更加复杂和重要，专业分工越来越细，间接促进了专职的前端开发人员这一角色诞生，在此之前，web 开发并不区分服务端和浏览器端的工作，因此 ajax 是前端领域的第一次重要事件。
Nodejs 对前端规范化和工程化的促进
接下来对前端变化最大的一个里程碑事件是 2009 年诞生的 nodejs（包括 common js 及 npm）的出现和流行，它对前端领域的重要意义并不仅仅是让前端可以快速用 js 写 server 那么简单，个人认为它最大的贡献反而是 commonjs、npm 以及其便捷开发体验促进的前端工程化，它使得前端开始从刀耕火种的和传统软件工程格格不入的部署方式，发展为接近传统企业应用的研发模式，在此之前，前端开发在资源引用、依赖管理以及模块规范上缺乏有效的工具和标准，但是 nodejs 流行以后，基于 commonjs 的模块及 npm 的包部署和依赖管理成为主流（类似 java 的 maven 体系），并诞生了多种基于 nodejs 开发的 cli 工具辅助前端开发（如 grunt、gulp），npm 目前是全球最大的包管理仓库，并且成为前端项目的包依赖管理事实标准。而 webpack 的出现，又使得前端代码的部署更加简便，让前端可以以类似 java jar 包的形式发布应用（bundle），而不管项目中是何种类型的资源。
React 的组件化及 vdom 理念
第三个革命性事件是 2013 年开始出现的 react，尽管 web components 标准在此之前早已发布，但是真正让组件化理念深入人心并且应用最广的库是 react，它还至少有两点特性足以让它成为历史上最具前瞻性的前端库，第一个特性是 vdom 的出现，在此之前，所有的 ui 库，都直接与 dom 关联，但是 react 在 UI 创建与渲染引擎之间，增加了一个中间层——vdom（一个使用轻量级 json 描写 UI 结构的协议），除了改善了其本身的 dom diff 性能之外，还有一个重大意义就是 UI 的编写与渲染开始分离，一次编写，多端渲染的 UI 得以实现，这个多端包括 server 端、移动端、pc 端以及其他需要展示 UI 的设备，之后的 react native 以及 weex 都是这一分层思想的受益者。
除了 vdom 之外，react 还有一个重要的理念非常超前，即 UI 是一个函数（类），函数输入一个 state，一定返回确定的视图，在此之前，大部分框架和库，都会把 UI 分离成一个 html 片段（通常支持模板写法以渲染数据），一个为该 html 片段绑定事件的 js，尽管这样比较好理解，但是 react 对 UI 这种抽象却反映了 UI 的实际本质，并且这种函数式理念，在后面可以看到，将与 faas 及 serverless 技术产生美妙的碰撞。
react 的诞生对此后，甚至此前的框架和库都产生了深远的影响，包括不限于 angular 和 vue 都陆续采纳了它很多技术思想，并且成为前端开发领域目前已经趋于稳定的屈指可数的几个技术选型之一。
再来总结一下，ajax 使得前端的角色逐渐分离出来，nodejs 促进了前端的开发模式向传统编程语言靠近（工程化），react 的出现，基本结束了后端常常对前端”技术变化快“的吐槽，至此，前端的技术体系逐步成熟和标准化。
serverless 理念与前端的关系
那么为什么说下一次对前端技术领域有较大影响的理念是 serverless 呢，事实上，尽管 serverless 这个词汇由亚马逊提出来还不到几年，但是这个理念并不是什么爆炸性的新理念，在早期，cdn 还不普及的时候，web 工程师会把 js 资源和视图文件（可能是静态也可能是动态的）传到服务器，那个时候前端是需要关心服务器的，但是 cdn 及回源策略的普及，工程及搭建系统的大规模使用，使得前端可以快速把一个 js 或者静态文件扔到 cdn 节点，通过回源机制（cdn 回源到一个动态服务），半动态的视图层渲染也成为可能，在这整个过程，前端开发无需关心任何服务器的知识，也不知道 cdn 有多少节点，如何做负载均衡，做 gslb 的，也不需要知道 qps 多少，一个 cdn 可以放各种业务各种开发的资源，可以说 cdn 是 serverless 理念的的先行者。
回到应用部署，在前几年 nodejs 刚流行的时期，已有开发者意识到应用与机器的部署与运维成本对业务方会是个问题，出现了一些容器化的思想，比如 cbu 在 15 年出的 naga，在这个 naga 容器里，业务逻辑是一个个插件，容器负责请求的路由分发，负载及稳定性管理，业务方只需要编写并上传最直接的业务代码即可，对业务方来说是实现了 serverless 的理念，因为 naga 的维护者帮你解决了部署及运维的问题。
再说对前端息息相关的页面搭建系统以及 bff 层，无论是各种搭建系统（如斑马、积木盒子、TMS），还是基于 graphQl 的平台，还是通过 web ide 快速编写 api gateway 的产品——如 cbu 的 mbox，都让业务开发只关心业务逻辑，无需关心部署运维知识，它们一定程度上体现了 serverless 的理念。
serverless 将对前端的影响
综上所述，前端早已与 serverless 产生了联系，但是很多人还没感知，接下来，serverless 显示化地爆发将给前端带来更为深远的影响，主要体现在三个方面。
前端将会重新回归到 web 应用工程师这一职能
在最前面说了，前端是社会分工的细化，大约起源于 2007 年左右，在此之前是没有专门的前端开发角色的，通常称作 web 工程师或网站工程师，早期的网页大都是服务器渲染，使用 asp、php、jsp 等 server page 技术，js 仅仅是 web 工程师需要掌握的小小技能之一，但是随着 web 2.0 及互联网、移动互联网、电子商务的发展，需要专门的人专注于编写具备很好兼容性和体验的 UI，因此逐渐产生了专注于浏览器及移动端的前端工程师。
但是前端技术领域逐渐趋于稳定，伴随着十几年的发展，各种开箱即用的库、垂直方案以及工程手段唾手可得，甚至目前出现了一些辅助工具可以把设计师的视觉稿生成 UI 代码，前端可以安心并且以非常低的成本编写 UI 和业务逻辑，而不用耗费大量精力在选型、造轮、还原视觉、处理兼容性、性能优化、调试和部署上，这种情况，前后端工种分离造成的协同成本反而放大了，因为在前后端角色分离的情况下，后端往往还会充当 bff 层的角色，比如为前端表现层封装各种 api gateway，经常出现相互等待、联调协议的情况，而且 bff 层通常只是一些数据的加工，其他的角色经过短期的培训可以快速上手，因此前端一直在尝试接入到 server 端的 bff 层。
在 15 年前端开始推广使用 nodejs 来部署应用，阿里内外也出现了不少 nodejs 的框架，如业界的 express，在生产环境，包括给买家、商家以及内部人员使用的系统，有不少使用了 nodejs，但是到今年 2019 年，再来回顾一下，发现这个数字并没有超出预期。
造成这一现象的原因，个人认为归根到底还是因为分工太细导致的前端对服务器知识的缺乏，nodejs 本身的定位是服务器技术，本质上在服务器要面对的问题与 java 无异，现有的前端 jd 招聘的人才，鲜有能在服务器上工作游刃有余的人，除非专门招的 nodejs 人才，server 服务的长期运行会暴露很多问题，比如接口很慢，进程 core，cpu 飙升，内存泄漏等，另外负载均衡、扩缩容，高并低延等知识，大部分前端都是没有这些经验的。
云计算的本质就是要让业务开发专注于业务逻辑，业务之下的硬件及软件设施都是按需采买，开箱即用，而 serverless 理念及相关技术，将使得开发人员不再需要关心应用及机器的问题，甚至连流量能不能撑住也不用关心了，它能自动扩缩容，因此，未来 web 开发人员的运维成本会大幅降低，前端也可介入到 bff 层的开发，而后端可以聚焦于数据处理、业务逻辑与算法。
这一变革符合研发效能提升的背景，未来的云设施将会做得非常厚，非常专业、稳定，而前台开发人员可以快速地，最低成本地在云设施上建立业务逻辑，前端和服务器的前端（对整个请求链路来说，前端是相对的，只要离客户请求更近的角色都可以称自己为前端），分工将没那么明确，以前的浏览器端的前端，将逐步承担一部分服务器端接入层以及 bff 层的工作，返璞归真，回到历史上曾经的 web 开发工程师角色，这是对前端最大的一个变革。
当然，serverless 技术让前端回归到传统的 web 层，不代表前端不用掌握服务器知识了，掌握操作系统内核及网络编程知识仍有助于你编写高性能、高可用的业务应用。
实时 SSR 将成为展示端 UI 的主要开发模式
最早的 web 开发，其实处理 UI 都是以服务器渲染为主，比如 perl、php 等动态网页技术，但是在前端逐渐成为一个工种开始负责了绝大部分 UI 开发，并且技术域逐渐缩小到客户端范围之后，网页静态化以及客户端的渲染逐渐成为主流。
但是这种模式对用户体验肯定是有问题的，导致了较多的白屏时间，而由于新的前端库如 react 和 vue 在 vdom 这层的抽象，服务器渲染的技术成本更低，因此 SSR 在最近几年，又逐步开始流行。
但是 SSR 的难点恰恰是前面说的，服务器端人才的匮乏，虽然 nodejs 和 vdom 的普及提升了 SSR 的实施效率，但由于服务器知识的缺乏，通常只有少部分具备综合知识的前端会深入的实践这一领域。
serverless 技术的普及将把这个问题消除掉，借助于 serverless 技术，前端可以快速搭建一个 ssr 的场景，在服务器取数，在服务器渲染，直出 html 给到客户端，而不用关心这个渲染服务能否扛得住流量，会不会挂掉，这些事情云设施供应商会去解决。
在前面说过，react 有一个核心理念就是把 UI 看成函数，如果说一个页面是多个组件组成的，那一个组件是函数，我们可以把一个页面看成是多个函数的组合，不同函数的组合，组合成不同的导购场景，如果把一个函数看成一个微服务，一个场景就是微服务的聚合，这恰恰是 faas 的理念。
通过 serverless 低成本地实时 ssr，可以让客户体验更好，借助算法和大数据，还可以快速实现 UI 的千人 n 面，构建真正的导购大脑。
基于场景的云开发（web ide）将成为主流开发模式
在提到 serverless 技术的时候，有一个关联的领域不得不提，那就是 web ide，很多互联网大型企业把一个 web ide 当成了云的基础设施并且大力投资，这是为何？个人认为有两个原因。
第一个是因为 serverless 目前在业界使用以垂直场景为主，他们有一个共同点，就是代码足够标准、规范，场景较为垂直，代码复杂度不是很大，而且借助 web ide 可以快速地与云平台结合，做到一键发布，因此这种场景，是比较适合轻量的在线编码到部署全链路打通的。
另一个原因是，目前所有的云设施解决的是业务运行问题，但是软件开发有一个非常大但是大部分人可能会忽略的痛点，那就是环境问题，相信很多人都有那种 clone 别人的项目但是废了九牛二虎之力都无法启动的问题，因为要装各种环境啊？另外就是和别人联调的时候，是不是因为各种环境部署缺失的问题，联调效率很低？
借助容器如 docker 等技术，软件的运行及调试环境，可以快速地移植给别人复用，而目前基于 js 的代码编辑器已经非常强大，vscode editor 就是基于 js 编写并且沉淀出一个库 Monaco Editor，因此可以说，大部分认为 web ide 可能在语法提示、智能感知上比不上本地 ide 的想法是过时了。
同时 web ide 可以快速地与平台集成，深入定制，打通业务平台，一键部署，极大地提升研发效率。
web ide 还能解决跨地办公的问题，因为解决了环境准备这一老大难问题，你可以在家里，在公司，甚至在火车上，快速编写并交付代码。
因此未来的 paas 平台，都将关联一个深度定制的 web ide，需要编写业务逻辑时，一个连接跳转到 web ide 即可编码，完全无需关心本地环境问题，做到真正的 envless。比如你要开发一个 TMS 模块，那么点击”新建“，跳到了 web ide，代码会帮你初始化好，点击运行，会在云端启动服务器运行该组件，编写好之后，一键即可发布到 TMS。
对于各种 faas、api gateway 系统以及其他云服务，都会一样，web ide 将成为企业云化的基础设施。尽管阿里云目前还未发布媲美 cloud9 以及 coding.net 的 web ide，但是很欣喜地看到集团内部已经涌现出一些优秀的产品，如 aone 的 ide，以及数据平台的 app studio，其体验已经接近业界顶级水准。
结语
在云计算领域，serverless 将会掀起一场革命，即使看起来与这一领域关联不大的前端，也会经受即 ajax、nodejs 以及 react 之后的又一重大变革，你做好应对了吗？
本文作者：伐薪阅读原文
本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。