【原生开发遇瓶颈，为何开发者纷纷转向Web栈做AI交互】

快速阅读：原生开发在处理简单界面时表现出色，但在面对现代 AI 聊天这种“长文本、流式渲染、富文本”的需求时，原生框架（如 SwiftUI/AppKit）反而成了枷锁。与其在底层渲染引擎的泥潭里挣扎数月，不如直接拥抱成熟的 Web 技术。

想在 macOS 上做一个支持 Markdown、能流畅滚动、还能顺手选中整条消息的 AI 聊天界面，这听起来像个基础功能，但实际做起来简直是场噩梦。

如果只用 SwiftUI，你会发现它在处理复杂的文本交互时极其笨拙。想更进一步？换成 `NSTextView` 或 TextKit 2，结果发现它们跟现代的声明式 UI 根本不兼容。当你试图把 AI 生成的文本像流水一样“流”进这些组件时，CPU 占用率会飙升，界面开始闪烁。

这让我想起计算机体系里的抽象层问题。原生框架提供了极其精细的控制权，但它们在“文本渲染”这个极其复杂的领域，提供的抽象层级太低了。渲染文本不仅仅是画几个字符，它涉及双向文本流、复杂的字形塑造、以及在文本动态增长时如何优雅地重新布局。

有网友提到，这其实是一种“技能问题”，但事实是，即使是顶尖开发者，在面对这些底层坑洞时也会感到无力。

于是，一个反直觉的路径出现了：直接用 WebKit 或 Electron。

这听起来像是向“臃肿”投降，但当你真正上手时会发现，浏览器引擎在文本处理上的积累简直是降维打击。Markdown 转 HTML、CSS 驱动的排版、成熟的文本选择逻辑，这些在原生环境下需要写数月代码的功能，在 Web 技术栈里是开箱即用的。

这并不是说 Web 技术在所有领域都完胜。Electron 的内存占用确实是个槽点，但在“生产力”与“完美主义”的博弈中，开发者往往会选择后者。

现在的困境在于，当一个时代的交互范式从“点击按钮”转向“阅读长篇流式文本”时，原生工具链的进化速度，似乎没跟上用户需求的迭代。

如果原生框架无法提供一个好用的、可组合的富文本组件，那么开发者转向 Web 技术，其实是一种极其理性的架构选择。

本质上，我们不是在选择技术，而是在选择生存效率。

justsitandgrin.im/posts/native-all-way-until-you-need-text/