longbridge/nsh

NSH 想让你只写一份界面，就能在手机、桌面和浏览器上以原生控件呈现。项目还非常早（当前版本 0.1.1），所以下面更像是对设计思路和边界的梳理，而不是可以放心上线的背书。

解决什么问题

跨平台 UI 通常只有两条路：为每个平台写原生代码，或者接受 WebView 渲染出来的界面——样子和手感都不像宿主平台。你真正想要的是共享一套组件、状态和布局规则，同时让菜单在桌面上像弹出层、在手机上像底部面板，文字输入走系统自带键盘。NSH 改的正是这一步：同一套组件分别通过 iOS 的 UIKit、Windows 的 Win32、Linux 的 GTK 4 以及网页的 HTML 渲染，同时共享响应式引擎和 flexbox/grid 布局。最后同一份代码既可作为独立应用打包，也能嵌入已有的原生应用。

有什么不同

有趣的地方在于把「怎么写」和「怎么画」拆开了。你可以整款应用都用 Rust 写，也可以用 TSX 写界面，或者混合起来让 TSX 导入 Rust 组件。TSX 这边，引擎在运行时加载模块，作者把它定位为插件和 AI 生成 UI 的载体，以签名包形式分发，在宿主配置好的沙箱里运行。一个 Rust 构建的 nsh CLI 覆盖初始化、运行、热更新和打包。

两个取舍比较明显。第一，设计上刻意不带样式：nsh/base 只提供行为和可访问结构，颜色、字体、间距和动效都由应用自己决定，TSX 侧可以借助 Tailwind 和源自 shadcn 的主题变量。这换来了应用自己的外观，代价是要自己拼一套组件库。第二，每个桌面端用自己的后端，所以 AppKit、Win32、GTK 4 之间行为可能有差异；GPUI 后端是额外目标，不是替代方案。运行时加载的签名 TSX 包是 README 描述的能力，这里无法验证它在实际使用中的表现。

谁值得试

适合：已经熟悉 Rust 和 TypeScript 的团队，要做一款在多个平台上都显得原生的应用，并且愿意基于基础原语自己把控视觉设计。「嵌入已有原生应用」的示例是它相比从零起一个工具包最有说服力的理由。不适合：想要开箱即用的完整控件、且 API 已经稳定的人。0.1.1 的阶段意味着框架还很早，而不带样式的基座意味着要做出好看的界面，前期得投入不少设计工作，之后才能体现出框架的价值。

使用条件与边界

各平台的门槛很具体：iOS 15+、Android 9（API 28）+、macOS 14+、Windows 10 1809+、Linux 需要 GTK 4.14+，GPUI 在 Linux 上还需要 Vulkan。这些限制会挡掉老旧设备，也会挡掉一些长期不升级的 Linux 桌面；为 iOS 或 Android 构建仍然需要 Xcode 或 Android SDK。Rust 路线要同时装 nsh 和 Rust，TSX 路线写代码只需要 nsh；安装方式有 macOS/Linux 的脚本、Homebrew 和 Windows 的 PowerShell。

长期维护是更值得掂量的问题。README 说明了 TSX 的热更新，但 Rust 改动需要重新构建并重启；安装脚本可以更新 CLI，以及放在 ~/.nsh/source 下的源码检出。组件行为和主题 API 是否稳定到不用频繁重写，仅凭 README 无法判断；在真正投入前，建议先看安装与平台说明和目标与设计原则。

HotRepo 点评

HotRepo 在新项目榜（rust 语言，#14）记录到 2026-10-25 共 614 个 star，覆盖范围只有 2026-10-24 到 2026-10-25 两天。这是一个带日期的快照，不是增长曲线；对一个十天天龄的仓库，仅凭两个观察日无法判断热度能否持续。设计值得一读，API 值得核对：具体要确认的是，不带样式的 nsh/base 原语加主题变量，是否足以支撑你真正要做的那些界面。