前端技术规划与战略:2022

Posted Phodal

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了前端技术规划与战略:2022相关的知识,希望对你有一定的参考价值。

最近几年,因为前端没啥有意思的东西好玩的,主要精力就在工作相关的后端架构咨询和设计上。只是,刚好最近在编写知识管理元框架 Quake ,应用了一些算是比较新的架构思想,特别好玩。所以,这篇文章结合一些公司的前端架构需求,社区上的一些趋势,以及自己的探索编写出来的。

回顾 2021 规划

开始之前,先回回顾一下我在年初写的《前端规划:我的 2021 前端技术战略》,总体上有四个关键要素:

  • 前端架构治理。主要的点是:大型前端应用、规范之旅。

  • 微前端“普及”。主要的点是:微前端框架成熟、

  • 低代码平台的返璞。主要的点是:重塑用户体验、构建开发者体验。

  • 超越前端。主要的点是:Serverless 一体化、重回跨语言前端(如 Rust 等)。

总体上来看,基本上和今年的趋势大差不差了(明明还是差很多的)。所以,如果让我去规划 2022 的话,它可能是这样的。

1. 元宇宙的前端:复兴的前端 3D 世界。

6 年前,我在玩 VR 探索前端可能性的时候,写了一系列的相关文章,比如那篇《Oculus + Node.js + Three.js 打造VR世界》,还有《javascript 在 VR 世界的应用》,总体上,我并不看好普通的前端开发往 VR 世界扩展,它多数是一些图形学相关的知识,需要上手成本会略高一点。

不过,如果一定要的话,可以参考一下我上个月写的《从 Codecity 到元宇宙:元宇宙的软件形态会怎样的?》。只是从某各意义上来说,元宇宙和狭义上的 Web 前端没有多大的关系,除了技术,我们还需要这么一些知识:

  1. 构建 3D 世界的能力,如结合 Three.js 来进行与 VR 的交互。

  2. 将物体从物理世界复刻虚拟世界。即数据孪生。

  3. 从平面软件到物体建模。

  4. 接入虚拟化与沉浸式。

所以,如果想做计划储备那就需要:游戏编程、数字孪生、交互设计、协作模式。总体来说,关系不大,它可以构建一个快速的 MVP。

除了对于元宇宙本身来说,企业对于虚拟形象的热门化,也会带动前端在 3D 世界的发展。

2. 无组件架构:新的可复用模式

虽然,我玩微前端玩得很早,一直觉得微前端(MicroFrontend)这名字不好,只是也懒得去纠结。与现有的遗留系统迁移使用的微前端模式相比,我更看好诸如于 ComponentLess 这样的组件模式,有点类似于 Serverless 之于 NanoService。使用更细粒度的 Web Component 组件,可以构建出更小的应用,易于替换与解耦设计。

回到案例上, 在构建和设计 Quake 应用的时候,我们就是这么玩的:

  • Web Component 作为基础。使用了基于 Web Component 作为应用的基础,在这个基础上套娃(wrapper)了 React 框架的组件、Vue 框架的组件、Angular 框架的组件……。

  • 组件级别的封装。我可以用 React 中的某个框架,可以用 Angular 中的某个框架,只需要封装为 Web Component 即可。

  • 无限套娃模式。可以在 A 组件调用 B 组件,B 组件还可以调用 A,然后无限死循环了。

  • 随意可抛弃式。

所以,就孕育出了无组件的定义:

无组件(Componentless)架构是一种架构模式,它是指大量依赖于三方组件(运行时依赖的组件而非编译时依赖的组件,即编译即服务)或暂存容器中运行的自定义代码的前端应用。应用的三方组件如同三方 API 服务一样,可各自独立发布、独立部署,应用无需重新编译、构建和部署。

3. 低代码及其细化策略

从模式上来说,在低代码社区里,低代码平台已经初步分为(可以是阶段,也可以是方向):

  • nocode 无代码:不需要写代码就能做出一个应用。

  • lowcode 低代码:仅需写少量代码就可以做出一个应用。

  • procode 专业代码:应用所有的代码都需要开发人员编写。

对于三种不同的方式,成熟的低代码都有自己的方案。不同公司有不同的策略:在一个平台上支撑三种不同的方式,又或者是在三个平台上支撑三中不同的方式,只是会复用三种不同的基础设施。这些并不重要,重要的是在实现会发现:多数的低代码平台太复杂了,还需要进一步地拆分。

4. 开发者们的体验

今年与越来越多的小伙伴们交流起了开发者体验,于是开源了电子书《开发者体验:探索与重塑》(https://dx.phodal.com/)。从趋势来说,在开源继续热火朝天的 2022 年来说,开发者体验应该会成为人们研究该领域的一个新趋势。原先我们假定的是:开发团队应该关注于开发者体验。然而,从国内的实践情况来看,所有与这个平台、工具、SDK 等相关的利益相关者们,都应该关注于开发者体验。尤其是,相关的最高管理者,他们决定了相关项目的 KPI/OKR。

无论如何,在设计 KPI 的时候,记得:从协同价值出发、以过程改进为核心,引入适当的不可量化指标。

不过,在写 2021 年规划的时候,我也同样预测了这个趋势。所以,我并不确定他会不会如预期一样。只是呢,在未来的几年里,它是一种不可避免的趋势。

5. 更好的遗留系统迁移

对于大部分公司而言,人们对于前端遗留系统的预期是:不花费大量的时间和精力,只需要它能 run 起来,在未来几年后一起重写(这个事可能不会发生)。所以,在 2021 年里,我尝试去扩展遗留系统迁移的方式。

在 IE 逐渐被淘汰之后,在前端遗留系统的迁移上,我们会有更多的选择,诸如于采用下一代 Web 组件化 Web Components。因此,我们可以采用诸如于领域元组件的方式 —— 它是一个包含特定领域组件(业务场景)的集合。其内部包含了一系列的组件,依赖于输入的领域元数据或者领域特定语言,构建出适用于特定领域的组件。

当然了,原先的微前端架构、花式构建(组件式构建、拆分式构建)依旧是试用的,只是现在有了更多的方法了。

6. 有限的改进前端工具

从 2021 年的趋势来看,已经有越来越多的前端工具,使用 Rust 和 Golang 等 “更快” 的语言编写。所以,这个趋势依旧会在 2022 年继续。毕竟,凡是用 JavaScript 写的,都可能用 Rust 重写一遍。

只是从个人的体验来说,这种改进方式是有限的,前端应用的构建慢多数是因为前端项目代码量大导致的。所以,除了改进前端工具之外,还有一种出路是减少代码的编译。

7. 前端元框架

继续上面的话题,作为一个架构师,跳出具体框架和具体技术栈来考虑问题,便会发现好多事件特别好玩。先前的主要源泉来自于 2018 年构思的:《前端下半场:构建跨框架的 UI 库》,以及去年构思的《Yiki:元微前端框架》。

过去,我一直构建一个基于 Web Component 的 UI 库,后来太懒了。所以,我就继续用 Ionic 的组件库,配合上上面提到的 NanoComponent,搭建一个 Web Component 路由,我们就可以构建一个全新的前端架构模式。基于此,还可以构建出一个适用于前端框架的元框架。框架本身是用来解决问题,提供生产力的,但是前端框架太多就是个问题。

这个有待于在 2022 年里,再想想怎么搞。

8. 探索前端 + AI 的方向

市面上当前流行的 Design to Code,Product to Code,个人觉得是把牛刀用到了吃鸡上:说不上是有意义的创新。说是在降低工作量,但是可能投入远比这多的工作量 —— 远不如 DSL 来得靠谱 + 可迁移。

我一直在思考有没有更创建的前端(边缘侧) AI 方向,但是没有想到。我相信聪明的社区会有更多的答案。

9. DSL as Core

最后一点,就是过去我一直在玩的东西,DSL as Core。回到这个思想来看的话,我觉得什么设计转代码是不合理的,KPI 思想下的产物。理想的模式,应该是 DSL 生成设计 + DSL 生成代码,类似于 unflow 的思想。这样一来,我们就可以无更顺畅的将业务需求转为设计,并实现它的自动化 所以,在 Quake 中是这么玩的,通过 DSL:

---------------------------------------------------------------
| Calendar(flow("show_calendar"), 12x) |
---------------------------------------------------------------
| Network(<graph-network>, 4x) | Timeline(flow("show_timeline"), 8x) |
---------------------------------------------------------------

就可以生成以下的页面:

当然了,上面的 flow 是来自于 DSL,类似于: from('todo','blog').to(<quake-calendar>).filter('created_date > 2021.01.01 AND created_date < 2021.12.31')会自动生成对应的 JavaScript 代码,又或者是任意的后端代码。它可以从数据库中读取 todo 和 blog,然后渲染到 <quake-calendar> 组件中。

随后,只需要为这些 DSL 创建一个配置页面,就可以实现低代码或者无代码。这种模式并不适合于常规的业务开发, 但是非常的好玩:我需要有 CRUD API,还有组件,我就能提供无限的可能性。

10. 构建组合式架构

简单来说,就是提供一个机制来快速组装应用,无论是微前端还是 Componentless 都是相同的目的。这也是我最近正在探索的东西,详细的内容可以年后用一篇文章来探索。

其它

和 2020、2021 年相比,相信 2022 年会出现更多好玩的前端技术。

以上是关于前端技术规划与战略:2022的主要内容,如果未能解决你的问题,请参考以下文章

信息技术开拓视野——记IT战略规划与企业架构培训课程

2022 年前端趋势总结与 2023 前端规划

2022 年前端趋势总结与 2023 前端规划

Scrum 3.1 多鱼点餐系统开发进度(第三阶段项目构思与任务规划)

[课程设计]Scrum 3.1 多鱼点餐系统开发进度(第三阶段项目构思与任务规划)

英特尔2022年投资者大会:公布技术路线图及重要节点