整体来看，从大的趋势上没有太大的变化。这里并不考虑某些特定的技术，而是从总体上（战略）层面来看待问题。所以，就有了这么几个点：

• 前端架构治理。
• 微前端“普及”
• 低代码平台的返璞
• 超越前端

看上去最后一点一直是如此，哈哈。

前端架构治理

前端架构治理是一个颇为复杂的问题，我们限入了一个困境：要做的事情很多，但是无奈 JavaScript 的灵活性困扰了我们每一步。所以，在某些时候，我们所能治理的东西比较有限。常见的一些有：构建优化、组件化、微前端等。

大型前端应用

单个前端应用上了一定的规模，这本身是比较少见的 —— 从比例上来看。但是一旦遇到的时候，就往往需要大量地工作，才能治理好整个前端应用，还需要配合开发一些工具。好在市面上已经有大量的类似工具，也可以编写如 Lemonj 这样的轻量级自动化 CSS 重构工具。

说实话，如果我们管理不好 CSS 中的 color 变量，那么整体的规范性就会成为一个新的问题。

规范之旅

我本不想浪费时间在这个话题上，但是真的很无奈。

兄弟姐妹们，能用 TypeScript 就用 TypeScript，能绑定各种 Lint 就用各种 Lint，能用 Git Hooks + Husky 就加上吧！大型前端项目，有机会选择 Angular 就用 Angular 吧！

微前端“普及”

从 2018 年，我开始推广微前端架构至今，这种架构模式的基础设施已经越来越成熟。我们可以明显地看到，它已经从大型前端团队的落地，开始进入小型前端团队的视野里。而采用的主要意图，也发生了一些变化。原先是以大型应用架构为主而采用微前端，而几年之后，我经历过地大量相关咨询项目里，它变成以演进式方案而存在，即完成旧系统的平滑迁移。

微前端框架成熟

继我写了国内的第一个微前端框架 mooa 之后，国内诞生了越来越多的商业级微前端框架：qiankun、ngx-planet 等等。每一种框架都有各自地适用场景，这里就不一一展开。

唯一可以肯定的是：这些框架很少能直接满足大部分项目的需求 —— 因为业务特定的缘故。所以，我在过去的几年时间里，设计了越来越多的微前端演进方案。

渐进式演进方案

对于一个正常业务开发的项目来说，微前端架构不是一蹴而就的，而是演进出来的。于是，也就衍生了相关的渐进式演进方案，如：

• 元微前端框架。在 2020 年里，因为某公司需要一个更具竞争力地微前端框架，所以我联想到了：元微前端框架。虽然，我没有花时间去想象这样的框架，但是已经有人采用了类似的思想。
• 多加载器模式。对于微前端框架来说，从某种意义上来说，它只是一个应用加载器。我们通过这个加载器去加载不同框架的应用，如 qiankun 可以支持 Angular、Vue 和 React，而对于并非这种框架的应用来说，它们需要一个新的加载器。于是，多应用加载器模式孕育而生。
• 定制微前端框架。改造现有的微前端框架，使之适合于现有的业务架构。

因此，微前端作为一种前端遗留系统重写的架构模式，它将越来越普及。

低代码平台的返璞

中台火了几年之后，被誉为“前端中台”的低代码平台也在整个市场上越来越火爆。在这个行业里，开发人员划分了三个领域 no code（无代码 ）、low code（低代码）、pro code（专业代码），而当开发人员把这三个领域合并为一个系统时，这个系统就变得异常奇怪。

依我的观点来看，既然面向的人群不一样，面向的水平不一样，那么我们应该有三个独立的、拆开的系统。它们可以共享基础设施，这不代表它们就是一个系统。

重塑用户体验

对于一个低代码/无代码平台来说，平台的复杂度主要是由其要承载的业务引起的。如果一个只是做 H5 又或者是表单的低代码平台来说，其本身设计不会过于复杂。而在场景变得越来越多时，系统变得愈发复杂，直至使用人员无法理解。

事物的发展是有其规律的，当平台能满足需求之后，自然而然下一步便是重塑用户体验。

构建开发者体验

PS：这一小部分主要是从我的个人的角度来看，可能能代表一部分开发者。

从个人的角度来看，拖拉拽对于开发人员来说，它的成本非常高。可编码的东西，如果可以通过按键来解决的放，那么它必然会提高效率。举个简单的例子，在设计低代码平台时，我们会对组件进行命名，如 header。那么，我们通过诸如于 VS Code 的 snippets 来直接生成表示页面/组件的 DSL，必然会比我在页面上拉拉扯扯快得多。

动态编写 DSL 胜于拖拉拽。

超越前端

后端工程师，首先它是个工程师，然后它才是个后端工程师。前端工程师，首先它是个工程师，然后它才是个前端工程师。

在思考问题时，也应该从总体的角度来考虑问题，再从自身的角度来看怎样全局优化，这便是资深程序员与普通程序员的区别。所以，站在更高的视角，看到的问题就不一样，比如 BFF 的全局优化，比如 Serverless 架构等等。

Serverless 一体化

对于大量地小型应用来说，直接采用 Serverless + 小程序来说是一个非常便宜快速的方案。至少在前期的试错成本非常之低，无需考虑服务器和并发等问题，也无需浪费大量地服务器资源。

不论使用的是什么技术栈，在 2021 年，你都应该试试 Serverless 架构了。

重回跨语言前端

Rust、Web Assembly 或者是 Kotlin，又或者是一些新兴的语言，它们都可以以一种新的试，让其它领域的开发人员编写能运行在浏览器上的代码。

最近的一年多里，在大家看来：我一直在忽悠前端开发人员写 Rust。原因无非是，它的后台是 Mozilla —— 可以快速运行在浏览器之上，又是系统编程语言 —— 可以尝试大量非常有意思地传统应用。

其它

最后，让我用一个老生常谈的问题，来结束这篇话题 —— 前端是选择深度还是广度？

这个问题的答案其实蛮简单的，也蛮打击人的。它取决于我们所在的团队的规模，当团队够大的时候，我们就越有机会尝试一些特别有意思的新技术，又或者是深入优化某一领域的技术。这个道理也适用于后端。