今年以来，随着各种LLM的编程能力大幅提升，vibe coding也开始渗透到了各个方面。先是A\搞个AI写编译器，再是OpenAI摘取人类数学中“低垂的果实”，每个月都能震惊瘫坐一次。Bun在搞Rust大重写，pnpm也重写到了Rust。Rust方面来看，各种UI框架层出不穷，一句话就能搞一个自己的Native UI框架。当然，因为WASM能够在浏览器中运行，所以很多人开始尝试将原生UI带入浏览器，用Rust来写前端。
诚然，在前Agent时代，WASM确实为不少能够编译到WebAssembly的原生应用提供了在浏览器中运行的可能性。比如Blazor，还有一些神秘的自研框架，但是这些都起码遵循了最基本的网页原则，起码还是HTML的DOM模型。再往前看，是JSP、ASP、PHP这套传统的服务端渲染模式，它们同样遵循网页的基本结构和交互逻辑。相比之下，现在这种用Canvas+WASM绘制Web的方式真的是令人匪夷所思。
绕不开的Flash
那有好事的就要问了：Flash也干了，你怎么不喷？先不说Flash已经死了，单Flash的体验也是遥遥领先于现在这票Canvas+WASM的原生UI尝试。Flash有自己的ActionScript，不用在浏览器中下载10M甚至上百M的WASM，此乃一胜；Flash不用吃WASM和JS交互的屎，此乃二胜；Flash不用管WASM RT是否开启JIT，此乃三胜。更不用说Flash最擅长的交互和动画处理能力，Canvas+WASM在这方面远远不如Flash，体验上自然也就差了很多。
我是来上网的，你们要干什么
最近vibe coding大跃进，某群群友也搞了个自研wabou来凑凑热闹。什么QT，Flutter，KMP，Slint这种老牌能target到Web的框架就更不用说了。这些框架都有非常搞笑的问题：首屏灾难。因为这些东西和Blazor不一样，它们是没有服务端渲染的概念的，目前来看也很难做服务端渲染。所以，在浏览器自身的loading之后，需要再写一个js桥，再在页面中下载完WASM并初始化，预热完毕后才能显示首屏内容，用户体验极差。这就导致了你想要看到第一个界面，就必须通过两次loading，一次是加载document，一次是加载WASM。加载document还好说，如果不是新页面是不会导致白屏的，但加载WASM的过程往往会让用户看到白屏（某些有深色模式的网页会有支持深色但是大部分没有）。所以我需要对着一个或多或少有进度条没进度条的网页等个十几秒甚至更久，真是给我气笑了。
还记得之前还在大叫每增加一秒，页面浏览量减少11%，现在增加个半分钟也变成可以被接受的方案了，真是时代变了。隔壁Next.js大家庭还在狠狠的优化SSR速度，这边SPA则已经开始摆烂了。明明在移动互联网时代，手机上网页加载缓慢对跳出率的影响更加显著，但是大家都开始不关心这个了。
与此同时，每一次渲染也是一次酣畅淋漓的性能释放。先不提这套方案对webview的基线要求有多高淘汰了多少老设备（啊这个这个不少webview真的没有120+的Chromium版本，根本用不了），对于现代设备来说，性能问题也是一个非常严重的问题。因为Canvas是在主线程中绘制的。对Web开发有一点了解的人都知道，做网页最忌讳的就是将重任务放置在主线程操作，因为这会导致页面卡死。以滚动为例，原生浏览器的滚动是异步的，能够在大多数情况下都不卡，而这些自绘框架处理的滚动多半是达不到原生的性能的。那些vibe slop更是完全不会去关心什么worker和离屏渲染。这种类似Immediate UI的设计在桌面端可能还可以，放到老的手机上则是一场彻底的灾难。
如果你尝试使用多线程来解决问题，那么你将会吃上最屎的开发体验。这基本上要求你会前端会后端，熟练掌握bridge，workers的使用，以及线程间的数据同步和状态管理，你让AI来写也就只能拉一坨出来。
在现在手机/平板/电脑屏幕DPI越来越高的现在，使用这种自绘方案不仅会遇到Canvas大小限制的问题，还会遇到掉帧卡顿、内存泄露这些根本不应该发生在一个网页上的问题，也是活久见了。
顺带一提，还有context loss的问题。压力一个核显？
苹果vs安卓
苹果因为出过电池门和其他不大不小的事件，是的很多用户都不积极升级iOS版本。这导致即使是在2026年，对于Safari的适配要求基本上还是在Safari 16左右的水平，震撼美味。你无法使用三方浏览器，而Safari是跟随系统更新的，所以如果你用这些技术，你的网站将无法在苹果设备上显示。
安卓方面则相对宽松得多。大多数安卓设备都可以自由安装第三方浏览器，但是我们自有国情在，什么百度浏览器里面的内核版本还是两位数，只能说各有各的屎要吃。
键盘导航与可访问性
各个原生UI的可访问性和键盘导航做的都非常垃圾，即使有，也不是默认开启的。这就导致了我这种喜欢按tab或者有些时候用读屏器或者键盘操作网页的人非常痛苦。基本上，所有操作系统中的无障碍组件都无法正确理解其中的空间，必竟Canvas本质上就是一个位图。
当然这对于某些需要反爬的网站来说是一个好消息。
原生，启动失败
浏览器不是一个界面，浏览器是设计用来浏览的，具备有所有浏览相关的功能。但是我们的Native UI则有一些不同的想法。
虽然说这些框架实现了原生UI进Web，但是把所有Web原生的功能全部bypass了。什么页面内搜索，文本选择，复制，翻译，打印，自动填充，浏览器扩展支持等等，全部无法使用。锚点、页面缩放这些功能也是根本不存在了，因为Canvas就是一个位图，什么都干不了。先不说有些好的App开发者会补全一部分内容，反正框架完全就不管了。
前进，后退这些History API，刷新后的状态恢复，滚动条的支持（是的如果你按Shift点击原生滚动条是可以直接滚动到哪里的，我看没什么人做，这是Windows特性），Ctrl点击，Alt点击这些更加小众的特性也不会有人关心的。
紧接着这些的是SEO。虽然现在大部分搜索引擎爬虫都已升级，能够处理SPA这种dom由js生成的网站，但是对于Canvas这种一点DOM的网页还是完全的无能为力。传统SSR页面返回HTML后，搜索引擎能够直接解析文本和链接，能量巨大；传统CSR页面至少能在执行js后产生DOM，Google可以尝试渲染并索引，能量中等；纯Canvas应用即使执行完所有js和WASM，最终也不行，能量为零。OG支持、网页存档这些功能也基本无法正常工作。
文字渲染
是的，又到了最讨厌的时候，我都不想点名了，没有几个能够正确的渲染字体，并且支持CJK变体等等高级字体特性的框架，有也不能在Web上用。输入框+IME也是同理，在移动端这种软键盘环境下还会更加抽象。
所以为什么要搞
我真的搞不懂。那炫炫技就算了，问题会LLM会也不等于你会啊，更何况这种方案对用户体验的破坏实在是太严重了。既然说现在LLM已经能把前端代替掉了，为什么不写传统前端呢？如果是将跨平台应用搬上Web，这虽然合理，但是未免太牺牲用户体验了。