Blog

Blog

PHODAL

前端规划:我的 2021 前端技术战略

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

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

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

前端架构治理

前端架构治理是一个颇为复杂的问题,我们限入了一个困境:要做的事情很多,但是无奈 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 —— 可以快速运行在浏览器之上,又是系统编程语言 —— 可以尝试大量非常有意思地传统应用。

其它

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

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

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签

最近的一些事

  • 最近我和我的同事们,一起在创建一个新的编程语言:Charj 。它是一个使用 Rust 编写的描述式、中间编程语言。GitHub: https://github.com/datum-lang/datum

    Nov. 14, 2020, 9:27 p.m. | China