2023年已如白驹过隙般过去。虽然在2023年的前端大舞台上并没有出现革命性的明星项目，但在各个细分的技术领域都有一定的拓展与深耕，而且2023年AI大模型的迅猛发展也为前端领域注入了活力，接下来让我们一起乘坐时光机重回2023，盘点2023年在前端行业发生的哪些重要的事情。
●首先在被誉为大模型元年的今年，大模型的应用能力持续完善，并逐渐开始在前端多个领域中落地。
●在前端语言与标准领域，今年JavaScript和CSS都有一些新的变化，在TypeScript已成为前端项目标配的如今，今年社区为何频频出现了不一致的声音？
●在前端框架领域，前端框架的四家马车React、Vue、Svelte和Angular继续领跑，它们都在按照自己的特色不断发展与进步。此外Qwik和Htmx在今年也广受前端社区喜爱，成为年度前端框架的黑马。
●在前端基础建设领域，Rust在前端的影响力越来越大：基于Rust的构建工具Rspack和代码检查工具Oxlint正式发布、Vite官方也正式宣布计划使用Rust重构Vite，替换掉原有的Esbuild和Rollup。此外，前端全能工具包Bun正式发布1.0版本，成为JavaScript年度明星项目。
●在低代码领域，低代码社区建设持续完善，基于源代码驱动和与大模型结合的低代码引擎于今年首次亮相。
●在D2C领域，出现了C2D2C这个新的解决方案，大模型为D2C赋能未来可期。
●在跨端领域，鸿蒙应用的异军突起为跨端领域开辟了新天地。
2023技术年度回顾1、语言与标准：CSS、ES和TS语法持续完善，社区竟现反TS声音
根据StackOverflow2023年度流行语言报告中统计显示，前端三剑客（HTML/CSS/JavaScript）依然位居榜首。而JavaScript已连续11年成为最流行的编程语言，而TypeScript也上升到第五的位置。整体而言，前端社区依旧充满朝气与活力。接下来让我们回顾一下2023年前端在语言与标准的领域上有哪些变化吧。
（图选自）
已成前端项目标配的TypeScript社区竟现抛弃呼声？
近年来，由于TypeScript提供的类型安全性、更好的工具支持以及与JavaScript生态系统的兼容性，它所带来的对代码质量和可维护性方面的价值已被前端社区所认可，目前已经成为开发Web应用程序的主要编程语言之一。从Github2023年度报告显示，今年TypeScript首次超过Java，成为GitHub上OSS项目中第三大最受欢迎的语言，其用户群体增长了37%。
1)TypeScript5.0：对包体积及构建速度进行全面优化
今年3月16日TypeScript5.0正式发布，该版本更新了许多令人激动的新特性，例如支持全新的装饰器、extends支持多配置文件、引入const类型参数等。笔者认为TypeScript5.0最大提升应该是在一直令人诟病的包体积大小和编译构建速度上的优化。
首先，TypeScript从命名空间转移到了模块中，这使我们能够利用现代构建工具来执行优化，如作用域提升，此外还删除了一些废弃的代码。优化后，TypeScript5.0相较于TypeScript4.9，包体积从约63.8MB减少到约37.4MB，降低了约42%。
（数据与图选自）
其次，TypeScript5.0还对代码的数据结构以及算法实现上进行优化，例如TypeScript5.0会现有对一些常用的机制进行了缓存，以便在编译操作之间重复使用。TypeScript5.0相较于TypeScript4.9编译速度上有着明显的提升。
（图表选自）
2)TypeScript5.2：使用using关键字进行资源管理
在一些编程语言中，比如C#，使用using关键字可以确保在使用完资源后，会自动释放这些资源。然而，在JavaScript中，开发者需要手动释放一些资源，比如打开的文件、数据库连接等。这就导致了在代码中需要显式地处理资源的释放，容易出现忘记释放、异常时未能释放等情况。
而TypeScript5.2新增的using关键字，配合Symbol.dispose一起使用，能很好的解决这个问题。
使用using前：不管程序是否发生异常，都需要在手动关闭文件句柄
import{open}from"node:fs/promises";letfilehandle;try{filehandle=awaitopen("thefile.txt","r");}finally{awaitfilehandle.close();
使用using后：离开作用域后会自动释放文件句柄
import{open}from"node:fs/promises";constgetFileHandle=async(path:string)=>{constfilehandle=awaitopen(path,"r");return{filehandle,[Symbol.asyncDispose]:async()=>{awaitfilehandle.close();},
awaitusingfile=getFileHandle("thefile.txt");
3)反对TypeScript的声音
尽管目前TypeScript如日中天，取得了前所未有的成功。然而，在今年8月份，RubyonRails的创建者DavidHeinemeierHansson（DHH）从即将发布的Turbo框架第8版中删除了TypeScript，并发文称“通过添加微不足道的类型技巧，让我的开发体验变得更加糟糕，而且频繁引发很多困扰。本应简单的事情反而变得很困难。”
早在2020年，Deno团队已经开始在Deno内部代码抛弃TypeScript，当时Deno团队给出的理由如下：
●在变更文件时，TypeScript导致连续编译过程变得非常缓慢。
●在创建Deno可执行文件以及面向用户的API源文件时，TypeScript结构会引发一系列运行时性能问题。
总结而言，他们抛弃TypeScript重回JavaScript的主要原因如下：
\2.减少TypeScript元编程所带来的代码组织的负担和所需要编写的代码量。
4)TypeScript转向JavaScript真的是一个好选择吗？
在日常业务开发中，我们通常只会使用类型定义、泛型以及简单的类型推导，并不会使用到所谓的“TypeScript类型体操“，但是TypeScript强类型所带来的类型安全能够大幅度提高项目的代码质量和可维护性。而在类库和框架的开发中，抛弃TypeScript转向JavaScript的只是少数开发者，目前绝大部分的主流前端开源项目都是在拥抱TypeScript，这也足以证明社区肯定TypeScript所带来的价值。
此外，虽然TypeScript原生编译器速度较慢，但是笔者认为这个是可以通过更换esbuild或则swc等性能更加优异的编译器来解决的。
没有任何一门语言是十全十美的，TypeScript也毫不例外。笔者认为TypeScript的确会引入了一定的复杂度，但是其所提供的类型系统能够大幅度提高项目的健壮性和可维护性，在绝大部分前端开发场景下，都是利大于弊的，能够很好地规避JavaScript弱类型带来的大部分陷阱。
参考内容：
ECMAScript2023：持续完善并拓展JavaScript语法
回顾完前端语言明日之星TypeScript，让我们将目光转到JavaScript上。今年6月27日，第125届ECMA大会正式批准了ECMAScript2023语言规范。总而言之，本次ECMAScript2023并没有新增大的改动点，更多是对JavaScript原来语法的完善与增补。而笔者认为其中比较有意义的更新主要有以下两个：
\1)WeakMap支持Symbol作为Key。
总所周知，WeakMap的Key是弱引用，且要求是唯一的值。由Symbol具有唯一性，保证不可重建，因此在今年的ECMAScript2023新特性中扩展了WeakMapAPI，WeakMaps允许使用唯一的Symbol作为键。不过值得注意的是，通过Symbol.for创建的Symbol是不可以作为弱引用的，因为Symbol.for会在全局注册Symbol，并支持在任何地方通过Symbol.for再次引用。
\2)新增四个通过副本修改数组的方法：toReversed()、toSorted()、toSpliced()、with()，
目前大多数的数组方法都是非破坏性的，当然也存在一些对原数组具有破坏性的方法，例如reverse()、sort()以及splice()。当我们想要使用这些方法又不想对原数组造成影响的话，通常需要先拷贝一份数组再调用相应的方法，由此可见，这种开发体验不友好的。因此在今年的ECMAScript2023优化了开发体验，新增了相应的非破坏性方法。
关于更多ECMAScript2023其他改动的完整信息，请参考官方文档，此处不再赘述：
众望所归的CSS嵌套和CSS父选择器正式落地
\1)原生CSS支持嵌套
CSS支持嵌套一直是Sass中最受开发者喜爱的功能点之一，它允许让开发者在编写样式的时候更加整洁、内聚。据上一年StateofCSS统计，CSS嵌套是受访者认为CSS最需要补充的功能之一。
而在今年CSS2023新特性中，原生CSS正式支持嵌套写法，在高版本浏览器中，无需依赖额外的编译器即可享受Sass嵌套语法，很大程度上优化了开发者体验，提高了CSS的可读性和可维护性。
\2)各大浏览器正式支持CSS父选择器
除了CSS嵌套外，父选择器也是受访者认为CSS最需要补充的功能之一。简单来说，CSS父选择器的作用能通过子元素选中其父元素。既然是万众期待且如此实用的选择器，为什么各大浏览器迟迟没有支持呢？
笔者总结答案主要是以下两个原因：
a)浏览器的渲染模式是以流的方式，一个元素接一个元素进入。因此当一个元素在浏览器渲染出来时，其父元素的样式计算已经完成并且也已经渲染好了。在此之后，通过子元素选择父元素并应用样式触发重绘时，需要对父元素和子元素都进行重新绘制，这样的计算对于当时的渲染引擎而言是昂贵的。
b)与其他选择器而言，父选择器触发重绘的性能开销很大，如果有一个父选择器，那将很容易成为低效率选择器中的新老大。
近几年浏览器的渲染引擎有了很大的改进，目前浏览器可以有效地确定哪些需要渲染或更新，而哪些不需要。因此在今年众望所归的父选择器:has也正式被各大浏览器所支持。
2、前端框架：主流框架持续完善，黑马Htmx与Qwik异军突起
回顾2023年前端框架，最受欢迎的四大主流框架依旧是React、Vue、Angular和Svelte。从2023年NPM包下载量来看，React框架依旧一骑绝尘，遥遥领先。Vue则处于第二的位置，而Svelte已连续两年超过Angular，成为前端第三大最受欢迎的UI框架。
（图查询自）
除了上述前端框架的四架马车以外，今年还有两个黑马框架正式发布1.0版本，他们分别是Qwik和Bun，接下来让笔者带你们盘点2023年期间这些框架到底发生了什么值得回顾的重要事情吧。
React2023：重构与转型
在2023年期间，React官方整整一年都没有发布新的release版本，上一次发布release版本还是在2022年的6月，而React19也似乎遥遥无期，最近一次更新已经是在一年前了。那么今年React官方到底在忙些什么呢？
与此同时，今年React团队引入了名为Canary版本的发布渠道，从而使其可以在新功能的设计接近完成时就可以选择使用这些功能，而不必等到它们发布为稳定版本，React团队也是主要通过此方式为上层框架提供相应的API支持。
Vue3VaporMode：更少的运行时开销
而笔者则重点介绍一下尤大曾在2023新年展望中首次提到的VaporMode。
\1)VaporMode是什么？
VaporMode是Vue3受Solid.js启发新的编译模式。它不依赖于虚拟DOM，而是更多地利用Vue的内置响应性系统。简而言之通过将代码编译为更高效的JavaScript，减少运行时开销，以获取更好的页面性能。Vue之所以支持实现与Solid类似的编译策略，是因为Vue与Solid.js具有类似的响应式系统，它们都通过使用代理的方式实现响应式，并具有基于读取的自动跟踪。
\2)VaporMode的进展与规划
VaporMode目前仍处于开发阶段，从VueConf2023中可得知目前的进展与规划如下，具体更多介绍请观看上述提到的VueConf2023视频进行了解，笔者在此处简单概括一下：
第一阶段：核心功能的运行时
这一阶段的主要重点是在Vue核心功能的运行时引入并支持VaporMode，该阶段目标如下：
●支持核心指令（v-on、v-if、v-for等）和组件树。
●验证性能假设。
●与现有SSR输出的水合兼容性。
目前第一阶段已基本完成。
第二阶段：核心功能的编译器
这一阶段的主要重点是确保可以使用Vue模板或JSX并将其转换为运行时可以处理的内容，该阶段目标如下：
●共享代码生成IR（中间表示）
●JSXAST/模板AST-IR-VaporMode代码
第三阶段：集成
这一阶段的主要重点是两方面，一是VaporMode能够无需对当前的设置进行任何修改，可以无缝地融入现有的应用，降低接入成本；二是支持在组件级别进行选择性接入VaporMode，以便于开发者可以根据需要灵活地使用VaporMode，例如在性能关键的区域中使用，该阶段的目标如下：
●对独立Vapor应用的工具支持
●在现有应用中运行Vapor组件
●Vapor中运行vDOM组件
第四阶段：功能对等
在首次发布时，VaporMode将仅提供基本的核心功能，而诸如、、、Suspense等辅助功能将在Vue团队完成前述目标后进行实现。
总结而言，尤大在会议中如此说道：“这个策略只是一个实验性的产品，并不一定会上线，更不会是破坏性的更新，将来会提供可选的编译模式提供给开发者进行自行选择”。VaporMode新特性可以理解成Vue在性能和包体积缩减方面的进一步探索与发展，其灵活的采用策略在保持与现有特性的兼容性，为不同场景需要提供了不同编译选择。
Vue2已迎来终局
Svelte4正式发布：持续优化并铺垫未来
今年6月，Svelte4正式发布，Svelte4主要是一个维护版本，该版本提高了最低版本要求并加强了特定领域的设计，为未来的Svelte5的发布奠定了基础。Svelte4的主要亮点在于包体积大小优化上，从原来的10.6MB减少到2.8MB，降低约75%。
除此以外，Svelte宣布将在Svelte5将引入新的响应式API：runes。Runes本质上是作用于Svelte编译器的特殊语法，通过derived和$effect的语法。
从网上开发者做到一张代码对比图上看，Runes设计思想上类似于VueReactiveTransform。
Angular重磅回归
今年5月4日，Angular16正式发布，开发者预览版引入全新的Angular响应式模型和基于Esbuild的构建系统，并无显著的新特性，更像是一个“垫脚石”版本。而在2023年的11月8日，Angular17正式发布，该版本引入了许多重要的更新：
●引入了可延迟的视图，将性能和开发者体验提升到新的高度。
●内置控制流循环使运行速度在公共基准测试中提高了高达90%。
●混合渲染和客户端渲染的构建速度分别提高了87%和67%。
Htmx意外走红：重新回到ASP时代？
在前后端分离和单页面应用（SPA）已经形成大局的2023年，却有一款基于动态服务器页面（ASP）思想的框架htmx意外走红。它在2023年JavaScript明星前端框架中排名第二，仅次于React。接下来就让笔者带大家了解一下Htmx究竟是何方神圣以及Htmx的爆火是否意味着前端要开历史的倒车重回ASP时代呢？
\1)Htmx是什么
\2)Htmx是传统思路的回归
如今，React、Vue等前端主流框架使用的都是单页面应用（SPA），目前也是创建Web应用程序的主流方式，前后端采用JSON数据进行交互。
而Htmx则是由服务端处理页面交互和响应，例如UI事件会被发送至服务端进行处理，并生成html本体返回客户端。
但是笔者认为Htmx虽然有它的优点所在，但是在生产环境的使用上还是存在非常大的局限性：
\1.由于需要向HTML代码中添加非常多的“增强属性”，HTML会变得非常臃肿，可读性和可维护性会变得更差，不适用于大型项目的开发。
\2.目前React、Vue等SSR直出渲染已经能够具有非常好的首屏性能了，笔者认为服务端只需要做好首屏渲染就好了，所有渲染逻辑统一收归服务端渲染后返回HTML片段会造成更大的服务器压力。
总而言之，Htmx的意外走红并不是Web应用开发模式开倒车的征兆，是各自适应场景不同，适合简单的页面，或者前端经验缺乏的人使用。
Qwik1.0正式发布：不是水合合不起，而是可恢复更有性价比
除了上述框架以外，2023年还有号称历史上第一个O(1)的前端SSR框架的Qwik正式发布1.0版本。Qwik虽然是今年才正式发布1.0版本，但是它已经凭借其惊艳的性能数据，斩获2022年JavaScript明星项目的前端框架排行榜第二名，当时仅次于React。
\1)传统SSR框架的局限性
为了保证页面首屏可见的性能，对于动态页面一般会采用SSR的方式来优化首屏可见耗时。目前主流的支持SSR的框架，例如react、vue等，从用户请求到页面可交互需要经历以下四个阶段：
a.获取服务端渲染后直出的HTML
b.浏览器下载页面所需要的所有JS资源
c.解析并执行JS
\2)Qwik是如何做到的呢？
Qwik虽然也是SSR框架，但是它采用提供一种无hydartion的更加优雅方案，称为Resumability可回复性的方案
a.服务端渲染时将所有必需的信息序列化成HTML模板，包括WHAT（事件处理函数内容）、WHERE（哪些节点需要哪些事件处理函数）、APP_STATE（应用状态）和FRAMEWORK_STATE（框架状态）。
b.依赖于事件冒泡来拦截所有事件进行全局处理，无需在特定DOM元素上单独绑定事件。
c.当用户点击时，通过全局事件委托的方式，动态加载点击函数并执行。
d.点击函数会触发视图更新，并动态加载渲染函数并执行，从而完成了恢复性渲染。
简而言之，Qwik将HTML中序列化所有必需的信息，以及使用全局事件处理程序来拦截和处理事件，而不必显式将事件处理程序附加到特定的DOM元素上，这样可以避免的水合过程，并采用更加极致的懒加载策略和可恢复性操作，从而做到”直出即可用“的状态。
当然，任何框架的优势和劣势都不是绝对的。首先，Qwik由于需要在服务端渲染时进行信息序列化操作，因此会给服务器带来更大的压力。其次，qwik在触发用户行为时再惰性加载并执行响应的JS脚本，这样需要在用户触发交互时动态生成对应的事件处理函数进行执行，造成一定的交互响应上的延时。
3、前端基础建设：多种语言助力前端基建的持续发展前端锈（Rust）化愈演愈烈
从Github2023年度报告显示，Rust增长率位于所有语言榜首，其年增长率到达40%，并连续第八年被2023年StackOverflow开发者调查评为最受赞赏的语言。
从StackOverFlow2023年度开发者报告也显示，超过80%的开发人员希望在明年继续使用它。
\1)前端基建Rust化预言
●打包构建：以Webpack为代表。
●编译器：以Babel为代表。
●代码检查：以Eslint为代表。
●代码格式化：以Perttier为代表。
●代码压缩：以Terser为代表。
\2)Rust在前端基建已经崭露头角
●2022年10月底，Next.js发布了基于Rust的构建工具Turbopack，因为性能数据非常惊艳，引起了一时的轰动。
●2023年3月10日，字节跳动发布了基于Rust的构建工具Rspack正式发布，经官方开发者验证可以给项目带来5～10倍的编译效率提升。
●2023年10月5日的ViteConf2023线上大会中，Vue作者尤雨溪也宣布计划使用Rust重构Vite，替换掉原有的Esbuild和Rollup，以获得更好的性能。
●2023年12月12日，基于Rust的代码检查工具Oxlint正式发布，Shopify报告称其比ESLint快50-100倍，并可以随CPU核心数量不断扩展。
Rust因为其出色的性能，在编译、打包构建等前端基建的方向所带来的性能数据提升令人震撼。在JavaScript性能提升挖掘缓慢的今天，不少前端基础建设框架/库的开发者为追求更高的性能开始逐渐将目光转向了Rust。由此可以预测，Rust工具将会更加深度地融入前端生态，说不定会掀起新一轮的前端基础建设浪潮，让我们拭目以待。
前端界的卷王Bun1.0正式发布
在前端基础建设方面，已经连续两年登顶JavaScript明星项目的Bun于今年9月8日正式发布1.0版本。Bun不仅是一个专注性能与开发者体验的全新JavaScript运行时，还是一个转译器、构建工具、包管理器以及测试库的全能工具包，旨在无感替代现有的JavaScript运行时（node.js和Deno），并成为浏览器外执行JS的主流环境，为用户带来性能和复杂性的提升的同时，以更好更简单的工具提高开发者的效率。
笔者认为其最大的两个特点在于性能和便捷性上：
\1)性能
之所以Bun在性能上会有如此优异的表现，主要是因为作者在实现上对方方面面进行了精细的优化，特别值得提及的两个优化点是：一是Bun使用性能更好的Zig和C++实现了Node中使用JavaScript编写的重要内置库，而且Zip支持进行低级内存控制和消除隐藏控制流，性能优化更好。二是Bun与使用基于V8引擎编写的Node和Deno不同，它使用的是JavaScriptCore引擎，该引擎在性能上优于V8引擎。
\2)便捷性
随着JavaScript不断发展，各种工具被逐渐添加进来，JavaScript的工具链变得越来越庞大与复杂，但是目前前端并没有统一的工具包，使用时需要开发者手动添加各种工具以满足开发编译需要。而Bun设计初衷除了性能优化外，还希望作为一个全能的工具包的形式，消除JavaScript工具链的复杂性，为前端开发者提供一个开箱即用的开发体验。
4、Chrome浏览器：加强对用户数据安全的保护将全面禁止第三方Cookie
早在前两年，Chrome已经计划全面弃用第三方Cookie了，但是如果直接弃用很可能会导致大量网站功能无法正常使用。而在今年Chrome更新的113和114版本中，Chrome稳定推出了Cookie第一方集和Cookie独立分区两项功能，并随即在今年10月11日于Chrome的官方博客上宣布计划从2024年第一季度开始对1%的用户禁用第三方Cookie，并在第三季度将禁用范围扩大至100%。接下来笔者将对此进行解读一下。
\1)第三方Cookie的作用与风险
但是由于第三方Cookie所记录的信息允许被携带其他网站，因此这样无形之中就有用户隐私被泄露的风险。这种担忧不仅来自用户，也来自于法规如如欧盟的通用数据保护条例（GDPR）和加州消费者隐私法案（CCPA）。因此目前Safari、Mozilla等其实已经推行禁用第三方Cookie的措施了，而如今迫于隐私泄露的压力，第三方Cookie不得不逐步退出历史舞台。
\2)Chrome提供的解决方案
首先Chrome114版本提供Cookie独立分区（CHIPS）的能力，它允许开发者将Cookie按照分区进行存储，每一个顶级域名都有独立的Cookie存储分区，因此顶级域的页面可以访问其通过iframe嵌入的网站所存储到独立分区中的Cookie，而不同顶级域之间的Cookie存储分区并不互通。
再者Chrome提供Cookie第一方集（First-PartySets）用于解决自定义Cookie集合的问题。通常而言，许多公司或者组织都会使用多个域名，虽然它们的域名不同源，但是按道理来讲都是属于第一方的，此时开发者可以将需要共享Cookie的不同域名放到一个集合中提交给Chrome进行审核，审核通过后便可以通过Chrome提供的特殊方式读取这些域名下共享的Cookie。
内容参考：
将全面禁用ManifestV2扩展
ManifestV2是Chrome早期制定的、用于开发浏览器扩展的一套技术标准，多年来已经成为行业标准。但随着人们对数据、隐私安全的重视，其允许扩展修改用户请求、权限模型较为简单、CSP实现较为宽松等安全隐患也逐渐暴露出来。
ManifestV3标准在2018年发布以来，相较于V2版本主要做了如下优化：
●ServiceWorkers替代BackgroundPages
ManifestV3引入了ServiceWorkers来替代BackgroundPages。ServiceWorkers是一种可以在后台运行的JavaScriptWorker，它不依赖于任何特定的页面，这使得它在处理后台任务时更加高效和节能。此外，ServiceWorkers在处理完成后会自动停止，从而减少了扩展对系统资源的占用。
●引入更高级的权限模型
ManifestV3引入了一种新的权限模型，它允许用户在安装扩展时选择授予扩展哪些权限，从而提高了用户的隐私和安全性。
●限制远程代码执行
ManifestV3禁止扩展执行远程代码，所有的代码都必须包含在扩展的包中。这可以防止扩展被用来执行恶意代码。
●引入DeclarativeNetRequestAPI
ManifestV3引入了DeclarativeNetRequestAPI来替代webRequestAPI。DeclarativeNetRequestAPI允许扩展在网络请求被发送前对其进行修改，但它不允许扩展访问请求的详细信息，从而提高了用户的隐私。
长期以来，Chrome为兼容历史扩展，一直保持两套标准并存。然而在2023年，Chrome终于宣布将于24年6月份全面禁用V2扩展，这将大大提高Chrome数据和隐私的安全性。
5、低代码：持续完善的低代码引擎开源社区
2023年低代码仍然是前端领域非常火热的话题。根据爱分析《2023低代码厂商全景报告》显示，2023年中国低代码市场规模为50.2亿元人民币，年增速为39.9%，行业发展迅猛，同时低代码开始向更深入、更垂直的场景和应用渗透，要求低代码技术的发展趋势倾向于满足行业的需求。因此基于低代码引擎底座至上实现垂类定制的低代码解决方案逐渐成为了社区的基本共识。继2022年阿里开源了lowcode-engine后，网易和华为在今年也分别相继开源了Tango低代码引擎和TinyEngine低代码引擎，进一步丰富了低代码的社区生态。在技术实现上，前者基于源代码驱动实现，后者在低代码底层能力上集成了人工智能，接下来让我们一起看看它们有哪些亮点与不足吧。
基于源代码驱动低代码引擎的探索
今年8月网易云音乐前端技术团队开源了一款基于源代码驱动实现的低代码引擎Tango。和现有基于DSL编排的低代码实现不一样的是，Tango低代码引擎能够提供源代码进、源代码出的可视化搭建能力。
何为源代码驱动？
Tango低代码引擎在设计上摒弃了私有搭建协议和DSL，而是借助ESTree规范和源码AST转换。用户在低代码平台的搭建操作本质上都是对源码AST进行遍历并修改，进而将修改后的AST重新生成为代码，将代码同步给在线沙箱执行，从而做到了输入和输出都是代码，且不包含任何私有的中间产物。
源代码驱动的好处
对于源代码驱动的好处，笔者认为主要有两点：
\1.与传统的基于Schema驱动的低代码引擎相比，组件开发与拓展等都无需依赖于私有协议和DSL，灵活性较高。
\2.源代码驱动的低代码引擎的输入和输出都是代码，支持双向转码，解决了二次开发不同步的问题，使其更适合开发同学使用。
源代码驱动的不足
笔者认为源代码驱动在使用上有点类似于远古时期的DreamWeaver，这种方式虽然可以不依赖私有协议，但不同语言的AST是有差异的，如果需要实现跨端，不同语言之间的AST转换相对来说就比较困难了。
大模型与低代码平台结合的尝试
随着今年大模型的爆火与迅猛发展，大模型与低代码引擎结合有着非常大的潜力。在今年9月华为开源了一款支持使用大模型（文心一言）辅助开发低代码引擎TinyEngine。无独有偶，腾讯的无极低代码平台以及百度的爱速搭在今年更早的时候已经尝试在低代码平台中接入大模型辅助开发了。接下来就让我们一起看看，大模型与低代码引擎究竟能够碰撞出什么火花吧。
大模型在低代码平台的应用场景
低代码平台中并不是所有场景都适合使用大模型，例如在单次拖拽组件的场景，试想一下，原本只需要简单动动手指的功夫，现在需要敲一段指令让大模型理解你的诉求并完成操作，这效率明显更低。
笔者根据现有的已接入大模型的低代码平台整理了在低代码平台中适合使用大模型的应用场景：
\2.代码辅助生成：在低代码平台中需要编写少量代码实现功能的LessCode，可以通过大模型辅助编写或者直接命令生成，降低低代码开发平台的使用门槛。例如在无极的LessCode部分，通常需要学习无极的文档中的API来“获取页面的状态数据”或者“调用无极的工具方法”，此时使用大模型根据你的要求结合文档自动生成，是不是世界瞬间清爽了很多。
大模型在低代码平台落地应用的问题
受限于目前大模型的限制，目前大模型在低代码平台中落地应用会存在以下问题：
\2.Token限制：Token限制也是目前大模型使用中最头疼的问题之一，目前大部分是限制2K-4K，这是在训练时决定的，不好扩展，只能拆分Prompts。
\3.安全问题：由于数据具有安全性问题，大多数情况下无法直接将数据交给外部的大模型使用。
6、D2C：C2D2C亮相，大模型赋能D2C未来可期
C2D2C：精准识别组件
传统D2C如果想要做到精准识别组件，利用图像识别和深度学习难以实现，一般都需要设计稿足够规范或包含足够多的标注信息，而C2D2C就是为了解决传统D2C在组件识别上的局限性。所谓C2D2C，就是开发同学先用现有UI组件库转换成设计组件并导入到设计平台作为物料，然后设计同学使用这些设计组件物料输出设计稿，最后设计稿再转成基于UI组件库的代码。由于设计稿和代码使用的是同一套设计系统，设计稿中的组件和最终代码中的组件是一一映射的关系，因此无需进行标注就可以实现组件的精准识别。字节的SemiD2C、腾讯的如意助手、网易的海豹助手都是在2023年发布的C2D2C的具体产品。
大模型赋能D2C未来可期
这几年D2C的发展比较迅速，但前端社区并没有出现一个非常惊艳的独角兽项目，主要原因可能是传统的D2C解决方案通用性不足，对于业务需求和设计稿的各种复杂情况具有局限性：
\1.对设计稿规范依赖程度高：传统D2C生成代码依赖于设计师按照特定的规范来创建设计稿，例如标注等。
\2.布局算法的局限性：任何一种布局算法都存在局限性，对边界情况的处理能力不足，想要生成布局合理的代码依赖非常复杂的布局算法。
\3.生成的代码语义化和可维护性较低。
随着今年大模型的迅猛发展以及其优秀的泛化能力，大模型为前端设计稿生成代码注入了新的活力：可以利用大模型辅助设计稿生成代码：
\1.利用大模型的优秀的上下文理解能力，将DSL中元素绝对位置推断出合理的Flex布局，无需实现复杂的布局算法。
\2.利用大模型擅长处理代码的能力，可以通过页面布局的DSL生成可读性和可维护性更高的代码。
而就在2023年10月12日Builder.io推出的VisualColilot就是一款这样的商用产品，官方称可以将Figma设计稿一键生成高质量、可读性和可维护性较高的多种框架的代码，支持自定义组件，提供了二次编辑的低代码平台。
不过经过笔者尝试，将一张未经过任何处理的设计稿使用VisualColipot生成的代码并不理想，可读性和可维护性也没有那么高，甚至会有文字识别成图片的情况，没有达到直接可用的状态。但是毋庸置疑的是大模型确实为设计稿生成代码提供了一种新的思路与解决方案，相信随着大模型识别能力和生成能力的不断增强，大模型赋能D2C未来可期。
7、大模型：大模型应用能力持续完善与落地
接下来让我们一起回顾被称为大模型元年的2023年期间，大模型有哪些比较重要的发展与落地应用吧。
大模型支持返回结构化内容
默认情况下，大模型生成的内容都是非结构化的文本数据，但是开发者通常在编程的过程中使用的大多数都是结构化的数据，所以开发者需要自行对大模型生成的内容进行文本匹配等预处理操作，在通过API方式使用并没有那么便捷。TypeChat官方仓库如下：
而今年7月10日，C#和TypeScript首席开发人员、微软技术研究员AndersHejlsberg组成的团队于7月20日发布了TypeChat。它允许将大模型返回的非结构化数据转化为结构化数据并确保其满足模式约束，并提供自动纠错的机制，在一定程度上解决了大模型生成的内容存在较大的随机性和不稳定性。
TypeChat主要特点如下：
●支持返回结果类型定义：TypeChat使用TypeScript类型作为Schema约束大模型返回符合TypeScript类型的JSON格式数据，
●自动纠错机制：TypeChat内置自动纠错的能力，会通过Typescript来验证输出结果并进行循环纠正。
当CodeReview遇见大模型
在大模型应用于开发者赋能方面，除了使用大模型编程辅助工具外，还可以为开发者的研发流程中的一些环节进行赋能，例如CodeReview、生成单测等。
ChatGPT官方推出Prompt工程指南
一直以来，关于如何写好prompt，网上有各类教程，但是一直缺乏一份官方版本，12月15日，OpenAI在他们他们的文档中上线了Promptengineering（提示词指南），这也是从官方层面推出的权威且有效的prompt标准文档，该份文档提出了6条大的原则：
\1.Writeclearinstructions（写出清晰的指令）
2.Providereferencetext（提供参考文本）
\3.Splitcomplextasksintosimplersubtasks（将复杂的任务拆分为更简单的子任务）
\5.Useexternaltools（使用外部工具）
\6.Testchangessystematically（系统地测试变更）
关于这六条原则的细化解读和示例说明可以参考：
8、跨端：鸿蒙应用开发为跨端带来新变化
在今年华为首次公开了HarmonyOSNEXT的概念，HarmonyOSNEXT与之前的版本不同，HarmonyOSNEXT可谓是与Android彻底切割了，简而言之，在该系统上无法再运行Android应用，只能使用由ArkTS编程语言开发的原生HarmonyOS应用。因此笔者接下来会介绍一下华为新推出的HarmonyOSNEXT的普及会对跨端领域会带来什么样的影响吧。
\1)鸿蒙应用开发
在今年首次公开的HarmonyOSNEXT系统已经不再是过去被广大用户所调侃的“套壳Android”，它是完全基于全自研内核，去掉了传统的AOSP代码，仅支持鸿蒙内核和鸿蒙系统的应用减少了40%的冗余代码，使系统的流畅度、能效、纯净安全特性大为提升，而这些性能上的提升得益于HarmonyOSNEXT系统遥遥领先的设计理念：
●一次开发，多端部署。
●可分可合，自由流转。
●统一生态、原生智能
笔者认为两者都对前端开发者挺友好的，看来华为除了争取移动端开发者更想把前端开发者争取进来共建生态。
\2)对跨端的影响
HarmonyOSNEXT的出现无疑意味着了一个新的操作系统的诞生，随着后续HarmonyOSNEXT的推广，安卓、IOS、鸿蒙三分天下的局面指日可待，那么软件的研发成本肯定会上升，那么跨端的方案相信未来也会成为越来越多开发者的首选。目前鸿蒙除了有独立自主的开发UI框架ArkTS外，也兼容了市面上主流的跨平台方案，比如flutter、RN、Weex等。
9、WASM:未来将与更多语言和场景结合
为了解决这些问题，Mozilla的工程师AlonZakai在2012年提出了Asm.js，经过几年的发展，终于在2015年进化为WebAssembly。
WebAssembly（缩写为Wasm）是一种用于基于堆栈的虚拟机的二进制指令格式。Wasm被设计为编程语言的可移植编译目标，支持在Web上部署客户端和服务器应用程序。
到2024年，Wasm走过了12个年头，Wasm已经在广泛的环境中使用，从浏览器到边缘和IoT，甚至到云端。
从使用何种语言进行Wasm的开发统计上可以看到，Rust依然是排名第一的作为Wasm的开发语言，随着Rust广泛用于devops流程工具，2024年毫无疑问依然会延续这种趋势。
（图选自：）
从Wasm的特性提案中，我们能看到线程、垃圾收集和异常处理在去年的结果中均名列前茅，并且这三者都处于提案生命周期的实施（第3阶段）或标准化（第4阶段）。这意味着它们已准备好使用，并且接近完成。
可以预见接下来会有更多场景，更多语言接入对Wasm的支持跟使用，而各个领域的不同开发者碰撞，也会让Wasm的标准趋于全面以及更加具备普适性。而Wasm作为AI边沿计算的总要解决手段，相信2024年也会有结合实际AI业务场景的Wasm应用诞生。
10、音视频：传统编解码与AI编解码并驾齐驱
据《2024音视频技术发展报告》显示，在音视频行业中，从事RTC/实时通信技术和音视频编解码领域的研发占比最高。
在传统音视频编解码领域中，H.264/AVC和H.265/HEVC仍然时国内外在视频编解码上的首要选择。而H.266/VVC目前软件编码复杂度较高，导致其在实时通信应用场景较难实现，因此H.266/VVC硬件化是必然趋势。预测在未来两年内，H.265/HEVC仍然是主导选择，H.264/AVC使用份额呈现萎缩趋势，AV1在国内外的使用情况都会呈现增长趋势。
未来是多编码标准共存的时代，到底是H.265/HEVC继续稳定发展，还是AV1后来居上，亦或是AI编解码突出重围，让我们拭目以待。
2024技术展望
技术的发展是永无止境的，脚踏实地才能遥望星空，回顾2023年的前端技术也是为了更好地展望未来的发展趋势，据此我们可以对2024年前端技术不同细分的领域方面作出一些展望：
1、大模型持续为前端赋能
今年大模型的兴起为前端多个领域都注入了新的活力。随着明年大模型的不断发展与进化，相信大模型能够在前端越来越多的领域中落地并持续赋能。例如，在D2C领域，随着大模型识别推理和内容生成能力的不断提高，其根据设计稿所生成的代码的质量会更上一层楼，因此大模型在设计稿生成代码上的应用将会越来越广泛；低代码、AI辅助开发等领域相信也会有更多地应用场景。作为开发者我们也应当主动去拥抱并思考如何更好地利用大模型进行赋能。
2、拥抱TypeScript是前端语言与标准的主旋律
TypeScript虽然会带来一定的复杂度，但是其所提供的类型系统能够大幅度提高项目的健壮性和可维护性，在绝大部分前端开发场景下，都是利大于弊的。因此拥抱TypeScript依旧是未来前端语言与标准的发展大趋势，随着TypeScript的不断升级和优化以及前端基建能力不断完善，相信它会给我们带来更好的开发体验。
3、探索更好服务端渲染是前端框架的大势所趋
在前端框架领域，React、Vue、Svelte和Angular这四大框架依旧会是明年的前端框架的主流。无论是从今年的主流框架的发展趋势（ReactServiceComponent、VueVaporMode等），还是黑马无水合SSR的Qwik、重归ASP思想的Htmx以及前两年兴起的孤岛架构Astro，服务端渲染模式应当是明年前端框架的主战场了，其通常具有更快地页面首屏可见，用户体验更好。究竟明年是否会有更好的服务端渲染模式的诞生，也让我们拭目以待。
4、Rust是前端基础建设的未来
由于Rust其优异的性能使得其成为前端基建的新宠，在2023年期间陆陆续续有基于Rust的前端基建工具的诞生，以及越来越多的前端基建工具的开发者宣布使用Rust重构。相信随着明年Rust在前端的生态不断完善和推广，Rust将会成为前端基础建设的主流，而且随着Rust允许编译成更高质量的WebAssembly代码，在浏览器上也会渐渐出现其的身影吧。
5、鸿蒙入局，跨端技术将会越来越受推崇
2023年鸿蒙褪去的“Android套皮“的名号，推出了一个新的操作系统HarmonyOSNEXT。明年随着华为手机的持有量上升以及HarmonyOSNEXT的铺量，安卓、IOS和鸿蒙三大操作系统三分天下的格局形成指日可待，软件需要适配的操作系统的增加会带来的研发成本的上升，跨端的方案相信未来也会成为越来越多开发者的首选。而鸿蒙应用的开发语言ArkTS选择前端开发者最熟悉的语言和开发范式作为基底，这无疑对大前端而言，既是机遇也是挑战吧。
总而言之，时代在不断进步，技术也在不断进步，而我们也需要不断地进步！