前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >前端规划:我的 2021 前端技术战略

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

作者头像
Phodal
发布2021-01-29 15:12:04
1.3K0
发布2021-01-29 15:12:04
举报
文章被收录于专栏:phodal

去年我画了一张架构图,在介绍整个前端的趋势,今年依旧是这张「云研发路线图』开头。

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

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

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

前端架构治理

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

其它

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

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

就这样,让我凑够 2021 个字吧。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-01-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 phodal 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前端架构治理
    • 大型前端应用
      • 规范之旅
      • 微前端“普及”
        • 微前端框架成熟
          • 渐进式演进方案
          • 低代码平台的返璞
            • 重塑用户体验
              • 构建开发者体验
              • 超越前端
                • Serverless 一体化
                  • 重回跨语言前端
                  • 其它
                  相关产品与服务
                  腾讯云微搭低代码
                  微搭低代码是一个高性能的低代码开发平台,用户可通过拖拽式开发,可视化配置构建 PC Web、H5 和小程序应用。 支持打通企业内部数据,轻松实现企业微信管理、工作流、消息推送、用户权限等能力,实现企业内部系统管理。 连接微信生态,和微信支付、腾讯会议,腾讯文档等腾讯 SaaS 产品深度打通,支持原生小程序,助力企业内外部运营协同和营销管理。
                  领券
                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档