年终盘点大前端:前端进入深水区,面向开发者的低代码持续升温

掘金酱 行业动态 8天前 阅读 2317

作者 | 狼叔

本文是 “2021 年度技术盘点” 系列文章之一,主要介绍大前端领域在2021年的重要进展。

“2021年终技术盘点”是掘金推出的重磅企划,涵盖Serverless、Service Mesh、大前端、数据库、人工智能、低代码、边缘计算等众多技术领域。看过去,向未来,回顾IT技术在2021年的发展情况,盘点IT技术的重大事件,展望IT技术的未来趋势。同时,我们将开启第15期技术主题征文活动,一起来聊聊你眼中的2022年技术趋势吧!

引言

远离自嗨型工业垃圾,探索和深化依然是前端年度大方向,当下前端已进入深水区。为了便于大家理解这个观点,下面我们先回顾一下最近几年前端的变化。

  • 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年,前端领域都有哪些探索实践呢?

前端领域的探索方向主要集中在基础方向、跨学科融合、业务创新以及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个要点:体验、质量和效率。从效率角度来看,这是前端喜欢做低代码的直接原因。吴多益的《从实现原理看低代码》中讲解了百度在低代码领域的探索,他们对低代码的定义是一种声明式编程,优点是容易上手,支持可视化编辑,容易优化性能,容易移植。

对于低代码而言,“搭建”是一个关键词。开发者开发的搭建平台,是低代码早期的产品化平台。想想当年电商大促时候,成千上万的页面,仅靠有限的前端是无法解决的。于是,聪明人就开始抽象,将页面打散变成模块,将模块做成可配置的,一个页面用到的模块能够复用,模块可以拼接生成新的页面,这样绝大部分需求就不需要前端开发了,也就削掉了需求的峰值,对于前端来说就是降本增效。(关于低代码的资料,大家可以阅读这个链接:github.com/taowen/awes…

搭建在业务域里是复杂的,毕竟搭建是招选搭投中重要的一环。但从技术上说,并不复杂,拖拉拽仅限于模块级别,核心就3个难点:

  • 2)运营可配置的schema,阿里开源了Formly和Form-render。
  • 3)模块的加载器和页面渲染机制

目前的搭建,还只是前端编写代码的模块生产方式。接下来可视化生成模块,实现真正的低代码生成模块,才是趋势。我非常看好这个方向,也一直在做相应的探索,状态可视化、逻辑可视化、多状态视图解决方案,都是面向开发者的低代码平台。至于低代码是开发者的效率工具,这个是玉伯提的,对此我也是认可的,就相当于低代码被提升到了效率工具的级别。

多状态视图问题

如果想解决复杂模块可视化生成,首先要解决的就是多状态视图问题。在一个复杂模块中,状态变化会导致UI变化,如果是单一画布,其实无法表达这种情况。那么,如果将每个状态都对应一个图层,编排出状态图,在单一画布上解决UI生成的问题,是不是就可以解决了?

举个例子,只有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 (
    <Stateview default='unlogin'>
      <Layer state='logined'>
        <h1>Logined, <button onClick={unlogin}>go to UnLogin</button></h1>
      </Layer>
      <Layer state='unlogin'>
        <h1 >UnLogin, <button onClick={logined}>go to Logined</button></h1>
      </Layer>
    </Stateview>
  );
}
复制代码

通过这种方式,可以很好地解决多状态视图问题,当然stateview还只是这个领域的一个简单探索,相信接下来会更多这方面的探索。当每个状态视图都可以描述,会让d2c或画布搭建变得极为简单。

逻辑复用问题

F2C即Flow 2 Code,即通过流程可视化编排来产生代码。这不是一个新的概念,但确确实实是跨界整合的一个经典案例。在做前端智能化的过程中,我们发现,在UI侧有d2c这样的设计稿转代码工具,应对UI样式变化是足够的。但在逻辑领域,真正能解决问题的又面向开发者的少之又少,iMove算这个方向的探索之一。

iMove是一个面向前端开发者的逻辑编排工具,核心解决的是复杂逻辑复用的问题。iMove由2部分组成:画布和iMove-sdk。通过本地运行一个http服务来运行画布,在画布上完成代码编写和节点编排,最终将流程导出dsl,放到项目中,通过iMove-sdk调用执行。

解决的场景如下图所示。

具体用法如下。

上图要点说明如下。

  • 在画布上,通过拖拉拽完成dag有向图的编排,然后双节点进行代码编写。
  • 编写完成后,将代码下载到本地,通过iMove-sdk进行调用。

在能力固定,组装不确定的大多数情况下,iMove是极其好用的,它也是低代码的必要一环。

当然, 它的问题也很明显,仅仅是能用,但不好用。本身iMove是开源的,所有人都可以用,希望大家在使用时能够保留版权和感谢,当然最好是能够一起贡献。

iMove最大的问题是只解决了逻辑组装问题,最终也要是要为低代码生成努力的。逻辑编排只是低代码里的一环,对于复杂逻辑如何可视化编排,还有很大的探索空间。

状态与交互之间的关系

状态机可视化xstate做的很棒。我为什么了解xstate,因为XState作者给iMove点了个star

看看人家这代码,写的规矩

通过上图演示,可以说在状态、行为、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占比还非常高,今年企业级框架变多,尤其是大而全的框架更受欢迎。

Egg在国内普及率很高,而Midway和Nest增长较快,其实和TS普及有一定关系。

2)版本更新变化较大,从Node 12升级到Node 14,升级比较积极

去年Node.js主要是使用Node 12,2021年Node 14占比将近一半,更新还是较快的。

3)吐槽变多,意味着用的人变多,趋于成熟

C++之父Bjarne Stroustrup说过:世界上只有两种编程语言,一种是整天被人骂的,还有一种是没人用的。

大家对Node.js吐槽变多,实际上是在应用场景上使用较多,不再是针对于某些特性而进行吹捧。回归理性,在真实应用场景上,分布广泛,核心围绕API和BFF层,CLI&工具。

4)出圈:年龄分布较去年比变大,使用工种也变得比较丰富。

除了应用场景上,分布广泛外,非前端意外的开发者相关角色也有很大比例的提升,比如架构师,技术总监,项目经理等都一定程度上使用Node.js。可以说Node.js走出了前端圈,面向更大群体提供服务。另外受访者的年龄分布也变大了,这和出圈是有直接关系的。

5)使用困惑:性能优化,内存泄漏以及npm依赖

以往对Node.js困惑最多的是异步流程控制,随着async/await的普及,这个问题已经慢慢在弱化。随着开发者使用Node.js深度增加,对性能优化,内存泄漏更为关注,这也是比较容易理解的。

6)未来:从业经验越高则越关注性能和 Serverless

关注性能比较容易理解,关注Serverless最主要是的原因是Serverless可以做到低运维甚至是0运维。运维作为Node.js开发者必备技能,Serverless的出现使得很多非专业Node.js也能轻松搞定Node.js各种服务端场景。

参见《年终盘点Serverless:工业、学术、社区遍地开花,国内厂商迅速卡位》mp.weixin.qq.com/s/6Bl08eG8a…

其他

反模式,前端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. 端智能在当下还有很多应用场景;
  1. D2C天花板明显,目前解决的仅仅是模板以内UI样式生成的问题;
  1. 智能UI和智能无关,是上帝视角的业务创新;
  1. 站在产研链路上做创新,首先要解决前端范式结构化问题,未来路还很远;

按照某位算法同学的说法,AI差不多每7年会有颠覆性的东西出来,所以探索模式,等待变化就好了。

Web 3是讲不清楚的未来方向

实话说,我在关注并学习相关内容,目前还不熟悉,不表达看法,持续关注中。我的感觉,下一轮技术变革期到了。具体是啥,还不清楚,别自闭,开发心态多去接触吧。

总结

大前端整体健康发展中,虽然增速变缓,但多学科融合、上下游提效,以及深水区深耕,低代码等领域还是飞驰值得期待的。

  • 前端自身从标准化向成熟探索过渡,深化垂类和有深度的技术创新,当下前端已进入深水区。
  • 面向开发者的低代码持续升温,多状态视图、逻辑编排和状态可视化都是值得关注的方向。
  • Node.js社区健康稳步的发展中,将从性能好向好用的方向转变,在易用性和好用性上有很大提升。

在新基建之上,开发一个高可用系统的成本越来越低,需要思考前后端合作模式,更一进步对分工进行拆分。有人说这是前端3.0,也有人说这可能FFB(frontend for backbene),究竟是啥,日渐清晰,让我们拭目以待吧。

作者简介:

狼叔:网名 i5ting,阿里巴巴前端技术专家,Node.js 技术布道者,Node 全栈公众号运营者,曾就职于去哪儿、新浪、网秦,做过前端、后端、数据分析,是一名全栈技术的实践者。已出版《狼书(卷 1) :更了不起的 Node.js》《狼书(卷 2) :Node.js Web 应用开发》,即将出版《狼书(卷 3) Node.js 高级技术》。

相关阅读:

年终盘点Serverless:工业、学术、社区遍地开花,国内厂商迅速卡位

年终盘点Kubernetes生态:大版本“内卷”,安全性值得重视

4