一个写了20年C++的人，把ComfyUI从浏览器里拽了出来

ComfyUI的界面跑在浏览器里，这件事被当成理所当然很久了。节点拖拽、连线、参数面板全挂在一个DOM上，工作流一大就开始发涩。

elgeminy在r/StableDiffusion发帖说，他刚开始用ComfyUI时找的第一样东西，就是一个没有浏览器延迟的原生桌面客户端。找了很久没找到，于是自己写了一个。他有20多年商业C++开发经验。

技术选型他列得很直接：一个能吃下画布上几千个节点而几乎不卡顿的UI框架，网络层用boost，数据库用sqlite，格式化用fmt。这套选型里留了移植到Linux和Mac的余地。

难点在于为什么此前所有客户端都被关在浏览器里。答案是自定义JS节点，这些节点本身又受制于Litegraph的架构。elgeminy的做法是绕过去：这些节点的内部逻辑其实不复杂，他把大部分移植成了C++。前端专属的节点，比如reroute和书签，他做了功能更全的扩展版本。

必须留在HTML/JavaScript里的部分，他隔离到一个完全独立的进程中。这样笨重的浏览器引擎就不会拖累轻量的C++核心。

项目目前到Beta，源码和Windows预编译包放在评论区，帖子里还附了一段演示视频，作者说做视频对他也是件新鲜事。有人贴出了仓库地址：https://github.com/graphn-app/Graph-N

评论区的分歧比代码本身更有意思。

有人第一反应是节点2.0终于能用了。collectedtooth404说这也许能让nodes 2.0变得可以忍受，Zueuk回得更直接，说现在的nodes 2.0基本没法用。

也有人表示用不了。Reasonable-Aide1259指出缺了前端特性兼容：为了降低工作流复杂度，现在很多人依赖只在前端生效的set和get节点；媒体加载器也重要，不只图片，还有视频和音频，尤其是minimax相关的工作流。在他的程序里，这些只显示成json结构。

还有一条质疑来自RiskyBizz216：在ComfyUI上面造这个东西没什么意义，用libtorch和sd.cpp直接写原生C++方案，性能能超过ComfyUI。FartingBob反问：那还能用ComfyUI的插件吗，还能跟着ComfyUI频繁更新去支持新模型吗。

StableLlama的态度最不客气：浏览器延迟？过去20年的新闻你可能得补一补。ComfyUI环境里坏掉的东西很多，拿浏览器做UI是最不相关的那一个。

这些反驳各有各的道理，但都绕开了作者最初的那句话：他只是在找一个自己愿意用的客户端，没找到。