小程序工程化思考

December 25, 2020

和传统工程化对比

先看下传统前端工程化关注的事情 (from umi) image.png

image.png

小程序可做的就相对很少,源于技术本身的约束性,我们做一个对比:

  1. 框架角度:目前市面上有 kbone,taro,remax/r2m,mpvue,mpx等等选择,从优选业务场景覆盖的移动设备角度看均有明显的体验问题或不再维护,所以目前还是基于原生框架进行开发,从小程序不提供操作视图的底层api,不提供组件层级管理关系,不提供模板递归,限定包大小,固定的路由模型等等的约束性看,这也可能是微信比较推荐的做法。
  2. TS:目前是一个问题,没有最佳的TS规范,小程序原生的TS方式并不能很好的适应复杂场景的开发
  3. 样式(css): 因为没有视图层的接口,所以没有过多的选择,微信本身提供了 @import等模块化管理的能力,为了包大小,只能使用postcss+变量插件(或css变量)的方式进行样式管理
  4. JS编译/模块打包/压缩: 这是一个可以做的事情,webpack并不适用于小程序,这部分需要自研 传统基于babel的有mpbuild或者现代的基于esbuild/swc的mpe
  5. 路由管理/请求库: 均强制限制在小程序框架提供的方案,灵活性低
  6. 资源加载方式:固化为小程序主包,子包的形式,最新版基础库提供了动态加载的能力,有两个问题
    1. 对基础库有要求的小程序都无法使用
    2. 是一个比较限制的方案,并做传统微前端架构那样从远端加载代码
  7. 数据流:可能是一个可以做的事情,不过小程序本身不具备context的能力,实现出来的对比传统前端的易用性不是很好
  8. 代码风格:eslint prettier 等最佳实践
  9. 文档能力/通用组件开发能力:需要做的事情
  10. 测试:可能需要做,不过一般在业务团队因为ROI不高,所以不被重视

这样对比下来,就明显能感受到,我们在传统工程化上能做的事情比较少,更多的是要关注业务集成&业务领域的一些能力的建设。

小程序框架对比传统前端框架缺少什么

小程序 前端 问题 能否对齐 是否必要
启动流程 固定的 app → page 生命周期同步调用 任意编排 小程序在启动阶段有异步的依赖关系时时处理会很复杂 不能
code split 包维度 任意切分 不能
加载能力 支持 分包异步化 ,且必须提前构建到一起,支持2.17.3及以上 支持从网络加载包 微应用拆分无法绕过集成构建 不能
编排能力 page+component 任意编排 不能
组件能力 缺失 slot能力 ~ 不能
组件间通讯 props+父节点中转 props和context能力
视图介入 不可以直接操作视图 可以直接操作dom 小程序底层能力缺失导致动态能力很难有性能保障 性能考虑不能
动态执行JS 不支持 eval等
路由 固化 page → page + tabbar 任意自定义 无法做到贴合业务场景做编排 不能

演进视角看小程序当下成熟度对比

2021 增补

第一阶段:14年~17年 第二阶段:18年~21年 第三阶段:21年后 核心 小程序能力
框架 范式转移,vdom 提出 代表:react vue2 范式转移,编译时代替运行时 vdom 代表:svelte solidjs 范式转移,去除 JS 运行时开销 代表:qwik 更好的性能 还处于第一阶段
框架理念 class+声明式框架+TS 支持 代表:react<0.14,vue2 function 代表:react>15 hooks 代表:react 16,vue3 增强框架对内聚性的表达带来更强的可维护性 不到第一阶段,可做工
样式理念 样式预处理 代表:less scss 样式后处理 代表:postcss 样式框架

代表:tailwindcss
增强框架对内聚性的表达带来更强的可维护性 不到第一阶段,可做工
状态管理 单向数据流+单store,中心化

代表:flux,redux,vuex,mobx
增强ts+多store,去中心化

代表:mobx,pinia,recoil
元数据,惰性更新等尝试

代表:zustand、jotai、valtio
更好的DX,更好的性能,配合框架理念 不到第一阶段,可做工
工具链 范式转移,依赖分析,打包部署

代表:webpack
微创新

代表:rollup
效率大幅度提升

代表:vite
效率的提升 不到第一阶段,可做工
架构 SPA,SSR

代表:umi
微前端,SSR 流式,SSG,ESR

代表:qiankun
服务端组件等

代表:react18
大规模协同问题

算力转移提高性能
不到第一阶段