2024年稀土开发者大会前端未来专题聚焦前端领域的前沿趋势、新技术在前端的应用、跨平台开发的新进展、AI 技术对前端的影响等主题，探讨如何利用新兴技术提升开发效率和用户体验，来应对业务创新需求和挑战。以下就基于提升开发效率、跨平台开发、提升用户体验及AI技术等方面进行做一个总结和梳理:

一、提升开发效率1、解锁 JS/TS 及 Web 框架本地 AI 驱动的高效编程

代码补全是开发者提效的核心支柱，也是IDE与编辑器不可或缺的功能。现在的代码补全功能很多基于编辑器插件做的，插件本身不能做的很重，基本也是采用基于云端的大型语言模型（LLM）进行数据传输。而编辑器厂商占有得天独厚的优势，可以专为特定编程语言和框架定制的本地部署大型语言模型，来实现既安全又高效的即时代码补全功能。

本地化部署模式消除了数据外泄的风险，通过避免互联网传输，筑起了坚固的数据安全防线，对于一些无法搭建自己大模型又担心代码泄露的小厂商特别有用。

1）语言模型是针对特定语言和框架进行训练的，而不是一般性训练，因此它可以更小。如WebStrom就是对JS/TS 及 Web 框架进行特定训练。

2）根据开发环境配置（CPU & GPU）进行优化；例如，如果使用的是 x86-64 架构，模型将在 CPU 上运行，而如果使用的是 ARM64 架构，模型将使用计算机 GPU 的功能。

3）代码补全确定为一行，作为一种“相当公平的折衷”，专注于一个问题，注意质，开发人员可以轻松使用。

4）利用静态分析功能和对代码的理解来过滤掉不正确的建议，确保 IDE 不会建议使用不存在的变量和方法。

参考：/zh-hans/blo…

2、得物前端 monorepo 技术架构的设计与实践

当业务发展迅速，团队规模指数级增长的背景下，研发团队代码复用低效、基础能力升级难、问题定位时间过长、协助效率低下等的问题就会凸显。

Monorepo 大仓模式中，把组件放在共享目录下，就能通过源码引入的方式实现组件共享。越来越多的应用愿意走进大仓，正是为了享受这种组件复用模式带来的开发便利。这种方式可以满足大部分代码复用的诉求，但对于复杂业务组件而言，无论是功能的完整性，还是质量的稳定性都有着更高的要求。

有好处必有坏处，比如大仓模式下，增加了非owner改动代码的风险，多项目在一个仓库中，代码体积有几个 G，git clone时间较长。

得物前端 monorepo 大仓的研发模式目前包含 110+ 应用，覆盖前端平台 B 端、C 端、Node 和小程序应用，在大仓代码管理、权限设计、研发流程、单元测试、主干研发模式等技术上遇到了很多的技术难点与挑战，并且在各技术领域都有一定的积累和沉淀，为公司前端提供了统一的研发流程，规范了代码标准，提升了团队之间整体的协作效率。

1）按需拉取，基于【git sparse checkout】功能制定相应的命令行cli+vscode插件，通过选择来按需拉取。

2）代码标准规范，制定大仓根目录代码规划和应用目录代码规范，执行应用规则，然后再执行大仓通用规则

3）权限管理，支持目录文件Owener权限配置，在CR阶段会有文件目录权限卡点，避免误改

4）研发流程设计，统一分支命名规范，统一构建脚本，严谨的MR流程，单元测试流程卡点

以上流程没有统一的标准，可以根据实际的业务场景，以提效研发流程为目标，做尝试性探索.

参考：/article?id=…

二、 跨平台开发的新进展1、Taro 鸿蒙适配：CAPI 探索与实践

随着纯血鸿蒙不再支持APK安装包，头部互联网厂商纷纷进场，因此入门学习并适配鸿蒙逐渐成为趋势。

1）Taro 适配原理

为什么web框架不能跑在小程序上，一是宿主环境不一样，小程序容器没有提供DOM和BOM的API，二是小程序也没有提供指令式操作节点的能力。

那小程序适配原理就是模拟DOM和BOM的API，插入到Taro运行时中，生成自己的虚拟DOM，再生成对应的WXML模版。最终还是生成小程序的代码，然后让小程序引擎进行渲染。

Taro适配鸿蒙，前半部分可以保留，只需要在视图层改成鸿蒙的ArkUI框架，交给鸿蒙去渲染就好。

理论成立，实践开始。

2）ArkUI性能优化类似于vue3静态提升，在编辑阶段，通过SWC对代码的AST进行分析，输出TaroStaticTemplate，只保留可变节点提供双向绑定更新功能，解决节点数过多的问题。动态属性设置，根据需要使用多态样式进行属性设置。

3）基于C-API适配及优化Ark暴露了C++接口，允许调用更底层的UI能力。 直接在C++蹭通过指令的方式去创建节点，直接绕过ArkUI逻辑，框架逻辑运行在C++层，性能更佳。

三、用户体验1、可视化叙事与智能生成

数据可视化是指任何将数据转化为可视化展现（如图表图形、地图，有时甚至只是表格)的过程和方法。而叙事可视化是指数据驱动的，以多种可视化元素（文字 声音、图表、图形...）为载体，以表达内容、情感、为目标的形式、方法及作品观点。它通过将复杂的数据和信息进行视觉化处理，使得观众能够更加直观地理解数据的含义和背后的故事。

学术界在2015年的时候对可视化叙事提出了一个明确的定义并且介绍了如何构建一个数据故事。首先我们要知道，一个数据故事由不同的片段组成，每个片段都描述了一部分信息，通过将这些片段串接起来就可以得到一个数据故事。同时，为了丰富这个数据故事，我们还需要一些标注、叙述、旁白来强调一些关键信息。

下面这个流程图清晰的描述了如何搭建数据故事。

首先进行数据分析，探索有用的关键信息拿到关键信息后构建一个剧本，通过一个顺序将这些信息串在一起将故事通过可视化的形式呈现出来最后就是将这个故事通过某种形式呈现给观众，比如动画或者幻灯片。

当前数据可视化领域最有挑战的两个方向为“叙事可视化”和“智能可视化”。对应的字节开源的两个产品，VStory和VMind。

1）VStory叙事框架

在完善传统统计图表的基础能力之上，定义了完整的可视化叙事领域模型，并实现了集定义、渲染、编辑于一体的可视化叙事方案。目前 VisActor 开源出来的库有如下几个：绘图引擎 VRender，图形语法 VGrammar，图表库 VChart，表格 VTable。

其中 VChart 与 VTable 就是业务上常用的图表与表格库，而 VGrammar 是更底层的图形语法库，使用一套通用的结构描述任意图形，而最底层的 VRender 则是与浏览器绘图 API 的桥阶层，是一套绘图 API 抽象。

首先需要把故事的概念通过语法固定一下。故事由角色（characters）、幕(acts)、场(scenes)组成，场下面有很多动作（action），比如淡入，淡出等。将这些有机结合起来就可以实现一个可视化故事。

2）智能可视化在 VStory 基础上，基于大语言模型的智能叙事生成能力，可以实现了基础的图表推荐与生成、智能美化、智能标注、智能探查、智能动画编排等功能。

参考：/articles/73…

2、Wasm + WebGL 在前端互动技术中的应用实践

前端互动技术一般应用在增加互动性，增强品牌形象，提高趣味性和娱乐性的用户交互场景。前端互动技术使用最广泛是Lottie。Lottie 是动画 Airbnb 公司开源的跨平台动画框架，支持将 AE 中设计的动画导出为 Json 协议，是前端最流行的动画协议；但是在 Web 上官方只提供了三种渲染方式（SVG、Canvas 2D、HTML），并没有支持 WebGL；而前端最流行的那些 JS WebGL 渲染引擎也没有直接支持 Lottie 动画，通常需要使用第三方库或插件来解析和渲染 Lottie 动画。这就会带来三个问题：官方渲染方案性能低；离屏 Canvas 渲染性能低；JS 图形计算性能低。

WebAssembly（Wasm）是一种可以在 Web 浏览器中运行，提供比 JavaScript 更高的性能，并且支持多种编程语言的全新的字节码格式；基于其高性能的优势，尝试将其应用到渲染场景中，打造了了基于 Wasm + WebGL 的高性能、轻量化的 Simple 渲染引擎。以期借助于 Wasm 的高性能计算，以 Simple 引擎为基础，保持轻量化的同时，解决目前前端动效和轻互动场景主流技术方案如 Lottie 动画、动画图片（序列帧、 Apng 、WebP）、JS 渲染引擎等存在的能力受限、资源体积大、性能较低等问题。

考虑到前端用户学习和使用成本，Simple 引擎使用 TypeScript 语言开发上层接口，主要是利用 TS 封装简单对象，同时做类型提示方便前端用户使用，另外还提供尽可能高性能的方式和 Wasm 进行交互；底层则使用 C/C++，主要处理计算工作，比如：矩阵计算、图形计算、动画计算、动态合批等；同时Simple 引擎目前的渲染管线主要以 2D 为主，也分为两部分：JS 部分负责处理数据量少但是 GL 调用频繁的操作，Wasm 部分则相反负责处理数据量多但是 GL 调用少的操作，尽可能达到性能最优解。

Lottie WebGL 渲染是利用上文提到的 Wasm + WebGL 渲染引擎去渲染 Lottie 动画的方案，在几乎完美还原 Lottie 动画的基础上，利用引擎封装好的相关机制（事件、渲染对象）扩展 Lottie 动画的交互控制能力，丰富其特性支持，以及基于 Wasm + WebGL 渲染提升动画性能。

通常做高动效场景下的，提高表现力的同时保证动效的开发效率和性能表现是每一个厂商都会遇到的技术难题。深入渲染底层，并基于自身业务和开发流程，自研动效渲染引擎是必然结果。

3、前端体验优化

以往我们做前端优化，往往都是专注于性能优化，目标是如何把前端项目，网站页面的性能给越做越好。因为性能优化不是目的，只是手段和过程。改善用户体验和开发体验才应该是我们做优化的根本目的。因此前端优化大都有以下问题：

目标不明确，看到别人的优化方案有效果，就生搬硬套到自己的项目上，对自己项目的现状和痛点缺乏了解。

缺乏量化指标，拿不出客观准确的指标衡量优化效果，只能笼统的说产出是性能优化了。

只关注性能指标，没有实质性的改善用户体验，没有让用户主观上感受到优化收益。

缺乏长效化机制，无法确保优化效果长期稳定，过一段时间做的优化就被覆盖甚至删除了。

忽视了开发体验和用户体验的直接正相关性。

优化前充分准备量化数据，是前端体验优化不可或缺的灵魂。经过实践检验且行之有效一套量化指标，是由谷歌总结了海量用户数据后，发明的5类web-vitals指标。

从web-vitals获得的比较有统计意义的数据主要有：各指标的数值（value），例如累计FCP的 "value": 63.20000076293945,；评分（ratings）：按官方标准对值进行划分得到的字符串值，共有优 （'good'），待提升（'needs-improvement'），差（'poor'）三类值，可用于对数据进行标准化处理；Web Vitals也有chrome插件，可以实时查看网页性能。

有了量化用户体验的手段，我们就可以正式开始前端体验优化了。介绍一类投入产出比非常高的前端体验优化方案：

1）资源优先级提示：资源优先级提示是浏览器平台为控制资源加载时机而设计的一系列API，主要包括：预取回 Prefetch，预加载 Preload，预连接 Preconnect，DNS预取回 DNS-Prefetch

2）代码分割最佳实践：细粒度代码分割，通过配置，自动拆分出数十个体积小、粒度细的打包产物文件。同时，利用HTTP/2协议多路复用的特性，避免因加载静态资源数量过多导致的网络阻塞问题。目标是实现前端项目在多次打包部署上线后，仍然能复用之前版本的文件缓存，不必重新下载，从而加快页面加载，优化用户体验。

3）SSR架构进阶优化：CSR 到 SSG、ISR

参考：/post/738682…

四、AI 技术对前端的影响1、如何利用 AIGC 提高前端的竞争力

前端最大的困境是什么，可能是离业务比较远，甚至于不了解业务也可以正常工作。反向思考一下，前端为什么要了解业务呢？业务不是业务方更理解嘛。基于此，直接让业务方来做业务不就好了，于是低代码就来了。

低代码的底层架构就是，开发准备好物料，做好管理，搭建好可视化界面，然后剩下的交给业务去搭建就好了。完全是革自己的命，贡献给业务方。但做过低代码的都知道，东西都搭建好了，业务方说他不懂，还是你来吧，最后还是前端承担了所有。怎么破局呢，AIGC来了。

大模型可以让业务方以自然语言表达自己的需求，你需要借助你的业务知识库、基础物料、DSL模型和业务数据训练自己的大模型，使得大模型更贴合你的业务场景。在应用层，将业务需求分解成具体文档，通过Prompt转换来具体的code。

当然大模型更适用于具以下特征的低代码平台：粗颗粒度、高集成度的组件；交互体验一致性高，较少的个性化交互需求，并针对具体场景做极致简化。不适用特征：可视化至上，对个性化样式、交互需求极高细粒度抽象。

当你做低代码的时候，你以为你不需要了解业务了，但做着做着才发现你需要了解更多的业务，找出其中的共性，抽象出数据模型，同时还需要喂给大模型，等等。

最后前端还是需要回归业务，提升价值，在业务中学习AI，使用AI，发挥AI的价值。

总结：

即便是最资深的前端从业者，每个人看前端未来也有不同的侧重点。这倒不是因为视野的局限，而是现在前端领域太多了，专精其中某几个领域就足够了，适量比全面更好。

同时前端底层也在逐渐封闭，通往底层的大门已经一扇扇逐渐关闭了，将更多的开发者挤到上层区域建设，所以仅学会近几年的前端知识依然能找到工作。然而上层建设是不封顶的，有人看到了山，有人看到了星球，不同业务环境，不同视野的人看到的东西都不同。

一场大会不会告诉你前端的未来在哪里，它只会给你一点提示，剩下的都靠你去思，去考，去拓展了。