穿越时空：2023年前端技术盘点与2024年技术展望
👉导读
在过去的时间里，前端技术稳步前行，2023 虽然没有出现革命性的技术，但在语言与标准、主流框架完善、WASM、音视频等核心场景下都有了亮眼的进步。腾讯云开发者公众号特此与腾讯 MoonWebTeam 前端团队策划了本期前端 2023 技术回顾与 2024 技术展望，希望能给业界带来一些输入与启发。读完全文还可以参加惊喜活动抽奖哦！👉目录
1 2023 技术年度回顾 1.1 语言与标准：CSS、ES 和 TS 语法持续完善，社区竟现反 TS 声音 1.2 前端框架：主流框架持续完善，黑马 Htmx 与 Qwik 异军突起 1.3 前端基础建设：多种语言助力前端基建的持续发展 1.4 Chrome 浏览器：加强对用户数据安全的保护 1.5 低代码：持续完善的低代码引擎开源社区 1.6 D2C：C2D2C 亮相，大模型赋能 D2C 未来可期 1.7 大模型：大模型应用能力持续完善与落地 1.8 跨端：鸿蒙应用开发为跨端带来新变化 1.9 WASM: 未来将与更多语言和场景结合 1.10 音视频：传统编解码与 AI 编解码并驾齐驱2 2024 技术展望 2.1 大模型持续为前端赋能 2.2 拥抱 TypeScript 是前端语言与标准的主旋律 2.3 探索更好服务端渲染是前端框架的大势所趋 2.4 Rust 是前端基础建设的未来 2.5 鸿蒙入局，跨端三分天下格局指日可待时光荏苒，2023 年已如白驹过隙般过去。虽然在 2023 年的前端大舞台上并没有出现革命性的明星项目，但在各个细分的技术领域都有一定的拓展与深耕，而且 2023 年 AI 大模型的迅猛发展也为前端领域注入了活力，接下来让我们一起乘坐时光机重回 2023，盘点 2023 年在前端行业发生的哪些重要的事情吧：
（注：此处开始文章中所有”今年“代指 2023 年，明年代指”2024 年“）
首先在被誉为大模型元年的今年，大模型的应用能力持续完善，并逐渐开始在前端多个领域中落地。
在前端语言与标准领域，今年 JavaScript 和 CSS 都有一些新的变化，在 TypeScript 已成为前端项目标配的如今，今年社区为何频频出现了不一致的声音？
在前端框架领域，前端框架的四家马车 React、Vue、Svelte 和 Angular 继续领跑，它们都在按照自己的特色不断发展与进步。此外 Qwik 和 Htmx 在今年也广受前端社区喜爱，成为年度前端框架的黑马。
在前端基础建设领域，Rust 在前端的影响力越来越大：基于 Rust 的构建工具 Respack 和 代码检查工具 Oxlint 正式发布、 Vite 官方也正式宣布计划使用 Rust 重构 Vite，替换掉原有的 Esbuild 和 Rollup。此外，前端全能工具包 Bun 正式发布 1.0 版本，成为 JavaScript 年度明星项目。
在低代码领域，低代码社区建设持续完善，基于源代码驱动和与大模型结合的低代码引擎于今年首次亮相。
在 D2C 领域，出现了 C2D2C 这个新的解决方案，大模型为 D2C 赋能未来可期。
在跨端领域，鸿蒙应用的异军突起为跨端领域开辟了新天地。
此外在浏览器、 WASM、音视频等与前端息息相关的底层能力领域也有新的发展。
01
1.1 语言与标准：CSS、ES 和 TS 语法持续完善，社区竟现反 TS 声音
根据 StackOverflow 2023 年度流行语言报告中统计显示， 前端三剑客（HTML/CSS/JavaScript）依然位居榜首。而 JavaScript 已连续 11 年成为最流行的编程语言，而 TypeScript 也上升到第五的位置。整体而言，前端社区依旧充满朝气与活力。接下来让我们回顾一下 2023 年前端在语言与标准的领域上有哪些变化吧。
（图选自 Stack Overflow Developer Survey 2023）
已成前端项目标配的 TypeScript 社区竟现抛弃呼声？
近年来，由于 TypeScript 提供的类型安全性、更好的工具支持以及与 JavaScript 生态系统的兼容性，它所带来的对代码质量和可维护性方面的价值已被前端社区所认可，目前已经成为开发 Web 应用程序的主要编程语言之一。从 GitHub 2023 年度报告显示，今年 TypeScript 首次超过 Java，成为 GitHub 上 OSS 项目中第三大最受欢迎的语言，其用户群体增长了 37%。
（图选自 Stack Overflow Developer Survey 2023）
1) TypeScript 5.0：对包体积及构建速度进行全面优化
今年 3 月 16 日 TypeScript 5.0 正式发布，该版本更新了许多令人激动的新特性，例如支持全新的装饰器、extends 支持多配置文件、引入 const 类型参数等。笔者认为 TypeScript 5.0 最大提升应该是在一直令人诟病的包体积大小和编译构建速度上的优化。
首先，TypeScript 从命名空间转移到了模块中，这使我们能够利用现代构建工具来执行优化，如作用域提升，此外还删除了一些废弃的代码。优化后，TypeScript 5.0 相较于 TypeScript 4.9 ，包体积从约 63.8 MB 减少到约 37.4 MB，降低了约 42%。
具体更多的有关模块迁移描述可参考相关的官方文档：https://devblogs.microsoft.com/typescript/typescripts-migration-to-modules/
（数据与图选自 TypeScript 5.0 中的新特性： 声明器、构造类型、枚举改进、速度以及更多内容）
其次，TypeScript 5.0 还对代码的数据结构以及算法实现上进行优化，例如 TypeScript 5.0 会现有对一些常用的机制进行了缓存，以便在编译操作之间重复使用。TypeScript 5.0 相较于 TypeScript 4.9 编译速度上有着明显的提升。
（数据与图选自 TypeScript 5.0 中的新特性： 声明器、构造类型、枚举改进、速度以及更多内容）
2) TypeScript 5.2：使用 using 关键字进行资源管理
在一些编程语言中，比如 C#，使用 using 关键字可以确保在使用完资源后，会自动释放这些资源。然而，在 JavaScript 中，开发者需要手动释放一些资源，比如打开的文件、数据库连接等。这就导致了在代码中需要显式地处理资源的释放，容易出现忘记释放、异常时未能释放等情况。
而 TypeScript 5.2 新增的 using 关键字，配合 Symbol.dispose 一起使用，能很好的解决这个问题。
使用 using 前：不管程序是否发生异常，都需要在手动关闭文件句柄
import { open } from "node:fs/promises";let filehandle;try { filehandle = await open("thefile.txt", "r");} finally { await filehandle?.close();}使用 using 后：离开作用域后会自动释放文件句柄
import { open } from "node:fs/promises";const getFileHandle = async (path: string) => { const filehandle = await open(path, "r"); return { filehandle, [Symbol.asyncDispose]: async () => { await filehandle.close(); }, };};
await using file = getFileHandle("thefile.txt");更详细的信息可以阅读这篇文章：https://juejin.cn/post/7246978810021199930
3) 反对 TypeScript 的声音
尽管目前 TypeScript 如日中天，取得了前所未有的成功。然而，在今年 8 月份，Ruby on Rails 的创建者 David Heinemeier Hansson（DHH） 从即将发布的 Turbo 框架第 8 版中删除了 TypeScript，并发文称 “通过添加微不足道的类型技巧，让我的开发体验变得更加糟糕，而且频繁引发很多困扰。本应简单的事情反而变得很困难。”
（图选自 2024 款：最新前端技术趋势 - 掘金）
其实，Turbo 并不是第一个放弃 TypeScript 的前端框架，今年 3 月，Svelte 团队计划将会从目前使用的 TypeScript 迁移到 JSDoc。Svelte 创始人 Rich Harris 曾在推特上说道：Svelte 并没有放弃类型安全，而是改用 JSDoc，以减少包体和代码编译时间，依旧支持使用 tsc 编译器检查类型。
（图选自 前端框架Svelte放弃TypeScript，JS赢！-CSDN博客）
早在 2020 年，Deno 团队已经开始在 Deno 内部代码抛弃 TypeScript，当时 Deno 团队给出的理由如下：
在变更文件时， TypeScript 导致连续编译过程变得非常缓慢。
在创建 Deno 可执行文件以及面向用户的 API 源文件时，TypeScript 结构会引发一系列运行时性能问题。
TypeScript 本身对于 Deno 代码的组织工作毫无帮助，反而增强了代码组织负担，具体详见以下的 issue https://github.com/denoland/deno/issues/4748。
总结而言，他们抛弃 TypeScript 重回 JavaScript 的主要原因如下：
减少代码编译构建时间和代码体积。
减少 TypeScript 元编程所带来的代码组织的负担和所需要编写的代码量。
4）TypeScript 转向 JavaScript 真的是一个好选择吗？
在日常业务开发中，我们通常只会使用类型定义、泛型以及简单的类型推导，并不会使用到所谓的“TypeScript 类型体操“，但是 TypeScript 强类型所带来的类型安全能够大幅度提高项目的代码质量和可维护性。而在类库和框架的开发中，抛弃 TypeScript 转向 JavaScript 的只是少数开发者，目前绝大部分的主流前端开源项目都是在拥抱 TypeScript，这也足以证明社区肯定 TypeScript 所带来的价值。
此外，虽然 TypeScript 原生编译器速度较慢，但是笔者认为这个是可以通过更换 esbuild 或则 swc 等性能更加优异的编译器来解决的。
没有任何一门语言是十全十美的，TypeScript 也毫不例外。笔者认为 TypeScript 的确会引入了一定的复杂度，但是其所提供的类型系统能够大幅度提高项目的健壮性和可维护性，在绝大部分前端开发场景下，都是利大于弊的，能够很好地规避 JavaScript 弱类型带来的大部分陷阱。
参考内容：
Design Doc: Use JavaScript instead of TypeScript for internal Deno Codeh：ttps://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#heading=h.cx5nx247bag
Ruby on Rails的创始人将TypeScript从Turbo框架中移除，引起社区不满
ECMAScript 2023：持续完善并拓展 JavaScript 语法
回顾完前端语言明日之星 TypeScript，让我们将目光转到 JavaScript 上。今年 6 月 27 日，第 125 届 ECMA 大会正式批准了 ECMAScript 2023 语言规范。总而言之，本次 ECMAScript 2023 并没有新增大的改动点，更多是对 JavaScript 原来语法的完善与增补。而笔者认为其中比较有意义的更新主要有以下两个：
1) WeakMap 支持 Symbol 作为 Key。
总所周知， WeakMap 的 Key 是弱引用，且要求是唯一的值。由 Symbol 具有唯一性，保证不可重建，因此在今年的 ECMAScript 2023 新特性中扩展了 WeakMap API，WeakMaps 允许使用唯一的 Symbol 作为键。不过值得注意的是，通过 Symbol.for 创建的 Symbol 是不可以作为弱引用的，因为 Symbol.for 会在全局注册 Symbol，并支持在任何地方通过 Symbol.for 再次引用。
2) 新增四个通过副本修改数组的方法：toReversed()、toSorted()、toSpliced()、with()，
目前大多数的数组方法都是非破坏性的，当然也存在一些对原数组具有破坏性的方法，例如 reverse()、sort() 以及 splice() 。当我们想要使用这些方法又不想对原数组造成影响的话，通常需要先拷贝一份数组再调用相应的方法，由此可见，这种开发体验不友好的。因此在今年的 ECMAScript 2023 优化了开发体验，新增了相应的非破坏性方法。
关于更多 ECMAScript 2023 其他改动的完整信息，请参考官方文档，此处不再赘述：ECMAScript® 2023 Language Specification：https://tc39.es/ecma262/2023/
参考内容：
ES2023（ES14）新标准详解 - IT深客：https://www.itthink.tech/article/03e3d5cb-c817-41e9-918b-095fe6ace04b/d081bab2-1200-4fe3-a037-1abb8e6b8ba4#h2-SymbolsE58FAFE4BBA5E4BD9CE4B8BAweakE99B86E59088E79A84key
众望所归的 CSS 嵌套和 CSS 父选择器正式落地
今年除了 JavaScript 以外，CSS 也同样迎来了一系列新特性，这些特性不仅增强了样式和布局的能力，还提升了开发者的效率和用户体验。下面笔者仅介绍个人认为比较重要的两个 CSS 新特性，具体更多新特性的详情可以参考文章：【第3144期】2023年CSS新特性盘点
1) 原生 CSS 支持嵌套
CSS 支持嵌套一直是 Sass 中最受开发者喜爱的功能点之一，它允许让开发者在编写样式的时候更加整洁、内聚。据上一年 State of CSS 统计，CSS 嵌套是受访者认为 CSS 最需要补充的功能之一。
（图选自 https://2023.stateofcss.com/zh-Hans/usage/#what_do_you_use_css_for）
而在今年 CSS 2023 新特性中，原生 CSS 正式支持嵌套写法，在高版本浏览器中，无需依赖额外的编译器即可享受 Sass 嵌套语法，很大程度上优化了开发者体验，提高了CSS 的可读性和可维护性。
2) 各大浏览器正式支持 CSS 父选择器
除了 CSS 嵌套外，父选择器也是受访者认为 CSS 最需要补充的功能之一。简单来说，CSS 父选择器的作用能通过子元素选中其父元素。既然是万众期待且如此实用的选择器，为什么各大浏览器迟迟没有支持呢？
（图选自 https://2023.stateofcss.com/zh-Hans/usage/#what_do_you_use_css_for）
笔者总结答案主要是以下两个原因：
浏览器的渲染模式是以流的方式，一个元素接一个元素进入。因此当一个元素在浏览器渲染出来时，其父元素的样式计算已经完成并且也已经渲染好了。在此之后，通过子元素选择父元素并应用样式触发重绘时，需要对父元素和子元素都进行重新绘制，这样的计算对于当时的渲染引擎而言是昂贵的。
与其他选择器而言，父选择器触发重绘的性能开销很大，如果有一个父选择器，那将很容易成为低效率选择器中的新老大。
近几年浏览器的渲染引擎有了很大的改进，目前浏览器可以有效地确定哪些需要渲染或更新，而哪些不需要。因此在今年众望所归的父选择器 :has 也正式被各大浏览器所支持。
参考内容：
CSS 的父选择器:has()：https://www.w3cplus.com/css/css-parent-selector.html
CSS 原生嵌套语法来了！ - 知乎：https://zhuanlan.zhihu.com/p/603168988
1.2 前端框架：主流框架持续完善，黑马 Htmx 与 Qwik 异军突起
回顾 2023 年前端框架，最受欢迎的四大主流框架依旧是 React、Vue、Angular 和 Svelte。从 2023 年 NPM 包下载量来看，React 框架依旧一骑绝尘，遥遥领先。Vue 则处于第二的位置，而 Svelte 已连续两年超过 Angular，成为前端第三大最受欢迎的 UI 框架。
（图查询自 https://npm-stat.com/）
除了上述前端框架的四架马车以外，今年还有两个黑马框架正式发布 1.0 版本，他们分别是 Qwik 和 Bun，接下来让笔者带你们盘点 2023 年期间这些框架到底发生了什么值得回顾的重要事情吧。
React 2023：重构与转型
在 2023 年期间，React 官方整整一年都没有发布新的 release 版本，上一次发布 release 版本还是在 2022 年的 6月，而 React 19 也似乎遥遥无期，最近一次更新已经是在一年前了。那么今年 React 官方到底在忙些什么呢？
答案是将 RSC（React Server Component，服务端组件）接入当前 React 体系中，目前绝大部分前端开发者只是把 React 当作前端 view 库所使用，并不会直接使用 RSC 相关功能，因此 React 团队与 Next.js 团队进行合作，以React RSC 规范落地于 Next.js 框架内部。所以 React 需要由面向开发者的前端框架渐渐转型为支持面向上层框架的元框架。
早期，React 作为前端框架，为了满足广大开发者在 UI 开发的需求，所以绝大部分的面向开发者的改动都能在 React 官方文档中体现，因此开发者也能通过文档直观感受到 React 不断迭代。而今年更新优化绝大多数都是面向上层框架，例如一些面向上层框架的新特性以及重构优化，这些普通开发者日常很少使用。具体更多可阅读下面的文章：为什么React一年不发新版了？
与此同时，今年 React 团队引入了名为 Canary 版本的发布渠道，从而使其可以在新功能的设计接近完成时就可以选择使用这些功能，而不必等到它们发布为稳定版本，React 团队也是主要通过此方式为上层框架提供相应的 API 支持。
参考内容：
怎么理解RSC和Next.js的关系呢？-duidaima 堆代码：https://www.duidaima.com/Group/Topic/React/17987
Vue3 VaporMode：更少的运行时开销
在今年 VueConf 2023 中，尤大除了讲述 Vue 3.3 发布的一些新特性、VitePress 、VaporMode 以及 Vue 3.x 后续的一些规划。有关于 VueConf 更多的信息可以查看 Vue Mastery 发布的视频：https://www.youtube.com/watch?v=y-hN5Q_lb9A
而笔者则重点介绍一下尤大曾在 2023 新年展望中首次提到的 VaporMode。
1) VaporMode 是什么？
VaporMode 是 Vue3 受 Solid.js 启发新的编译模式。它不依赖于虚拟 DOM，而是更多地利用 Vue 的内置响应性系统。简而言之通过将代码编译为更高效的 JavaScript，减少运行时开销，以获取更好的页面性能。Vue 之所以支持实现与 Solid 类似的编译策略，是因为 Vue 与 Solid.js 具有类似的响应式系统，它们都通过使用代理的方式实现响应式，并具有基于读取的自动跟踪。
（图选自 https://blog.csdn.net/qiwoo_weekly/article/details/134432268）
2) VaporMode 的进展与规划
VaporMode 目前仍处于开发阶段，从 VueConf 2023 中可得知目前的进展与规划如下，具体更多介绍请观看上述提到的 Vue Conf 2023 视频进行了解，笔者在此处简单概括一下：
第一阶段：核心功能的运行时
这一阶段的主要重点是在 Vue 核心功能的运行时引入并支持 VaporMode，该阶段目标如下：
支持核心指令（v-on、v-if、v-for 等）和组件树。
验证性能假设。
与现有 SSR 输出的水合兼容性。
目前第一阶段已基本完成。
第二阶段：核心功能的编译器
这一阶段的主要重点是确保可以使用 Vue 模板或 JSX 并将其转换为运行时可以处理的内容，该阶段目标如下：
共享代码生成 IR（中间表示）
JSX AST / 模板 AST - IR - Vapor Mode 代码
第三阶段：集成
这一阶段的主要重点是两方面，一是 VaporMode 能够无需对当前的设置进行任何修改，可以无缝地融入现有的应用，降低接入成本；二是支持在组件级别进行选择性接入 VaporMode，以便于开发者可以根据需要灵活地使用 VaporMode，例如在性能关键的区域中使用，该阶段的目标如下：
对独立 Vapor 应用的工具支持
在现有应用中运行 Vapor 组件
Vapor 中运行 vDOM 组件
第四阶段：功能对等
在首次发布时，Vapor Mode 将仅提供基本的核心功能，而诸如<Transition />、<KeepAlive />、<Teleport />、Suspense 等辅助功能将在 Vue 团队完成前述目标后进行实现。
总结而言，尤大在会议中如此说道：“这个策略只是一个实验性的产品，并不一定会上线，更不会是破坏性的更新，将来会提供可选的编译模式提供给开发者进行自行选择”。VaporMode 新特性可以理解成 Vue 在性能和包体积缩减方面的进一步探索与发展，其灵活的采用策略在保持与现有特性的兼容性，为不同场景需要提供了不同编译选择。
参考内容：
即将到来的 Vue 3 “Vapor Mode”-CSDN博客：https://blog.csdn.net/qiwoo_weekly/article/details/134432268
Vue2 已迎来终局
随着 2023 年接近尾声， Vue2 也将在 2023 年 12 月 23 日到达它的生命周期的终点（EOL），目前 Vue2.7 是当前、同时也是最后一个 Vue2.x 的版本。Vue 2 的终止支持时间是 2023 年 12 月 31 日。在此之后，Vue 2 在已有的分发渠道 (各类 CDN 和包管理器) 中仍然可用，但不再进行更新，包括对安全问题和浏览器兼容性问题的修复等。
具体更多信息请阅读 Vue 官方声明：https://v2.vuejs.org/lts/
Svelte 4 正式发布：持续优化并铺垫未来
今年 6 月，Svelte4 正式发布，Svelte4 主要是一个维护版本，该版本提高了最低版本要求并加强了特点领域的设计，为未来的 Svelte 5 的发布奠定了基础。Svelte 4 的主要亮点在于包体积大小优化上，从原来的 10.6 MB 减少到 2.8 MB，降低约 75%。
除此以外，Svelte 宣布将在 Svelte 5 将引入新的响应式 API：runes。Runes 本质上是作用于 Svelte 编译器的特殊语法，通过 $state 可以将值定义为响应式，不仅可以在 Svelte 组件内使用，也可以在外部的 JavaScript 文件中使用，实现跨组件的状态共享。此外，Runes 还提供了运行时响应式 $derived 和 $effect 的语法。
从网上开发者做到一张代码对比图上看，Runes 设计思想上类似于 Vue Reactive Transform。
（图选自 Svelte 造了个“新轮子”—— runes - OSCHINA - 中文开源技术交流社区）
参考内容：
https://zhuanlan.zhihu.com/p/657630106
https://www.oschina.net/news/259069/svelte-5-api-runes
Angular 重磅回归
今年 5 月 4 日，Angular 16 正式发布，开发者预览版引入全新的 Angular 响应式模型和基于 Esbuild 的构建系统，并无显著的新特性，更像是一个“垫脚石”版本。而在 2023 年的 11 月 8 日，Angular 17 正式发布，该版本引入了许多重要的更新：
引入了可延迟的视图，将性能和开发者体验提升到新的高度。
内置控制流循环使运行速度在公共基准测试中提高了高达 90%。
混合渲染和客户端渲染的构建速度分别提高了87% 和 67%。
参考内容：
Htmx 意外走红：重新回到 ASP 时代？
在前后端分离和单页面应用（SPA）已经形成大局的 2023 年，却有一款基于动态服务器页面（ASP）思想的框架 htmx 意外走红。它在 2023 年 JavaScript 明星前端框架中排名第二，仅此 React。接下来就让笔者带大家了解一下 Htmx 究竟是何方神圣以及 Htmx 的爆火是否意味着前端要开历史的倒车重回 ASP 时代呢？
1) Htmx 是什么
htmx 是一款基于 ASP 思想的前端框架，也可以理解成增强型的 HTML。它允许开发者通过增强 HTML 的特写属性来实现页面的实时交互和动态更新，而不是编写大量的 JavaScript 代码，所以因其小巧的文件体积和能够与现有的服务端框架无缝集成而受到赞誉。Htmx 的实现原理是通过 AJAX、HTML5 和 WebSocket 等技术，将前端和后端的交互方式从传统的请求-响应模式转变为增量更新模式。更多具体的介绍可以参考文章 htmx-使HTML更强大 - 知乎，笔者在此不在赘述。（https://zhuanlan.zhihu.com/p/653008546）
2) Htmx 是传统思路的回归
如今，React、Vue 等前端主流框架使用的都是单页面应用（SPA），目前也是创建 Web 应用程序的主流方式，前后端采用 JSON 数据进行交互。
（图选自 More on HTMX – Back to the Future | Compositional IT）
而 Htmx 则是由服务端处理页面交互和响应，例如 UI 事件会被发送至服务端进行处理，并生成 html 本体返回客户端。
（图选自 More on HTMX – Back to the Future | Compositional IT）
但是笔者认为 Htmx 虽然有它的优点所在，但是在生产环境的使用上还是存在非常大的局限性：
由于需要向 HTML 代码中添加非常多的“增强属性”，HTML 会变得非常臃肿，可读性和可维护性会变得非常差，不适用于大型项目的开发。
目前 React、Vue 等 SSR 直出渲染已经能够具有非常好的首屏性能了，笔者认为服务端只需要做好首屏渲染就好了，所有渲染逻辑统一收归服务端渲染后返回 HTML 片段会造成更大的服务器压力。
总而言之，Htmx 的意外走红并不是 Web 应用开发模式开倒车的征兆，是各自适应场景不同，适合简单的页面，或者前端经验缺乏的人使用。
参考内容：
https://juejin.cn/post/7156507227669413895
https://zhuanlan.zhihu.com/p/653008546
Qwik 1.0 正式发布：不是水合合不起，而是可恢复更有性价比
除了上述框架以外，2023 年还有号称历史上第一个 O(1) 的前端 SSR 框架的 Qwik 正式发布 1.0 版本。Qwik 虽然是今年才正式发布 1.0 版本，但是它已经凭借其惊艳的性能数据，斩获 2022 年 JavaScript 明星项目的前端框架排行榜第二名，当时仅次于 React。
（图选自 2023 JavaScript Rising Stars）
1) 传统 SSR 框架的局限性
为了保证页面首屏可见的性能，对于动态页面一般会采用 SSR 的方式来优化首屏可见耗时。目前主流的支持 SSR 的框架，例如 react、vue 等，从用户请求到页面可交互需要经历以下四个阶段：
获取服务端渲染后直出的 HTML
浏览器下载页面所需要的所有 JS 资源
解析并执行 JS
构建出完整的渲染树，将渲染树和真实 DOM 相关联，并为 DOM 绑定相应的事件
（图选自 极致性能优化：前端SSR渲染利器Qwik.js）
2) Qwik 是如何做到的呢？
Qwik 虽然也是 SSR 框架，但是它采用提供一种无 hydartion 的更加优雅方案，称为 Resumability 可回复性的方案
服务端渲染时将所有必需的信息序列化成 HTML 模板，包括 WHAT（事件处理函数内容）、WHERE（哪些节点需要哪些事件处理函数）、APP_STATE（应用状态）和 FRAMEWORK_STATE（框架状态）。
依赖于事件冒泡来拦截所有事件进行全局处理，无需在特定 DOM 元素上单独绑定事件。
当用户点击时，通过全局事件委托的方式，动态加载点击函数并执行。
点击函数会触发视图更新，并动态加载渲染函数并执行，从而完成了恢复性渲染。
简而言之，Qwik 将 HTML 中序列化所有必需的信息，以及使用全局事件处理程序来拦截和处理事件，而不必显式将事件处理程序附加到特定的 DOM 元素上，这样可以避免的水合过程，并采用更加极致的懒加载策略和可恢复性操作，从而做到”直出即可用“的状态。
（图选自 极致性能优化：前端SSR渲染利器Qwik.js）
当然，任何框架的优势和劣势都不是绝对的。首先，Qwik 由于需要在服务端渲染时进行信息序列化操作，因此会给服务器带来更大的压力。其次，qwik 在触发用户行为时再惰性加载并执行响应的 JS 脚本，这样需要在用户触发交互时动态生成对应的事件处理函数进行执行，造成一定的交互响应上的延时。
参考内容：
https://km.woa.com/articles/show/559379?kmref=search&from_page=1&no=3
https://www.51cto.com/article/753555.html
1.3 前端基础建设：多种语言助力前端基建的持续发展
前端锈（Rust）化愈演愈烈
从 Github 2023 年度报告显示，Rust 增长率位于所有语言榜首，其年增长率到达 40%，并连续第八年被 2023 年 Stack Overflow 开发者调查评为最受赞赏的语言。
（图选自 Octoverse 2023: The state of open source | The State of the Octoverse）
从 StackOverFlow 2023 年度开发者报告也显示，超过 80% 的开发人员希望在明年继续使用它。
（图选自 Stack Overflow Developer Survey 2023）
由此可见，在 2023 年之间 Rust 受到了广大开发者的青睐，虽然整体使用率相较于其他语言较低，但是其增长势头非常迅猛，值得我们持续关注。
2)Rust 在前端基建已经崭露头角
回顾 2023 年前端基建相关的开源工具来看，这个预言仿佛在一步步接近现实，在前端基础建设领域不断出现 Rust 的身影
2022 年 10 月底，Next.js 发布了基于 Rust 的构建工具 Turbopack，因为性能数据非常惊艳，引起了一时的轰动。
2023 年 3 月 10 日，字节跳动发布了基于 Rust 的构建工具 Rspack 正式发布，经官方开发者验证可以给项目带来 5 ～ 10 倍的编译效率提升。
2023 年 10 月 5 日的 ViteConf 2023 线上大会中，Vue 作者尤雨溪也宣布计划使用 Rust 重构 Vite，替换掉原有的 Esbuild 和 Rollup，以获得更好的性能。
2023 年 12 月 12 日，基于 Rust 的代码检查工具 Oxlint 正式发布，Shopify 报告称其比 ESLint 快 50 - 100 倍，并可以随 CPU 核心数量不断扩展。
Rust 因为其出色的性能，在编译、打包构建等前端基建的方向所带来的性能数据提升令人震撼。在 JavaScript 性能提升挖掘缓慢的今天，不少前端基础建设框架/库的开发者为追求更高的性能开始逐渐将目光转向了 Rust。由此可以预测，Rust 工具将会更加深度地融入前端生态，说不定会掀起新一轮的前端基础建设浪潮，让我们拭目以待。
参考内容：
https://leerob.io/blog/rust
https://blog.csdn.net/dfc_dfc/article/details/135172646
https://mp.weixin.qq.com/s/6xxcUs-1RKg1124WHTffWw
前端界的卷王 Bun 1.0 正式发布
在前端基础建设方面，已经连续两年登顶 JavaScript 明星项目的 Bun 于今年 9 月 8 日正式发布 1.0 版本。Bun 不仅是一个专注性能与开发者体验的全新 JavaScript 运行时，还是一个转译器、构建工具、包管理器以及测试库的全能工具包，旨在无感替代现有的 JavaScript 运行时（Node.js 和 Deno），并成为浏览器外执行 JS 的主流环境，为用户带来性能和复杂性的提升的同时，以更好更简单的工具提高开发者的效率。
（图选自 2023 JavaScript Rising Stars）
笔者认为其最大的两个特点在于性能和便捷性上：
1)性能
Bun 比 Node.js 和 Deno 更快，尤其是在启动时间和运行时性能方面。Bun 的写入速度比 Node.js 和 Deno 快三倍，在读取文件的速度也快将近三倍。此外，Bun 的处理并发链接的速度也明显优于 Node.js 和 Deno。有关三者更多的性能方面的比较数据请参考官方 Github 仓库中的介绍，此处不再赘述。https://github.com/oven-sh/bun
之所以 Bun 在性能上会有如此优异的表现，主要是因为作者在实现上对方方面面进行了精细的优化，特别值得提及的两个优化点是：一是 Bun 使用性能更好的 Zig 和 C++ 实现了 Node 中使用 JavaScript 编写的重要内置库，而且 Zip 支持进行低级内存控制和消除隐藏控制流，性能优化更好。二是 Bun 与使用基于 V8 引擎编写的 Node 和 Deno 不同，它使用的是 JavaScriptCore 引擎，该引擎在性能上优于 V8 引擎。
2)便捷性
随着 JavaScript 不断发展，各种工具被逐渐添加进来，JavaScript 的工具链变得越来越庞大与复杂，但是目前前端并没有统一的工具包，使用时需要开发者手动添加各种工具以满足开发编译需要。而 Bun 设计初衷除了性能优化外，还希望作为一个全能的工具包的形式，消除 JavaScript 工具链的复杂性，为前端开发者提供一个开箱即用的开发体验。
参考内容：
https://dev.to/builderio/a-first-look-at-bun-is-it-really-3x-faster-than-nodejs-and-deno-45od
https://www.wbolt.com/bun-vs-node-vs-deno.html
https://zhuanlan.zhihu.com/p/657868875
1.4 Chrome 浏览器：加强对用户数据安全的保护
将全面禁止第三方 Cookie
早在前两年，Chrome 已经计划全面弃用第三方 Cookie 了，但是如果直接弃用很可能会导致大量网站功能无法正常使用。而在今年 Chrome 更新的 113 和 114 版本中，Chrome 稳定推出了 Cookie 第一方集和 Cookie 独立分区两项功能，并随即在今年 10月 11 日于 Chrome 的官方博客上宣布计划从 2024 年第一季度开始对 1% 的用户禁用第三方 Cookie，并在第三季度将禁用范围扩大至 100%。接下来笔者将对此进行解读一下。
（图选自 https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct?hl=zh-cn）
1) 第三方 Cookie 的作用与风险
首先 Cookie 是一种浏览器保存在用户电脑的持久化数据，通常用于帮助网站记住用户相关的信息。所谓的第三方 Cookie 是指用户当前访问的网站域名之外的其他域名下通过 Cookie 的形式所存储的内容数据，简而言之，与当前访问的网站非同源的 Cookie。这个也在我们的生活中非常的常见。例如，第三方 Cookie 允许记录用户在不同网站上的行为，以便于提供个性化广告和内容，利用第三方 Cookie 支持跨网站追踪的能力，让广告商能够根据用户的喜欢和习惯推送更加符合其口味的广告。
但是由于第三方 Cookie 所记录的信息允许被携带其他网站，因此这样无形之中就有用户隐私被泄露的风险。这种担忧不仅来自用户，也来自于法规如如欧盟的通用数据保护条例（GDPR）和加州消费者隐私法案（CCPA）。因此目前 Safari、Mozilla 等其实已经推行禁用第三方 Cookie 的措施了，而如今迫于隐私泄露的压力，第三方 Cookie 不得不逐步退出历史舞台。
2) Chrome 提供的解决方案
首先 Chrome 114 版本提供 Cookie 独立分区（CHIPS）的能力，它允许开发者将 Cookie 按照分区进行存储，每一个顶级域名都有独立的 Cookie 存储分区，因此顶级域的页面可以访问其通过 iframe 嵌入的网站所存储到独立分区中的 Cookie，而不同顶级域之间的 Cookie 存储分区并不互通。
（图选自 https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct?hl=zh-cn）
再者 Chrome 提供 Cookie 第一方集（First-Party Sets）用于解决自定义 Cookie 集合的问题。通常而言，许多公司或者组织都会使用多个域名，虽然它们的域名不同源，但是按道理来讲都是属于第一方的，此时开发者可以将需要共享 Cookie 的不同域名放到一个集合中提交给 Chrome 进行审核，审核通过后便可以通过 Chrome 提供的特殊方式读取这些域名下共享的 Cookie。
（图选自 https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct?hl=zh-cn）
更多详细的说明可以阅读下面这篇文章：Cookie 的访问方式可能要有大变化了！
内容参考：
https://juejin.cn/post/7313414896783769609
将全面禁用 Manifest V2 扩展
Manifest V2 是 Chrome 早期制定的、用于开发浏览器扩展的一套技术标准，多年来已经成为行业标准。但随着人们对数据、隐私安全的重视，其允许扩展修改用户请求、权限模型较为简单、CSP 实现较为宽松等安全隐患也逐渐暴露出来。
Manifest V3 标准在 2018 年发布以来，相较于 V2 版本主要做了如下优化：
Service Workers 替代 Background Pages
Manifest V3 引入了 Service Workers 来替代 Background Pages。Service Workers 是一种可以在后台运行的 JavaScript Worker，它不依赖于任何特定的页面，这使得它在处理后台任务时更加高效和节能。此外，Service Workers 在处理完成后会自动停止，从而减少了扩展对系统资源的占用。
声明式 Content Security Policy
Manifest V3 引入了声明式 Content Security Policy (CSP)。这意味着扩展开发者需要在 manifest 文件中明确声明扩展需要访问的资源，从而减少了恶意代码的攻击面。
引入更高级的权限模型
Manifest V3 引入了一种新的权限模型，它允许用户在安装扩展时选择授予扩展哪些权限，从而提高了用户的隐私和安全性。
限制远程代码执行
Manifest V3 禁止扩展执行远程代码，所有的代码都必须包含在扩展的包中。这可以防止扩展被用来执行恶意代码。
引入 Declarative Net Request API
Manifest V3 引入了 Declarative Net Request API 来替代 webRequest API。Declarative Net Request API 允许扩展在网络请求被发送前对其进行修改，但它不允许扩展访问请求的详细信息，从而提高了用户的隐私。
长期以来，Chrome 为兼容历史扩展，一直保持两套标准并存。然而在 2023 年，Chrome 终于宣布将于 24 年 6月份全面禁用 V2 扩展，这将大大提高 Chrome 数据和隐私的安全性。
1.5 低代码：持续完善的低代码引擎开源社区
2023 年低代码仍然是前端领域非常火热的话题。根据爱分析《2023 低代码厂商全景报告》显示，2023年中国低代码市场规模为 50.2 亿元人民币，年增速为 39.9%，行业发展迅猛，同时低代码开始向更深入、更垂直的场景和应用渗透，要求低代码技术的发展趋势倾向于满足行业的需求。因此基于低代码引擎底座至上实现垂类定制的低代码解决方案逐渐成为了社区的基本共识。继 2022 年阿里开源了 lowcode-engine 后，网易和华为在今年也分别相继开源了 Tango 低代码引擎和 TinyEngine 低代码引擎，进一步丰富了低代码的社区生态。在技术实现上，前者基于源代码驱动实现，后者在低代码底层能力上集成了人工智能，接下来让我们一起看看它们有哪些亮点与不足吧。
基于源代码驱动低代码引擎的探索
今年 8 月网易云音乐前端技术团队开源了一款基于源代码驱动实现的低代码引擎 Tango。和现有基于 DSL 编排的低代码实现不一样的是，Tango 低代码引擎能够提供源代码进、源代码出的可视化搭建能力。
何为源代码驱动？
Tango 低代码引擎在设计上摒弃了私有搭建协议和 DSL，而是借助 ESTree 规范和源码 AST 转换。用户在低代码平台的搭建操作本质上都是对源码 AST 进行遍历并修改，进而将修改后的 AST 重新生成为代码，将代码同步给在线沙箱执行，从而做到了输入和输出都是代码，且不包含任何私有的中间产物。
（图选自 Tango 低代码引擎官方 Github 仓库）
源代码驱动的好处
对于源代码驱动的好处，笔者认为主要有两点：
与传统的基于 Schema 驱动的低代码引擎相比，组件开发与拓展等都无需依赖于私有协议和 DSL，灵活性较高。
源代码驱动的低代码引擎的输入和输出都是代码，支持双向转码，解决了二次开发不同步的问题，使其更适合开发同学使用。
源代码驱动的不足
笔者认为源代码驱动在使用上有点类似于远古时期的 DreamWeaver，这种方式虽然可以不依赖私有协议，但不同语言的 AST 是有差异的，如果需要实现跨端，不同语言之间的 AST 转换相对来说就比较困难了。
内容参考：
https://zhuanlan.zhihu.com/p/653492974
大模型与低代码平台结合的尝试
随着今年大模型的爆火与迅猛发展，大模型与低代码引擎结合有着非常大的潜力。在今年 9 月华为开源了一款支持使用大模型（文心一言）辅助开发低代码引擎 TinyEngine。无独有偶，腾讯的无极低代码平台以及百度的爱速搭在今年更早的时候已经尝试在低代码平台中接入大模型辅助开发了。接下来就让我们一起看看，大模型与低代码引擎究竟能够碰撞出什么火花吧。
大模型在低代码平台的应用场景
低代码平台中并不是所有场景都适合使用大模型，例如在单次拖拽组件的场景，试想一下，原本只需要简单动动手指的功夫，现在需要敲一段指令让大模型理解你的诉求并完成操作，这效率明显更低。
笔者根据现有的已接入大模型的低代码平台整理了在低代码平台中适合使用大模型的应用场景：
文档问答助手：根据用户输入检索相关文档段落和问题，然后让大模型回答，这也是目前大模型最常见的应用，利用大模型优秀的信息检索和总结能力，在一定程度可以更快地解决使用低代码平台上的一些问题，提高效率。
代码辅助生成：在低代码平台中需要编写少量代码实现功能的 LessCode，可以通过大模型辅助编写或者直接命令生成，降低低代码开发平台的使用门槛。例如在无极的 LessCode 部分，通常需要学习无极的文档中的 API 来 “获取页面的状态数据” 或者 “调用无极的工具方法”，此时使用大模型根据你的要求结合文档自动生成，是不是世界瞬间清爽了很多。
大模型在低代码平台落地应用的问题
受限于目前大模型的限制，目前大模型在低代码平台中落地应用会存在以下问题：
幻觉问题：目前幻觉问题是大模型应用最大的拦路虎，简而言之，就是捏造事实、推理谬误、胡说八道，这个是由于大模型训练时的数据压缩（data compression）和不一致性（inconsistency）所导致的，具体描述可参考这篇文章，此处就不再赘述了。https://juejin.cn/post/7292814071929667603
Token 限制：Token 限制也是目前大模型使用中最头疼的问题之一，目前大部分是限制 2K-4K，这是在训练时决定的，不好扩展，只能拆分 Prompts。
安全问题：由于数据具有安全性问题，大多数情况下无法直接将数据交给外部的大模型使用。
内容参考：
https://juejin.cn/post/7280926568854667299?from=search-suggest
https://cloud.tencent.com/developer/article/2305269
https://zhuanlan.zhihu.com/p/661550285
1.6 D2C：C2D2C 亮相，大模型赋能 D2C 未来可期
继 2017 年谷歌发布了一篇关于 pix2Code 的论文以来，设计稿生成代码（Design to Code，D2C）一直都是前端领域比较热门的探索性话题。D2C 的关键点在于如何准确识别组件和还原布局，传统的设计稿生成代码主要是利用图像识别、标注信息、深度学习算法和页面布局算法等方式来实现，例如淘宝的 ImgCook、光速软件的 CodeFun 等。2023 年业界出现了和传统解决方案不一样的解决思路，比如利用代码转设计稿、再到设计稿转代码（C2D2C）来实现组件的准确识别，以及利用大模型的泛化能力解决传统 D2C 的局限性。
C2D2C：精准识别组件
传统 D2C 如果想要做到精准识别组件，利用图像识别和深度学习难以实现，一般都需要设计稿足够规范或包含足够多的标注信息，而 C2D2C 就是为了解决传统 D2C 在组件识别上的局限性。所谓 C2D2C，就是开发同学先用现有 UI 组件库转换成设计组件并导入到设计平台作为物料，然后设计同学使用这些设计组件物料输出设计稿，最后设计稿再转成基于 UI 组件库的代码。由于设计稿和代码使用的是同一套设计系统，设计稿中的组件和最终代码中的组件是一一映射的关系，因此无需进行标注就可以实现组件的精准识别。字节的 Semi D2C、腾讯的如意助手、网易的海豹助手都是在 2023 年发布的 C2D2C 的具体产品。
（图选自 网易云音乐设计协同演进之路）
大模型赋能 D2C 未来可期
这几年 D2C 的发展比较迅速，但前端社区并没有出现一个非常惊艳的独角兽项目，主要原因可能是传统的 D2C 解决方案通用性不足，对于业务需求和设计稿的各种复杂情况具有局限性：
对设计稿规范依赖程度高：传统 D2C 生成代码依赖于设计师按照特定的规范来创建设计稿，例如标注等。
布局算法的局限性：任何一种布局算法都存在局限性，对边界情况的处理能力不足，想要生成布局合理的代码依赖非常复杂的布局算法。
生成的代码语义化和可维护性较低。
随着今年大模型的迅猛发展以及其优秀的泛化能力，大模型为前端设计稿生成代码注入了新的活力：可以利用大模型辅助设计稿生成代码：
利用大模型的优秀的上下文理解能力，将 DSL 中元素绝对位置推断出合理的 Flex 布局，无需实现复杂的布局算法。
利用大模型擅长处理代码的能力，可以通过页面布局的 DSL 生成可读性和可维护性更高的代码。
而就在 2023 年 10 月 12 日 Builder.io 推出的 Visual Colilot 就是一款这样的商用产品，官方称可以将 Figma 设计稿一键生成高质量、可读性和可维护性较高的多种框架的代码，支持自定义组件，提供了二次编辑的低代码平台。
不过经过笔者尝试，将一张未经过任何处理的设计稿使用 Visual Colipot 生成的代码并不理想，可读性和可维护性也没有那么高，甚至会有文字识别成图片的情况，没有达到直接可用的状态。但是毋庸置疑的是大模型确实为设计稿生成代码提供了一种新的思路与解决方案，相信随着大模型识别能力和生成能力的不断增强，大模型赋能 D2C 未来可期。
1.7 大模型：大模型应用能力持续完善与落地
自 2022 年底 OpenAI 发布 ChatGPT 后，因为其卓越的对话能力和广泛的应用潜力，引起了世界范围内广泛关注和热烈讨论，也迅速掀起了一场人工智能变革浪潮。从 Github 2023 年度报告显示，2023 年 Github 上 AIGC 相关项目的数量呈现出爆发式增长，这得益于今年大模型的迅猛发展与其泛化能力。
（图选自 Octoverse 2023: The state of open source | The State of the Octoverse）
接下来让我们一起回顾被称为大模型元年的 2023 年期间，大模型有哪些比较重要的发展与落地应用吧。
大模型支持返回结构化内容
默认情况下，大模型生成的内容都是非结构化的文本数据，但是开发者通常在编程的过程中使用的大多数都是结构化的数据，所以开发者需要自行对大模型生成的内容进行文本匹配等预处理操作，在通过 API 方式使用并没有那么便捷。TypeChat 官方仓库如下：https://github.com/microsoft/TypeChat
而今年 7 月 10 日，C# 和 TypeScript 首席开发人员、微软技术研究员 Anders Hejlsberg 组成的团队于 7 月 20 日发布了 TypeChat。它允许将大模型返回的非结构化数据转化为结构化数据并确保其满足模式约束，并提供自动纠错的机制，在一定程度上解决了大模型生成的内容存在较大的随机性和不稳定性。
TypeChat 主要特点如下：
支持返回结果类型定义：TypeChat 使用 TypeScript 类型作为 Schema 约束 大模型返回符合 TypeScript 类型的 JSON 格式数据，
自动纠错机制：TypeChat 内置自动纠错的能力，会通过 Typescript 来验证输出结果并进行循环纠正。
有趣的是，在今年 11 月 7 日 OpenAI 开发者大会中，也宣布 GPT 支持返回 JSON 格式的响应数据：在调用 API 时在 message 中提供 JSON 数据的相关描述，并设置 response_format={"type": "json_object"}，GPT 则会根据描述返回相应的结构化数据，相当于官方层面支持了 Typechat 能力。这也侧面证明 TypeChat 是正确之道。
当 Code Review 遇见大模型
在大模型应用于开发者赋能方面，除了使用大模型编程辅助工具外，还可以为开发者的研发流程中的一些环节进行赋能，例如 CodeReview、生成单测等。
（图选自 基于大模型 + 知识库的 Code Review 实践）
今年 10 月 11 日，字节前端 ByteFE 团队发布了一篇基于大模型 + 知识库的 CodeReview 实践的文章。该文章提出，预先搭建一个包含公司内部基础框架、业务专用系统和业务专业术语等领域知识的矢量知识库，将大模型生成的 代码 summary 在矢量数据库中匹配获取相关知识，最后再与被审查的代码生成最终的 prompt 并提交给大模型处理。通过这种方式可以解决以往大模型 CodeReview 因缺乏对提交代码领域知识的理解而无法发现和识别业务逻辑中有意义的错误、CR 建议不尽如人意等问题。
更多的大模型结合知识库进行 CodeReview 的具体实践的细节可以参考文章：基于大模型 + 知识库的 Code Review 实践
ChatGPT 官方推出 Prompt 工程指南
一直以来，关于如何写好 prompt，网上有各类教程，但是一直缺乏一份官方版本，12月15日，OpenAI在他们他们的文档中上线了Prompt engineering（提示词指南），这也是从官方层面推出的权威且有效的 prompt 标准文档，该份文档提出了6条大的原则：
1. Write clear instructions（写出清晰的指令）
2.Provide reference text（提供参考文本）
3. Split complex tasks into simpler subtasks（将复杂的任务拆分为更简单的子任务）
4. Give the model time to "think"（给模型时间“思考”）
5. Use external tools（使用外部工具）
6. Test changes systematically（系统地测试变更）
关于这六条原则的细化解读和示例说明可以参考：OpenAI的官方Prompt工程指南详解 - 看这一篇真的就够了
1.8 跨端：鸿蒙应用开发为跨端带来新变化
在今年华为首次公开了 HarmonyOS NEXT 的概念，HarmonyOS NEXT 与之前的版本不同，HarmonyOS NEXT 可谓是与 Android 彻底切割了，简而言之，在该系统上无法再运行 Android 应用，只能使用由 ArkTS 编程语言开发的原生 HarmonyOS 应用。因此笔者接下来会介绍一下华为新推出的 HarmonyOS NEXT 的普及会对跨端领域会带来什么样的影响吧。
1) 鸿蒙应用开发
在今年首次公开的 HarmonyOS NEXT 系统已经不再是过去被广大用户所调侃的“套壳 Android”，它是完全基于全自研内核，去掉了传统的 AOSP 代码，仅支持鸿蒙内核和鸿蒙系统的应用减少了 40% 的冗余代码，使系统的流畅度、能效、纯净安全特性大为提升，而这些性能上的提升得益于 HarmonyOS NEXT 系统遥遥领先的设计理念：
一次开发，多端部署。
可分可合，自由流转。
统一生态、原生智能
具体关于这三个设计理念更加详细的描述可以参考这篇文章，笔者在此就不再赘述：华为鸿蒙Next,这次真的要遥遥领先了：https://juejin.cn/post/7303398827225415699#heading-6。
鸿蒙系统并为此配套了从开发套件 HUAWEI DevEco Studio（IDE）、开发框架 ArkUI、方舟编译器 ArkCompiler、开发语言 ArkTs 以及编译构建工具 HUAWEI DevEco Hvigor。笔者认为有意思的是，ArkUI 框架提供基于 JS 扩展的类 Web 开发范式和基于 ArkTs 的声明式开发范式。
前者相信前端开发者的非常熟悉了，所以笔者简单介绍一下后者，ArkTs 是基于 TypeScript 进行二次封装，适配 ArkUI 框架，对 TS 的动态类型特性施加更严格的约束，同时引入静态类型、拓展了声明式 UI、状态管理等相应的能力。因此我们可以得知，ArkTs 是 TypeScript 的超集，在保留 TypeScript 基本语法风格的基础上，提供更加强大的功能。
笔者认为两者都对前端开发者挺友好的，看来华为除了争取移动端开发者 更想把前端开发者争取进来共建生态。
2)对跨端的影响
HarmonyOS NEXT 的出现无疑意味着了一个新的操作系统的诞生，随着后续 HarmonyOS NEXT 的推广，安卓、IOS、鸿蒙三分天下的局面指日可待，那么软件的研发成本肯定会上升，那么跨端的方案相信未来也会成为越来越多开发者的首选。目前鸿蒙除了有独立自主的开发UI框架 ArkTS 外，也兼容了市面上主流的跨平台方案，比如 flutter、RN、Weex 等。
近些年来，移动端和前端的技术栈模式在趋同，目前移动端的UI框架都在向前端靠拢，例如 flutter、weex 都是朝前端的“声明式”方式靠拢，目前应用层开发移动端和前端的界限正在慢慢模糊。而鸿蒙的 ArkTS，更是前端开发者最熟悉的 js 语言切入战场，天然降低的前端开发者的入场成本，ArkUI更是在底层设计上兼容了前端团队，提供了基于 ArkTS 的声明式开发范式和基于 JS 扩展的类 Web 开发范式。相信也会对大前端的发展带来新的机遇与挑战。
内容参考：
https://juejin.cn/post/7303398827225415699#heading-6。
1.9 WASM: 未来将与更多语言和场景结合
随着互联网的发展，越来越多的应用程序借助 JavaScript 迁移到了 Web 上，但人们也注意到下载、解析、编译 JavaScript 会消耗大量时间，导致页面加载时间过长，最终导致用户流失。
为了解决这些问题，Mozilla 的工程师 Alon Zakai 在 2012 年提出了 Asm.js，经过几年的发展，终于在 2015 年进化为 WebAssembly。
WebAssembly（缩写为 Wasm）是一种用于基于堆栈的虚拟机的二进制指令格式。 Wasm 被设计为编程语言的可移植编译目标，支持在 Web 上部署客户端和服务器应用程序。
到 2024 年，Wasm 走过了12个年头，Wasm 已经在广泛的环境中使用，从浏览器到边缘和 IoT，甚至到云端。
从使用何种语言进行Wasm的开发统计上可以看到，Rust 依然是排名第一的做为 Wasm 的开发语言，随着 Rust 广泛用于 devops 流程工具，2024 年毫无疑问依然会延续这种趋势。
（图选自：The State of WebAssembly 2023）
从 Wasm 的特性提案中，我们能看到线程、垃圾收集和异常处理在去年的结果中均名列前茅，并且这三者都处于提案生命周期的实施（第 3 阶段）或标准化（第 4 阶段）。这意味着它们已准备好使用，并且接近完成。
（图选自：The State of WebAssembly 2023）
另外，WASI（WebAssembly 系统接口），最受关注的是 I/O 提案（如 HTTP、文件系统），可见，创建 WebAssembly 模块与外界通信的标准方式是当务之急。
可以预见接下来会有更多场景，更多语言接入对 Wasm 的支持跟使用，而各个领域的不同开发者碰撞，也会让 Wasm 的标准趋于全面以及更加具备普适性。而 Wasm 作为 AI 边沿计算的总要解决手段，相信2024年也会有结合实际 AI 业务场景的 Wasm 应用诞生。
1.10 音视频：传统编解码与 AI 编解码并驾齐驱
音视频编码技术虽然不与前端直接相关，但是作为前端依赖的底层能力，还是值得我们前端同学保持关注一下其在 2023 年间的一些发展趋势的。
据《2024 音视频技术发展报告》显示，在音视频行业中，从事 RTC/实时通信技术和音视频编解码领域的研发占比最高。
在传统音视频编解码领域中，H.264/AVC 和 H.265/HEVC 仍然时国内外在视频编解码上的首要选择。而 H.266/VVC 目前软件编码复杂度较高，导致其在实时通信应用场景较难实现，因此 H.266/VVC硬件化是必然趋势。预测在未来两年内，H.265/HEVC 仍然是主导选择，H.264/AVC 使用份额呈现萎缩趋势，AV1 在国内外的使用情况都会呈现增长趋势。
（图选自 重磅首发｜腾讯云音视频联合LVS发布《2024音视频技术发展报告》-腾讯云开发者社区-腾讯云）
此外，随着今年大模型的迅猛发展，AI 编解码受到越来越多的关注。AI 编解码打破传统框架，采用机器学习的方式，相较于传统方案可以获得压缩率的大幅度提升，目前 AI Codec 的 SOTA 方案的压缩性能上已经超越了 H.266/VVC，展现了其非常强大的技术潜力，但是由于其在按乘加数计的运算复杂度也有较大增，从压缩率与复杂度折中的角度看，并没有达到惊艳的效果，以及非标准的原因，目前还不足以打破现有生态获得大规模推广。从《2024 音视频技术发展报告》中显示，复杂度包括延时、计算量、显存等问题是AI 编解码目前存在最大挑战，其次是泛化、特化、标准化等问题。
（图选自 重磅首发｜腾讯云音视频联合LVS发布《2024音视频技术发展报告》-腾讯云开发者社区-腾讯云）
因此传统和基于 AI 的编码技术会在相当长的一段时间里呈现出并行发展的态势，据专家预测，未来 AI 编码的道路存在两条，一是通用 AI 芯片做编解码，借助高效芯片在软件层面可实现高效率，而这个道路向前走的关键在于算法的优化程度以及 AI 芯片的普及程度。二是与传统方式一致，借助专有硬件实现高效编解码，但这条道路则非常坎坷与漫长。
未来是多编码标准共存的时代，到底是 H.265/HEVC 继续稳定发展，还是 AV1 后来居上，亦或是 AI 编解码突出重围，让我们拭目以待。
内容参考：
https://www.sgpjbg.com/baogao/146973.html
02
技术的发展是永无止境的，脚踏实地才能遥望星空，回顾 2023 年的前端技术也是为了更好地展望未来的发展趋势，据此我们可以对 2024 年前端技术不同细分的领域方面作出一些展望：
2.1 大模型持续为前端赋能
今年大模型的兴起为前端多个领域都注入了新的活力。随着明年大模型的不断发展与进化，相信大模型能够在前端越来越多的领域中落地并持续赋能。例如，在 D2C 领域，随着大模型识别推理和内容生成能力的不断提高，其根据设计稿所生成的代码的质量会更上一层楼，因此大模型在设计稿生成代码上的应用将会越来越广泛；低代码、AI 辅助开发等领域相信也会有更多地应用场景。作为开发者我们也应当主动去拥抱并思考如何更好地利用大模型进行赋能。
2.2 拥抱 TypeScript 是前端语言与标准的主旋律
TypeScript 虽然会带来一定的复杂度，但是其所提供的类型系统能够大幅度提高项目的健壮性和可维护性，在绝大部分前端开发场景下，都是利大于弊的。因此拥抱 TypeScript 依旧是未来前端语言与标准的发展大趋势，随着 TypeScript 的不断升级和优化以及前端基建能力不断完善，相信它会给我们带来更好的开发体验。
2.3 探索更好服务端渲染是前端框架的大势所趋
在前端框架领域，React、Vue、Svelte 和 Angular 这四大框架依旧会是明年的前端框架的主流。无论是从今年的主流框架的发展趋势（React Service Component、Vue VaporMode 等），还是黑马无水合 SSR 的 Qwik、重归 ASP 思想的 Htmx 以及前两年兴起的孤岛架构 Astro ，服务端渲染模式应当是明年前端框架的主战场了，其通常具有更快地页面首屏可见，用户体验更好。究竟明年是否会有更好的服务端渲染模式的诞生，也让我们拭目以待。
2.4 Rust 是前端基础建设的未来
由于 Rust 其优异的性能使得其成为前端基建的新宠，在 2023 年期间陆陆续续有基于 Rust 的前端基建工具的诞生，以及越来越多的前端基建工具的开发者宣布使用 Rust 重构。相信随着明年 Rust 在前端的生态不断完善和推广，Rust 将会成为前端基础建设的主流，而且随着 Rust 允许编译成更高质量的 WebAssembly 代码，在浏览器上也会渐渐出现其的身影吧。
2.5 鸿蒙入局，跨端三分天下格局指日可待
2023 年鸿蒙褪去的 “Android 套皮“的名号，推出了一个新的操作系统 HarmonyOS NEXT。明年随着华为手机的持有量上升以及 HarmonyOS NEXT 的铺量，软件需要适配的操作系统的增加所带来的研发成本的上升，跨端的方案相信未来也会成为越来越多开发者的首选。而鸿蒙应用的开发语言 ArkTS 选择前端开发者最熟悉的语言和开发范式作为基底，这无疑对大前端而言，既是机遇也是挑战吧。
总而言之，时代在不断进步，技术也在不断进步，而我们也需要不断地进步！
参考资料
https://juejin.cn/post/7309016658814189579?searchId=2023122711510148E406B52912BF8B6738#heading-5
https://juejin.cn/post/7316592832189300746?searchId=2023122711510148E406B52912BF8B6738#heading-0
其余参考资源详见各部分内容中的内容参考部分
鸣谢
感谢 owenlai、kasswang、averyhuang、chairlencai、nicolasxiao、clintlin、ziyanou 等团队内的小伙伴对本文的指导与修改。
分享抽龙年红包封面！！转发本篇文章就能随机获得以下封面 1 个！限量100个，周三中午12点开奖！
📢📢欢迎加入腾讯云开发者社群，社群专享券、大咖交流圈、第一手活动通知、限量鹅厂周边等你来~