前端技术规划与战略：2022
最近几年，因为前端没啥有意思的东西好玩的，主要精力就在工作相关的后端架构咨询和设计上。只是，刚好最近在编写知识管理元框架 Quake ，应用了一些算是比较新的架构思想，特别好玩。所以，这篇文章结合一些公司的前端架构需求，社区上的一些趋势，以及自己的探索编写出来的。
回顾 2021 规划
开始之前，先回回顾一下我在年初写的《前端规划：我的 2021 前端技术战略》，总体上有四个关键要素：
-
前端架构治理。主要的点是：大型前端应用、规范之旅。
-
微前端“普及”。主要的点是：微前端框架成熟、
-
低代码平台的返璞。主要的点是：重塑用户体验、构建开发者体验。
-
超越前端。主要的点是：Serverless 一体化、重回跨语言前端（如 Rust 等）。
总体上来看，基本上和今年的趋势大差不差了（明明还是差很多的）。所以，如果让我去规划 2022 的话，它可能是这样的。
1. 元宇宙的前端：复兴的前端 3D 世界。
6 年前，我在玩 VR 探索前端可能性的时候，写了一系列的相关文章，比如那篇《Oculus + Node.js + Three.js 打造VR世界》，还有《JavaScript 在 VR 世界的应用》，总体上，我并不看好普通的前端开发往 VR 世界扩展，它多数是一些图形学相关的知识，需要上手成本会略高一点。
不过，如果一定要的话，可以参考一下我上个月写的《从 Codecity 到元宇宙：元宇宙的软件形态会怎样的？》。只是从某各意义上来说，元宇宙和狭义上的 Web 前端没有多大的关系，除了技术，我们还需要这么一些知识：
-
构建 3D 世界的能力，如结合 Three.js 来进行与 VR 的交互。
-
将物体从物理世界复刻虚拟世界。即数据孪生。
-
从平面软件到物体建模。
-
接入虚拟化与沉浸式。
所以，如果想做计划储备那就需要：游戏编程、数字孪生、交互设计、协作模式。总体来说，关系不大，它可以构建一个快速的 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(,?4x)?|?Timeline(flow("show_timeline"),?8x)?|
---------------------------------------------------------------
就可以生成以下的页面：
当然了，上面的flow是来自于 DSL，类似于：from('todo','blog').to(会自动生成对应的 JavaScript 代码，又或者是任意的后端代码。它可以从数据库中读取todo和blog，然后渲染到
随后，只需要为这些 DSL 创建一个配置页面，就可以实现低代码或者无代码。这种模式并不适合于常规的业务开发， 但是非常的好玩：我需要有 CRUD API，还有组件，我就能提供无限的可能性。
10. 构建组合式架构
简单来说，就是提供一个机制来快速组装应用，无论是微前端还是 Componentless 都是相同的目的。这也是我最近正在探索的东西，详细的内容可以年后用一篇文章来探索。
其它
和 2020、2021 年相比，相信 2022 年会出现更多好玩的前端技术。