公众号｜沐洒（ID：musama2018）      关注我，带你学点有用的

未来的剧本早已写好，我们只不过恰好演到中场，未来发生的一切都有迹可循。

书接上回。

在《上篇》文末我们留了一个小小的悬念：曾经叱咤风云的前端「切图仔」们，在遭遇行业洗牌后的命运如何？

这就不得不提到两个风靡全国的概念：「大前端」和「全栈」。​

1. 大前端 Broad Front-End

大前端（Broad Front-End）：通常指代一个涵盖了多个前端技术和开发领域的广泛概念，包括 Web 前端、移动端、桌面端等。

其实「大前端」的概念由来已久，早在Web2.0初期就已经有了，当时「H5」刚兴起，IOS开发还停留在Object-C阶段（Swift尚未到来），小程序尚在襁褓之中，「大前端」就已经悄悄在大厂的前端圈子里缓缓传开了。

当时的「大前端」，依托于JSBridge等技术，把内嵌在客户端内的H5页面做得尽可能接近原生效果，从而更进一步的扩张前端从业者的职能边界。

而后来呢，RN（React Native）问世，Flutter紧随其后，小程序也踩着红毯闪亮登场。

在各种优秀的跨终端框架的加持下，前端工程师们虎口夺食，硬生生的干掉了无数的传统客户端开发者（这里要向客户端同学说声对不起，害你们失业了），即便是没有被干掉的幸存者，也被各路「前端总监」们收入麾下，正式成为「大前端」的光荣成员。

这一仗，前端又赢了（在《上篇》中已经赢了一次），深入腹地，从客户端工程师手中再夺一城，进一步开疆扩土，霸占贤妻……啊呸！不是这个意思。

从这个意义上讲，前端工程师真的是当之无愧的「卷王」！永远在想方设法的拓宽边界，甚至跨界处理问题。

这也是为什么前端职位是几十年如一日的长存着，经久不衰的缘故。

当你将高薪归因于自己努力的时候，其实你更应该意识到，是那一群不断升级前端技术的「卷逼」大佬，在默默的替大家负重前行。

是他们，基于古早的「前端三件套」（HTML/CSS/JS），不断翻新出各式各样的语言，库，框架，脚手架，工具等等等等，帮你扫清技术障碍，为你赢得生存时间，赢得自我价值兑现的机会。

而凡事有因必有果，有好必有坏。

前端成为了互联网行业各大角色里，技术升级迭代最快最多的角色，虽然赢得了商机，却也背负了一个行业骂名：造轮子最多的工种。

这话一点没错。放眼全行业，找不到第二个工种能像前端一样活跃，嗑药一样疯狂的造着各种五彩缤纷的轮子，给后来入行的新人们，留下了铺天盖地的「八股」知识图谱，也给他们造成了巨大的选择困难：

• Vue和React我到底该学哪个？
• JS和TS到底谁更好？
• Less和Sass傻傻分不清？
• RN和Flutter谁才是正道？
• More ……

更不用提一堆单看名字都会搞混的Redux，RxJs，Nuxt，Next，Nest，Node，Deno……（新人表示：我选择狗带 T_T）

2. 全栈 Full-Stack

全栈工程师（Full Stack Engineer）：是指具备多种技能，能够在软件开发的各个层面（前端、后端、数据库等）进行工作的工程师。他们通常对各种编程语言、框架和技术都有一定的了解和实践经验。全栈工程师可以独立完成从项目设计、编码、测试到部署的整个开发过程。

说完大前端，我们再来聊聊切图仔的第二个出路：「全栈」。

说到全栈，便不能不提全栈第一功臣：Node.js。2009年诞生之后，它并没有第一时间获得青睐，行业内多多少少都对这门语言持有怀疑态度，别说老板们，就连程序员自己都没有多少信心把Node作为服务端语言，去生产环境承载对外业务的压力。

这种偏见常年游荡在行业内，Node也只能委曲求全的用于本地开发构建，代码调试，各种Cli的制作等轻量场景，直到出现了新的契机……

MongDB，Express等「前端-全栈最佳实践」方案的诞生，确实给Node生态带来了生机，和巨大的潜力，但这些预期范围内，理所应当的生态发展，并不足以成为一个让Node出圈的契机。

在我看来，反而是一个看似关系不大的概念起了关键性作用：微服务。

这个词熟吧，前几年在服务端火得一塌糊涂，相较于「单体架构」，以DDD（Domain Driven Design，领域驱动设计）作为指导思想的「微服务架构」使得业务逻辑得以真正意义上的解耦，进而极大的提升了服务的整体健壮性和可扩展性，也使Devops得以顺利落地。

不过话说回来，与其说是微服务成全了Devops，倒不如说，是Devops成就了微服务。这部分我们先不展开，回到前端全栈话题。

对于我说微服务给Node带来了出圈的契机，你是不是觉得有点奇怪？一个是编程语言，一个是架构思想，这八竿子打不着的关系，怎么就扯到一起了呢？

这世间的事就是这么神奇，亚马逊的蝴蝶扇一扇翅膀，就会给太平洋沿岸带来一场飓风。

「微服务」的商业化落地，对现存业务架构进行了全面的洗牌，眼见着一个个「巨石应用」被拆散又重组，确实给产品迭代效率带来了质的飞跃，但同时也引入了新的问题：服务太多，对接成本变高！

显而易见，微服务架构下，请求从前端发出后，会根据不同的功能，流向不同的后端服务，你们有没有发现一个问题？后端的微服务架构，实际上是解耦了自己，而把聚合复杂度丢给了前端……造孽啊！

且不说不同的后端服务地址（IP:Port）不同，连返回体结构也会不同呀，不同的开发者素质不一，权责处理得也不尽相同，有的后端让你很省心，权限，身份等事务一应包揽，但有的后端啥都让你自己去处理。诸如此类，烦心事不少。

再者，以前单体应用时期，前端只需要处理“请求”本身的业务语义，比如某个接口“查询书籍列表”，前端就只需要把对应的limit（每页条数）和skip（页码）信息告知后端服务即可，剩下的前置逻辑（如用户身份读取，权限过滤，参数校验，限流，缓存等）和后置逻辑（错误处理，响应包裹，日志，监控等），就都不用管了。

而微服务架构下，一切都推倒重来了。服务按领域做划分，开发者也按模块做了分工，大家各扫门前雪，再加上素质良莠不齐，前后端对接成本就指数级上升了。

由于各个后端服务通常是按照业务领域来设计的，各自有自己的权责范围，对于前置/后置逻辑这种「脏逻辑」，就开始踢皮球。

危机危机，有危就有机！

这时候，业界最卷工种——前端，就携带着Node生态顺势介入了！

于是你就会看到，在前端和后端的中间，强势插入了一个「网关层」（Gateway），配合着各种Node框架（Express/Koa/Nest等），把上述各种「脏逻辑」全部吃掉了。

这事儿办的可真漂亮，简直是双方都开心。

后端开心的是，有人帮我们吃掉脏逻辑啦，我们只需要专心处理好具体功能逻辑即可。

而前端开心的是，老子又凭实力夺下一座城池了哈哈哈哈……

从此以后，Node开始在线上服务崭露头角，再也不是那个只能用来写点Cli（Command Line Interface，命令行界面）的鸡肋东西了。前端开发也顺理成章的，陆续发展出全栈工程师的细分工种，一点点，一点点的蚕食着后端开发的工作。

你没看错，在「卷王」的蚕食下，一小部份简单的逻辑（比如读写分离之后的「读」逻辑）也逐渐被Node吃下。照这个节奏，迟早有一天整个行业都要被前端给“绿”掉（这里采用绿色纯粹是因为Node是绿的，别想歪了）。

至此，我算是把切图仔的两条升级之路讲清楚了吧？你可能要问了，难道就没有尚未升级的UI工程师吗？

其实也是有的，只是不多而已。

这类“前朝余党”，一部分被大公司淘汰了，跑去二三线城市搞搞外包勉强度日，还有另一部份依然战斗力十足的，他们既不喜欢去卷客户端（大前端），也不喜欢去卷后端（全栈），他们坚持住了前端的初心：「努力研究交互设计，提升用户体验」，去卷上游的设计师去了。

然后你就看到了一个个前端大佬升任「某某设计中心」总监，带领一众设计师和UI工程师，继续在UI/UX的修行之路上，渐行渐远。

这便是前端开发的现状，卷天卷地卷空气，终究是不负如来不负卿，在恶劣的生存环境下，硬生生杀出了一条条血路。

这里稍微提一嘴，本文所述的两条出路，是从工作职责出发划分的，实际上，如果从业务领域出发，前端就会分叉出非常庞杂的细分领域工种，正如我之前文章所说，参考《大厂前端日常窥探「贰」：前端大佬们都在干啥？》。

OK，前端的过去和现在，我给大家讲清楚了吧？没看明白的可以再看亿遍，每一个细节都不要放过，因为接下来，我们要进入真正的深度思考了！如果你对这些背景了解不透，就会无法理解我在《下篇》里的推导逻辑

在《下篇》中，我将带大家一起来看看，「宇宙第一卷王 ：前端」的未来大概率会往哪个方向继续卷下去。

欢迎追更这个《深度漫谈》系列，由于篇幅较长，我将全文划分为“上中下”三篇分开发布，分别聊了前端的过去，现在和未来。

预告一下，在《下篇》中，我将带你使用「第一性原理」，从事务本质出发，去探索前端工程师的未来。

敬请期待。

技术交流群   

我建了个前端技术交流群，整体氛围非常好，每天大家都会在群里真诚的交流技术问题，从前端到全栈，从尚未毕业的小年轻，到不惑之年的老大哥，大家都在拼命的汲取知识!

有想要交流&学习前端知识的老少朋友，欢迎加入我们！

进群方式：

关注公众号 “沐洒”，回复“技术群”，获取最新群聊二维码。

如果还想继续看我写的东西，就关注我吧（记得加星标🌟哦），顺便给个赞👍或点一下 在看  ，你的支持是我继续写下去的动力。

公众号｜沐洒（ID：musama2018）     关注我，带你学点有用的