总体来说，大趋势没有太大变化。这里不考虑一些具体的技术，而是从总体（战略）角度考虑。所以，有几点：前端架构治理。微前端的“流行”，低代码平台的回归本源，超越前端似乎最后一点一直都是这样，哈哈。前端架构治理前端架构治理是一个比较复杂的问题，我们被局限在一个两难的境地：要做的事情很多，但JavaScript的灵活性每一步都困扰着我们。所以，在某些时候，我们能管的是有限的。常见的有：构建优化、组件化、微前端等。大型前端应用单个前端应用具有一定的规模，本身就比较少见——从比例上来说。但是一旦遇到，往往需要大量的工作来管理整个前端应用，还需要开发一些工具。好在市面上已经有大量类似的工具，像Lemonj这样的轻量级自动化CSS重构工具也可以编写。老实说，如果我们不好好管理CSS中的color变量，那么整体的规范性就会成为一个新的问题。SpecificationJourney我不想在这个话题上浪费时间，但我真的很无奈。兄弟姐妹们，能用TypeScript就用TypeScript，能绑定各种Lint就用各种Lint，能用GitHooks+Husky就加！大型前端项目，如果有机会选择Angular，就用Angular吧！微前端的“火爆”从2018年我开始推广微前端架构开始，这种架构模型的基础设施已经越来越成熟。从大型前端团队的落地我们可以清楚地看到它已经进入了小型前端团队的视野。采用的主要意图也发生了一些变化。本来，微前端主要是用于大型应用架构，但是几年后，在我经历的大量相关咨询项目中，它已经成为一种进化的解决方案，即完成平滑迁移旧系统。微前端框架成熟。在我写出国内第一个微前端框架mooa之后，越来越多的商业级微前端框架在国内诞生：qiankun，ngx-planet等等。每个框架都有自己的适用场景，这里不做展开。唯一可以肯定的是，这些框架很少能直接满足大多数项目的需求——出于业务特定的原因。因此，在过去的几年里，我设计了越来越多的微前端进化方案。渐进式演化方案对于一个正常的业务开发项目，微前端架构不是一蹴而就的，而是演化而来的。由此衍生出相关的增量演进方案，如：元微前端框架。2020年，因为一个公司需要一个更有竞争力的微前端框架，所以想到了：元微前端框架。虽然，我没有花时间去想象这样一个框架，但是已经有人采用了类似的想法。多加载器模式。对于微前端框架，从某种意义上说，它只是一个应用程序加载器。我们使用这个loader来加载不同框架的应用，比如qiankun可以支持Angular、Vue和React，但是对于不属于这个框架的应用，就需要一个新的loader。于是，多应用加载器模式诞生了。自定义微前端框架。改造现有的微前端框架，使其适合现有的业务架构。因此，作为一种改写前端遗留系统的架构模式，微前端将会越来越流行。经过几年的低代码平台回归基础中台，被称为“前端中台”的低代码平台也在整个市场上越来越受欢迎。在这个行业里，开发者把nocode（无代码）、lowcode（低代码）、procode（专业代码）三个区域划分开来，当开发者把这三个区域组合成一个系统时，系统就变得很奇怪了。在我看来，既然目标群体不同，层次不同，那么我们就应该有三个独立的拆解体系。仅仅因为它们可以共享基础设施并不能使它们成为一个系统。重塑用户体验对于一个低代码/无代码的平台来说，平台的复杂性主要是由它需要承载的业务造成的。对于一个只做H5或者表单的低代码平台来说，设计本身并不会太复杂。而当场景越来越多，系统就会越来越复杂，直到用户看不懂。事物的发展有其规律。当平台能够满足需求时，下一个自然步骤就是重塑用户体验。构建开发者体验PS：这一小部分主要是我个人的观点，可能代表一部分开发者。从个人的角度来看，拖放对于开发者来说是非常昂贵的。可编码的东西，如果能一键解决，那肯定会提高效率。举个简单的例子，在设计低代码平台的时候，我们会给组件命名，比如header。然后，我们直接通过VSCode等snippet生成代表页面/组件的DSL，这样势必会比我在页面上拉来拉去快很多。即时编写DSL比拖放要好。超越前端和后端工程师，首先是工程师，然后才是后端工程师。前端工程师，首先是工程师，其次才是前端工程师。在思考问题的时候，也要站在全局的角度去考虑问题，然后再从自己的角度去看待如何去优化全局。这就是高级程序员和普通程序员的区别。所以从更高的角度来看，看到的问题是不一样的，比如BFF的全局优化，比如serverless架构等等。Serverless集成对于大量的小型应用，直接采用Serverless+applets是一种非常便宜和快速的解决方案。至少前期的试错成本很低，不需要考虑服务器和并发的问题，不需要浪费大量的服务器资源。无论你使用什么技术栈，在2021年，你都应该尝试Serverless架构。回到跨语言的前端Rust、WebAssembly或Kotlin，或者一些新兴的语言，它们都可以用一种新的尝试，让其他领域的开发者编写出可以在浏览器上运行的代码。在过去一年多的时间里，在大家看来：一直在忽悠前端开发者写Rust。原因不外乎它的背景是Mozilla——它可以在浏览器上快速运行，它是一种系统编程语言——它可以尝试很多非常有趣的传统应用。其他最后，让我用一个老生常谈的问题来结束这个话题——前端选择深度还是广度？这个问题的答案其实很简单，也很震撼。这取决于我们所在的团队规模。当团队足够大时，我们就有更多的机会去尝试一些特别有趣的新技术，或者对某个领域的技术进行深度优化。这个原则也适用于后端。
