参加了WOT全球技术创新大会2023，迅速整理了 《大前端最佳实践》专题的收获

令人心动的 WOT

最近这段时间，我最期待的一件事就是6月17号这天的到来。因为之前51CTO的官网预告了"WOT全球技术创新大会2023"。（这个设计图怪好看的）

点击进入大会的官网，大会的举办时间是6月16号、6月17号这两天。16号那天工作没时间，17号这天我挺早出发的。因为到的早，还玩了几个小游戏，拿了好几个小礼物。

还有一个比较惊奇的发现，51CTO 有自己的技术期刊叫做《CTO悟道》，现在已经有6期了。可以关注公众号——51CTO技术栈，然后发送"订阅期刊"，可以看电子期刊。

大会议程速览

回归到大会内容，大会两天时间，同一个时间段里有不同的主题同时开始，有十几个专题。既有创新技术的分享，又有技术最佳实践的传递。

拿到这个大会议程的一览表的时候，我是真实体会到了"乱花渐欲迷人眼"。很多专题都想去听，但是自己又没有练会"分身术"。

只好选了最感兴趣的两个专题，分别是《大前端最佳实践》和《AIGC技术及商业化落地》。

今天主要分享《大前端最佳实践》的收获。

大前端最佳实践

作为一名前端开发工程师，很难不被"最佳实践"这四个吸引。

试想一下，卡了好久的业务瓶颈，突然来了一位大佬，说你试试这种方式，瞬间"柳暗花明又一村"。

字节跳动的前端工程化实践

这个主题的老师，是字节跳动-Web Infra-前端架构工程师的林宜丙。

林老师这次的分享是关于前端工程化实践。

工程化是前端很重要的一个环节，同时也会随着业务的发展面临一些挑战。

来一起听听林老师讲字节跳动是如何解决这些新挑战所做的实践。

主题内容

前端工程化是指在前端开发过程中，采用一系列的技术手段和工具，来提高开发效率、保证代码质量、提高代码复用性、实现自动化流程和促进团队协作等方面的目标。近年来，前端开发领域呈现出如下3个趋势：涉及的平台越来越多、支撑的业务越来越多、团队的规模不断增大。

上述3个趋势具体到前端工程上又表现为：代码规模增大、维护人数增多、研发工具增加、依赖关系复杂，这些趋势让前端工程化面临新的挑战：多项目维护成本高、多人开发协作成本高、构建速度慢、应用劣化快。

主题大纲：

• 采用 Monorepo 方式维护多项目
• 采用微前端/微模块方案分治应用
• 投资 Rust 构建工具和 Build System
• 提供基于规则的研发诊断工具

采用 Monorepo 方式维护多项目

Monorepo是一种将子项目组织到一个仓库中统一管理的策略。主要目的就是降低多项目维护成本。

与Polyrepo将子项目分布到不同的仓库中管理的方式有很大不同。

采用微前端/微模块方案分治应用

降低多项目维护成本的方式主要有三种：

• 复用基建：让开发者重新专注于应用本身
• 代码共享：降低代码复用的成本
• 原子提交：使用自动化的多项目工作流

投资 Rust 构建工具和 Build System

加快巨石应用的构建速度的两种方式：

• Bundler：加快巨石应用的构建速度
• Build System：加快 Monorepo 的构建速度

Bundler 用途是处理文件之间的模块依赖关系图，并将其打包成静态资源。

字节跳动自研的Rspack，是一个基于 Rust 的高性能构建引擎（Bundler），具备与 Webpack 生态系统的互操作性。

Build System，用来处理 Monorepo 下的项目依赖关系，并据此调度构建任务。它有以下能力：

• 任务并行能力：最大限度的并行任务加速
• 多级缓存能力：对构建实现了多级缓存
• 按需构建能力：根据代码更改的影响画来构建

提供基于规则的研发诊断工具

目前前端领域的应用分治解决方案主要有：Qiankun、Garfish、BIT。

降低多人开发的协作成本的方式：

• 减轻基座负担：基座应用与业务解耦
• 细粒度的组合：模块级别的独立开发、测试、部署
• 模块协议标准：模块中信、结合低码、灰度/AB

面向构建过程与构建产物的诊断与分析的一站式工具，有 Statoscope 等。

有效地防止应用劣势的方案：

• 面向构建过程：更细粒度和更丰富的分析能力
• 可扩展的规则机制：丰富的上下文，强大的扩展能力
• 与核心研发流程结合：在 CI 中让规则真正发生规则

我的收获

目前，我们项目中确实存在巨石项目代码治理的问题，且使用中的项目，代码是增量迭代的。我提出这个问题之后，林老师的建议是采用"渐进式"的策略，帮助我下定决心，开解了我一直以来的纠结点。

跨平台开发的最佳实践

这个主题的老师，是DCloud CTO，uni-app产品负责人的崔红保。

崔老师这次的分享是关于跨平台开发的最佳实践。

跨平台开发是前端开发者们讨论度很高的一个技术点，经常会遇到各式各样的问题。

崔老师这次带来了不一样但很有效的实践方案。

主题内容

近些年，跨平台开发早已是大家熟知的一种开发范式，但很多开发者依然面临着诸多困扰：
1. 新团队、新项目，该选型哪种开发框架？决策依据是什么？
2. 跨平台框架开发的App，即使采用原生渲染，为何还是感觉不够丝滑？原因是什么？如何改进解决？
3. 在跨平台基础上，前端如何才能进一步解放生产力？什么是最佳实践？

本次演讲，将分享上述问题的思考，并重点介绍 UTS+Serverless 这种新的开发范式。UTS采用类TS的DSL，通过Rust编译成swift/Kotlin，获得纯正原生App，在彻底解决传统Hybrid App性能顽疾的前提下，借助web生态及serverless，快速解放生产力，加快交付。

主题包括四个部分：

• 跨平台框架如何选型?
• 跨平台框架的共性问题
• UTS: 纯原生跨平台框架
• 云端一体，跨端之上的最佳实践

跨平台框架如何选型?

使用跨平台框架的三个主要目的是：增效、降本、赋能。

跨平台框架选型主要做以下方面的考虑：

• 功能：兼容终端类型，能力覆盖面
• 性能：运行体验。接近原生的丝滑?长列表、手办拖动
• 开发体验：错误提示，souremap，热重载
• 工具：持续焦成、自动化测试、工具链
• 生态：用户群体，学习门槛、生态复用
• 扩展性：平台特有能力的支持度自定义跨端扩展

跨平台框架的共性问题

目前主要流程的跨平台框架有：React native、weex、uni-app、Taro、Flutter。

它们一个共性问题是性能，比如原生渲染、阻塞问题等。

下一代跨平台框架符合以下特点：

• 继续基于 Web 技术栈
• 实现原生渲染
• 解决通讯阻塞

UTS: 纯原生跨平台框架

UTS（Uni Type Script）,是一款纯原生跨平台框架。

它拥有以下特点：

• 协作模式：协作模式改变，更少代码，更高效率
• SSR：组件支持SSR，降低SSR门槛
• 代码生成：业务抽象schemg，一键生成前后端代码
• 轮子生态：聚焦业务

云端一体，跨端之上的最佳实践

云端一体的主要特点是前后端协作模式变更。前端可直接查询DB，无需request请求。

这样的好处是：可帮助前端节省代码量。

我的收获

云端一体的开发模式，确实打破了我固有的开发思维，让我可以进行更多的技术延展。

将TypeScript编译到WasmGC的全新实践

这个主题的老师，是Intel SATG部门，WebAssembly Micro Runtime (WAMR) 核心成员的徐君。

徐老师这次的分享是将TypeScript编译到WasmGC的全新实践。

来一起围观徐老师所在的团队是如何实现的吧。

主题内容

WebAssembly已在众多领域大显身手，但目前其支持的编程语言以C/C++/Rust等系统编程语言为主，缺乏应用编程语言；另一方面，TypeScript在JavaScript基础上增加了类型标注，但这些类型信息在编译到JavaScript的过程中被完全擦除，利用率较低。本次分享将介绍一种将TypeScript编译到WasmGC的全新实践，利用WasmGC的类型系统对TypeScript进行静态化编译，同时为WebAssembly社区带来新的编程语言和开发体验。

主题大纲：

• WebAssembly的应用现状及主要挑战
• 案例介绍，解释目前使用WebAssembly的痛点
• 介绍TypeScript to WasmGC的静态化编译方案及其解决的技术痛点
• TypeScript静态编译技术未来的应用方向探讨

WebAssembly简介

WebAssembly(wasm)是一个可移植、体积小、加载快并且兼容Web的全新格式。

特点如下：

• 安全：沙箱隔离机制，宿主资源访问可控制
• 高效：通过JIT/AOT技术加持，可接近原生应用的执行性能
• 多语言支持：C/C++, AssemblyScript, Python, Go, Rust, ...

WAMR发展历史

• 2019年5月Intel开源WAMR (WebAssembly Micro Runtime) 项
• 2019年11月以创始项目身份发起并加入BytecodeAlliance(BA)
• 2021年10月转换为社区开放治理模式

设计目标：

• 广泛的适用性:从入式设备到云端
• 小尺寸，高性能的轻量级 WASM 运行时
• 适配多种CPU架构(32bit and 64bit)和操作系统
• IntelSGX/TDX一等公民支持

浏览器应用特点

1、浏览器上的应用主要来源:

• 存量C/C++代码移植到浏览器O
• Rust开发的新应用
• 游戏、机器学习(TensorFlow)等性能要求较高的应用

2、主要痛点;

• 学习曲线陡峭，需要掌握系统级编程语言，手动管理内存
• 应用生态匮乏，可复用程度低

独立运行时引擎应用

1、典型应用场景:

• 物联网
• 小程序
• 函数计算
• 可信计算
• 区块链

2、大前端应用对WebAssembly的核心需求:

• 模块化，方便动志安装、卸载
• 执行效率高，模块尺寸小
• 开发效率高，学习成本低

独立运行时引警应用案例-Disney ADK

1、Disney application development kit

• 自研底层框架，摆脱对浏览器的依赖
• 通过WebAssembly Runtime提供应用开发能力

• 高性能
• 受管控的资源访问，安全性强

• 使用Rust作为应用开发语言

2、缺点:

• 编程语言学习曲线陡峭，对开发人员要求高
• 与host之间数据交互困难，需要大量用到序列化/反序列化

将应用编程语言引入WebAssembly

1、两种

• QulckJs on WebAssembly
• CPython on WebAssembly

2、优点

引入了应用开发语言，解决了编程体验问题

3、缺点:

• VM层层微套，性能较着
• 生成的模块尺寸庞大
• 与host之问数据交互更加困

WebAssembly在前端中的主要痛点总结

• 开发者学习新的语言成本太高
• 目前主要的开发语言开发效率不高
• 现阶段支持应用编程语言的方式执行效率不高

当前是TypeScript静态化编译的有利时机

1、编程语言层面: TypeScript同时兼顾了动态和静态类型

• C/C++/Java一一静态类型系统，执行效率优先
• Python/JavaScript一一动态类型系统，开发效。
• TypeScrit一-兼顾静态和动志类型特性

2、开发者层面: TypeScript已被业界广泛接受

• 与JavaScript语法类似
• 对大型项目的架构设计及重构更加友好。

3、WebAssembly层面: WasmGC提案问世

• 用wasm直接表达高层的类型信息成为可能
• 充分利用wasm runtime的GC能力

什么是WasmGC

GC提案之前:

• 只有i32,i64,f32,f64四种基本类型
• 无自动内存管理，需要手动管理资测

GC提案引入;

• 新的引用类型

• struct
• array
• funcref
• l31ref
  anyref
• externref

• 对象可以交给runtime托管
• subtyping
• 纯静志类型系统

TypeScript编译到WasmGC方案的优势

• 尽可能地静志化编译，减小运行时负担

• 源码中的类型信息被充分利用，实现静志化编译
• class字段访问基于fieldindex，而非名字，效率更高

• 模块尺寸小

• 无需编译整个runtime到WebAssembly
• WebAssembly模块中无需自带内存管理逻辑

• 开发门搭低

• 严格的TypeScript子集，保持TypeScript原有语义
• 前端开发者无需学习新的语言就能开发高性能的WebAssembly模块
• 暂时无法静态化编译的部分可以通过any类型fallback到JavaScript

未来应用展望

• 独立运行时引擎应用

• 作为loT、小程序等场景的应用编程语言

• 浏览器应用

• 开发高性能的模块

总结

Ts2wasm为前端带来新的开发体验:

• 低学习成本，让前端也能轻松使用WebAssembly
• 直接编评到wesm，避免多层VM开销
• 混合美型系统，兼顾开发体验和运行效率

我的收获

我对 WebAssembly 了解不是很深，但是WebAssembly和浏览器结合以此实现应用的web可视化，我很感兴趣。

而徐老师最后总结中提到，Ts2wasm可以降低学习成本，未来，我会做相关的尝试。