*作者｜狼叔* > 本文是 “2021 年度技术盘点” 系列文章之一，主要介绍大前端领域在2021年的重要进展。 > > “2021年终技术盘点”是掘金推出的重磅企划，涵盖Serverless、Service Mesh、大前端、数据库、人工智能、低代码、边缘计算等众多技术领域。看过去，向未来，回顾IT技术在2021年的发展情况，盘点IT技术的重大事件，展望IT技术的未来趋势。同时，我们将开启第15期技术主题征文活动，一起来聊聊[你眼中的2022年技术趋势](https://juejin.cn/post/7049621519219195918 "https://juejin.cn/post/7049621519219195918")吧！ ## 引言远离自嗨型工业垃圾，探索和深化依然是前端年度大方向，当下前端已进入深水区。为了便于大家理解这个观点，下面我们先回顾一下最近几年前端的变化。 - 2013年到2017年，是前端发展的大爆发阶段，以React/Vue/Angular为代表的的新框架体系和生态快速孵化，每个月甚至每周就会有新的轮子出现； - 2018到2021年，前端发展整体趋于稳定，框架特性变少，各种轮子也逐渐变少，几乎很少出现让人眼前一亮的东西。前端在这个阶段开始进入细分领域，比如工程化、数据可视化、文档等垂类需要深耕的领域，在此时再造轮子Roi不高，毕竟脚手架再怎么写也不会比Umi、Cra、Next更强，最多是带一些业务属性； - 2021之后，前端开始进入从标准化向成熟探索的初期阶段，前端各种操作已经开始规范化，面向大规模编程、制定标准，这都意味着这个行业的成熟度在逐渐变高。ES规范、搭建表单规范、B端三大件Schema化、Web框架标准化等等，从造轮子到标准化，前端已经迈出了很大一步。为什么又说它是处于初期阶段呢？主要原因是现阶段前端还在进行很多尝试探索，比如midwya-hooks将前端的函数与Node.js结合、制定标准写法，比如next.js尝试用Rust来开发，又比如WebAssembly会不会替换docker......这些未知探索都说明前端仍然处于一个让人充满憧憬的时代。 2020年和2021年，前端领域都有哪些探索实践呢？ ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/049c172d875a4d95b0803701a9ae750d~tplv-k3u1fbpfcp-zoom-1.image) 前端领域的探索方向主要集中在基础方向、跨学科融合、业务创新以及Prd2Code。 - 基础方向：esm和http import，import map等发展，催生了snowpack，vite，webpack5等新基建，同时也为bundless提供了更多养料。当然还有很多标准规范需要制定，比如commonjs和esm之间的CDN服务转化； - 跨学科融合：比较典型的是前端智能化，结合AI和前端技术，为前端提效。这个方向是前端领域的很好探索，但需要突破前端和AI自身的能力。 - 业务创新：比较典型的是智能UI，服务端推荐搜索已经到达了瓶颈期，而端上的UI和人群细分并没有真正做好，例如针对价格敏感的用户，并没有实现UI上优惠价格放大，促进转化。 - PRD2Code：仅在前端开发领域，提效已经做了很多年，但站在产研链路上探索是一个很好的方向。横向不好做，做上下游，还是有机会的。在基建领域，前端也发生了很多变化： - SSR，得益于Serverless做的渲染方案，而Serverless又得益于云原生。 - midway-hooks，将react hooks和node web框架在同构写法上进行融合。 - Rust是未来前端基础设施，比如Next 12引入swc等。在新基建的基础上，开发一个高可用系统的成本越来越低，但需要思考前后端合作模式，对分工进行更进一步的拆分。前端领域的变化很多，唯一可确定的结论是前端进入深水区，自身从标准化向成熟探索过渡，深化垂类和有深度的技术创新。 ## 面向开发者的低代码持续升温面向用户的低代码产品，大家已经见到的很多了。在特定场景，低代码是能够解决问题的，但作用到底有多大呢？目前来看，至少对专业开发者来说，收效不大。前端领域主要关心的3个要点：体验、质量和效率。从效率角度来看，这是前端喜欢做低代码的直接原因。吴多益的《从实现原理看低代码》中讲解了百度在低代码领域的探索，他们对低代码的定义是一种声明式编程，优点是容易上手，支持可视化编辑，容易优化性能，容易移植。对于低代码而言，“搭建”是一个关键词。开发者开发的搭建平台，是低代码早期的产品化平台。想想当年电商大促时候，成千上万的页面，仅靠有限的前端是无法解决的。于是，聪明人就开始抽象，将页面打散变成模块，将模块做成可配置的，一个页面用到的模块能够复用，模块可以拼接生成新的页面，这样绝大部分需求就不需要前端开发了，也就削掉了需求的峰值，对于前端来说就是降本增效。（关于低代码的资料，大家可以阅读这个链接：）搭建在业务域里是复杂的，毕竟搭建是招选搭投中重要的一环。但从技术上说，并不复杂，拖拉拽仅限于模块级别，核心就3个难点： - 1）dnd拖拽模块搞定搭建，比如[Fabric](http://fabricjs.com/)，阿里开源的[Designable](https://github.com/alibaba/designable) - 2）运营可配置的schema，阿里开源了Formly和Form-render。 - 3）模块的加载器和页面渲染机制目前的搭建，还只是前端编写代码的模块生产方式。接下来可视化生成模块，实现真正的低代码生成模块，才是趋势。我非常看好这个方向，也一直在做相应的探索，状态可视化、逻辑可视化、多状态视图解决方案，都是面向开发者的低代码平台。至于低代码是开发者的效率工具，这个是玉伯提的，对此我也是认可的，就相当于低代码被提升到了效率工具的级别。 ### 多状态视图问题如果想解决复杂模块可视化生成，首先要解决的就是多状态视图问题。在一个复杂模块中，状态变化会导致UI变化，如果是单一画布，其实无法表达这种情况。那么，如果将每个状态都对应一个图层，编排出状态图，在单一画布上解决UI生成的问题，是不是就可以解决了？ ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3d597fb761864b7290e2d5d069cfb4e7~tplv-k3u1fbpfcp-zoom-1.image) 举个例子，只有Logined和UnLogin二个状态。，点击按钮可以互相切换状态，代码如下。 ``` import React from 'react'; import { Stateview, Layer, setViewState } from 'stateview'; /** * 最简单的Demo：2个状态切换 */ export default () => { function unlogin() { setViewState('unlogin') } function logined() { setViewState('logined') } return (

Logined,

UnLogin,

); } ``` 通过这种方式，可以很好地解决多状态视图问题，当然stateview还只是这个领域的一个简单探索，相信接下来会更多这方面的探索。当每个状态视图都可以描述，会让d2c或画布搭建变得极为简单。 ### 逻辑复用问题 F2C即Flow 2 Code，即通过流程可视化编排来产生代码。这不是一个新的概念，但确确实实是跨界整合的一个经典案例。在做前端智能化的过程中，我们发现，在UI侧有d2c这样的设计稿转代码工具，应对UI样式变化是足够的。但在逻辑领域，真正能解决问题的又面向开发者的少之又少，iMove算这个方向的探索之一。 iMove是一个面向前端开发者的逻辑编排工具，核心解决的是复杂逻辑复用的问题。iMove由2部分组成：画布和iMove-sdk。通过本地运行一个http服务来运行画布，在画布上完成代码编写和节点编排，最终将流程导出dsl，放到项目中，通过iMove-sdk调用执行。解决的场景如下图所示。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8efb346161a44dee8518009bb226a47d~tplv-k3u1fbpfcp-zoom-1.image) 具体用法如下。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a6d69b19d707434eb9a22c5ca0c7ae75~tplv-k3u1fbpfcp-zoom-1.image) 上图要点说明如下。 - 在画布上，通过拖拉拽完成dag有向图的编排，然后双节点进行代码编写。 - 编写完成后，将代码下载到本地，通过iMove-sdk进行调用。在能力固定，组装不确定的大多数情况下，iMove是极其好用的，它也是低代码的必要一环。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8f8b639baf7b4c0eac31a3028677cdd0~tplv-k3u1fbpfcp-zoom-1.image) 当然，它的问题也很明显，仅仅是能用，但不好用。本身iMove是开源的，所有人都可以用，希望大家在使用时能够保留版权和感谢，当然最好是能够一起贡献。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2228bd61e08b4fce9e453e800894fbba~tplv-k3u1fbpfcp-zoom-1.image) iMove最大的问题是只解决了逻辑组装问题，最终也要是要为低代码生成努力的。逻辑编排只是低代码里的一环，对于复杂逻辑如何可视化编排，还有很大的探索空间。 ### 状态与交互之间的关系状态机可视化xstate做的很棒。我为什么了解xstate，因为XState作者给iMove点了个star ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7aa1317bbc984d8eb78f38a767774c64~tplv-k3u1fbpfcp-zoom-1.image) 看看人家这代码，写的规矩 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4cd840e17c204a6f9b97457c87091a34~tplv-k3u1fbpfcp-zoom-1.image) 通过上图演示，可以说在状态、行为、UI上，它都能够很好的表达了。那么，它的野心是什么？单一状态可视化是不具备很大价值的，结合状态、UI、行为，走入到低代码领域可能才是出路。 xstate和iMove都只解决了一部分问题。惺惺相惜是正常的。 ### 未来展望通过上面的讲解，相信大家已经对面向开发者的低代码平台有了一定了解。画布开源的很多，比如fabric和designable，逻辑编排有iMove（上面讲了），状态可视化有xstate（上面讲了），今天看面向开发者的低代码平台的组成元素基本都有了。目前看还缺少一个整合的比较好的低代码实践。相信2022年，此处还会有进一步发展。 ## Node.js 2021年开发者报告解读很多人觉得Node.js没有往年那么火了，事实上不是这样的，Node.js社区健康稳步的发展中，主要是从性能好向好用转变，在易用性和好用性上有很大提升，从Node.js源码更新的内容看，大抵如此。Node.js Diagnostics Working Group是近二年Node.js社区的重点工作组，Node.js 14版本之后的大部分功能特性都是这个工作组推动的。早在2015年，有2个跟踪工作组tracing WG 和事后分析工作组 postmortem WG，在2017年合并到Diagnostics WG。核心产出是async_hooks, profiling, tracing, dump debug, report等，都是在易用性和好用性上做提升。让每个Node.js开发者更低门槛的提升Node.js应用的开发体验。社区方面，框架已经没有多少空间，以特性取胜的框架，应该不会很多。像fastify这种，修改Node.js机制，在性能领域深耕的框架，目前看是比较有作为的。pnpm是有创新的，但代码是有点可读性不太好。我更加喜欢rushstack对menorepo的改进，大规模编程范式还需要探索。除了去年提的midway-hooks，easy-monitor，看起来remix和morden算新，但还没有超出之前的范畴。这个领域太卷了，我更看好的是bundless。下面结合《Node.js开发者2021报告》内容，我们详细解读一下Node.js 2021年的情况。这份解读是根据冰森&狼叔直播内容整理的，要点如下。 ### 1）开发框架变化较大，造轮子变少，TS变多，使用企业级框架变多去年express占比还非常高，今年企业级框架变多，尤其是大而全的框架更受欢迎。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7d9d328f8e0447148eb80f9570fd0180~tplv-k3u1fbpfcp-zoom-1.image) Egg在国内普及率很高，而Midway和Nest增长较快，其实和TS普及有一定关系。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7667760157d4403193945ac835e21c06~tplv-k3u1fbpfcp-zoom-1.image) ### 2）版本更新变化较大，从Node 12升级到Node 14，升级比较积极去年Node.js主要是使用Node 12，2021年Node 14占比将近一半，更新还是较快的。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e019ccb137964fb6ad5551276361279e~tplv-k3u1fbpfcp-zoom-1.image) ### 3）吐槽变多，意味着用的人变多，趋于成熟 C++之父Bjarne Stroustrup说过：世界上只有两种编程语言,一种是整天被人骂的,还有一种是没人用的。大家对Node.js吐槽变多，实际上是在应用场景上使用较多，不再是针对于某些特性而进行吹捧。回归理性，在真实应用场景上，分布广泛，核心围绕API和BFF层，CLI&工具。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dd834cb911b040d8958607068e06f791~tplv-k3u1fbpfcp-zoom-1.image) ### 4）出圈：年龄分布较去年比变大，使用工种也变得比较丰富。除了应用场景上，分布广泛外，非前端意外的开发者相关角色也有很大比例的提升，比如架构师，技术总监，项目经理等都一定程度上使用Node.js。可以说Node.js走出了前端圈，面向更大群体提供服务。另外受访者的年龄分布也变大了，这和出圈是有直接关系的。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/814c6b97915944b6a78ba530d174dc77~tplv-k3u1fbpfcp-zoom-1.image) ### 5）使用困惑：性能优化，内存泄漏以及npm依赖以往对Node.js困惑最多的是异步流程控制，随着async/await的普及，这个问题已经慢慢在弱化。随着开发者使用Node.js深度增加，对性能优化，内存泄漏更为关注，这也是比较容易理解的。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8bb556a7294248d09ac0e6fd87c1b546~tplv-k3u1fbpfcp-zoom-1.image) ### 6）未来：从业经验越高则越关注性能和 Serverless 关注性能比较容易理解，关注Serverless最主要是的原因是Serverless可以做到低运维甚至是0运维。运维作为Node.js开发者必备技能，Serverless的出现使得很多非专业Node.js也能轻松搞定Node.js各种服务端场景。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/46dc373981b74abd86b47db158b99ddb~tplv-k3u1fbpfcp-zoom-1.image) ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8adf1df328a54d74a62996b4257606fd~tplv-k3u1fbpfcp-zoom-1.image) 参见《年终盘点Serverless：工业、学术、社区遍地开花，国内厂商迅速卡位》 ## 其他 ### 反模式，前端3.0和FFB 大厂前端开始反思了。让前端和后端职责更明确。 - 阿里的前端3.0:是希望前端和后端统一变为应用工程师，即前端能够通过Serverless解决基建运维问题，让前端开发者进一步了解业务，编写业务结构，而非简单的bff中的api proxy或SSR。 - 蚂蚁是想把bff变成FFB，即frontend for backend，这也是一个有趣的想法，让前端更纯粹。以上2点，都是针对智能化做的尝试。另外前后端的边界上，也可以反思一下，前端本来就是渲染模板和字段绑定，现在反而越进步变得越复杂，夹杂了越来越多的胶水逻辑。还原事物的本质， ### AI短期悲观，长期乐观输入输出确定，中间过程自动化，是AI 最擅长干的事。输入输出严格确定，不是自由人喜欢干的事。矛盾就是这个。泛化性是一直研究的核心方向。但，**前端** **范式未定，AI短期产研链路上，不会有大突破。所以我的结论是AI短期悲观，长期乐观。** 再看D2C，它是有一定作用的，但需要划清楚边界。比如CodeFun的效率提升可以达到25%，完成很多UI工作，但目前仅限于设计稿转代码，生成的代码只做UI绑定。当前D2C的最佳实践比较好，还有很大的成长空间。目前循环，列表类解决最好的，大概只有CodeFun了。摸鱼神器。当然CodeFun也有很大成长空间，想用好d2c，当前的最佳实践还是有点少的。整体而言，我的看法是： 1. 端智能在当下还有很多应用场景； 2. D2C天花板明显，目前解决的仅仅是模板以内UI样式生成的问题； 3. 智能UI和智能无关，是上帝视角的业务创新； 4. 站在产研链路上做创新，首先要解决前端范式结构化问题，未来路还很远；按照某位算法同学的说法，AI差不多每7年会有颠覆性的东西出来，所以探索模式，等待变化就好了。 ### Web 3是讲不清楚的未来方向实话说，我在关注并学习相关内容，目前还不熟悉，不表达看法，持续关注中。我的感觉，下一轮技术变革期到了。具体是啥，还不清楚，别自闭，开发心态多去接触吧。 ## 总结大前端整体健康发展中，虽然增速变缓，但多学科融合、上下游提效，以及深水区深耕，低代码等领域还是飞驰值得期待的。 - 前端自身从标准化向成熟探索过渡，深化垂类和有深度的技术创新，当下前端已进入深水区。 - 面向开发者的低代码持续升温，多状态视图、逻辑编排和状态可视化都是值得关注的方向。 - Node.js社区健康稳步的发展中，将从性能好向好用的方向转变，在易用性和好用性上有很大提升。在新基建之上，开发一个高可用系统的成本越来越低，需要思考前后端合作模式，更一进步对分工进行拆分。有人说这是前端3.0，也有人说这可能FFB（frontend for backbene），究竟是啥，日渐清晰，让我们拭目以待吧。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/61dc027077eb42b3a1df7eb73fa70b11~tplv-k3u1fbpfcp-zoom-1.image) **作者简介：** 狼叔：网名 i5ting，阿里巴巴前端技术专家，Node.js 技术布道者，Node 全栈公众号运营者，曾就职于去哪儿、新浪、网秦，做过前端、后端、数据分析，是一名全栈技术的实践者。已出版《狼书(卷 1) ：更了不起的 Node.js》《狼书(卷 2) ：Node.js Web 应用开发》，即将出版《狼书(卷 3) Node.js 高级技术》。 **相关阅读：** [年终盘点Serverless：工业、学术、社区遍地开花，国内厂商迅速卡位](https://juejin.cn/news/7049187137685553160 "https://juejin.cn/news/7049187137685553160") [年终盘点Kubernetes生态：大版本“内卷”，安全性值得重视](https://juejin.cn/news/7049688078385938463)

Logined, go to UnLogin

UnLogin, go to Logined

Logined,

UnLogin,