这可能是今年最让 JS 开发者激动的事情了

[zy445566]

上面是我用 JS+HTML+WebGL2 做的鹈鹕 3D 骑自行车，FPS 也非常不错。

你可能会说“这不是用 Ai 有手就行了么？”

但是，如果我说我把这上面用 xbintsc 编译成原生二进制，还不到 10MB,还能在没有 WebView 环境上跑，还能支持 Node.js 和 HTML 混写，如下：

<html>
    <body>
    <div id="out">loading...</div>
    <script lang="ts">
        import { readFileSync } from "fs";

        const out = document.getElementById("out");
        const world = readFileSync("data.txt", "utf8");
        out.textContent = "hello " + world;
    </script>
    </body>
</html>

要知道以前光 chrome 最少也得有 100MB ，用 xbintsc 编译产物 10MB 还不需要 WebView 环境，这可不仅仅代表桌面端开发体积极大减小和更加正确的实现路径的问题。

更加具有划时代意义的是，JS 开发者在嵌入式设备跑你想要做的应用成为了可能。

xbintsc 开源地址

[daysv]

那么代价是什么呢

[zy445566]

昨天看到帖子： https://v2ex.com/t/1253744
争论实现难度和技术细节，其实最不难实现的就是 JS 语法和 node 相关的 Api ，因为 JS 语法有 t39 的 test262 测试用例库(5000+道)，只要让 Ai 全部跑通就可以。难点主要是集中在视觉交互和启用 GPU 引擎上，包括中间层 Metal/Vulkan/GLSL/SPIR-V 以及视觉验证上，我这边是使用点和矩形切面验证

[idealhs]

你的意思是，你做出来了一个 Electron Mini ?

[zy445566]

@daysv 代价是你搭建多环境的编译环境会比较复杂，不过 mac 和 window 还好(mac 只要 Xcode Command Line Tools ，win 推荐 11 系统+vs2026)，ubuntu 我看到社区有人搞花了 2 周（ https://blog.csdn.net/weixin_29172963/article/details/167739404 ）

[v1]

@idealhs 不如说做了个 js 解析器+mini-webview

[daysv]

问题在于能完美覆盖所有功能吗？ Web API 那么多都能实现完美迁移吗？实现了还能保持 10MB 大小吗？

[Yaavi]

666 自研渲染引擎 + 编译器

[GPLer]

quickjs 可以把 js 编译为二进制，html + css 这个确实难搞点，不过哪怕实现出来也不能支持所有特性吧，组件库支持的怎么样？

[zy445566]

@idealhs 意思差不多，但是 Electron 的技术实现路线，我不认为正确，因为非原生编译还是存在负累

[unco020511]

html 是完整支持吗

[MarkLeeyun]

相当于用 js 做 3D 游戏吗？

[zy445566]

@daysv 我做的是按需加载模块，如果是无样式的英文(字库不需要)的界面甚至只要 3MB ，但是如果有<video>/<audio>就直接引入 ffmpeg(mini7.1 大概 7MB)也就是产物至少 10MB 起步，不同的功能所需要的大小都不一样，再比如 mac 还需要额外至少 2MB 的 Metal 驱动来启动 GPU 的 2D 视觉能力。
对于完美覆盖所有功能，这两个要分开，html 和 css 的功能其实并不算多，是可枚举的。
但是完美这个事情，主要是一致性，目前只能使用测试用例保证，目前测试用例在 github action 要跑 20 分钟，目前 1000+测试用例，后续大概率还会增加

[zy445566]

@MarkLeeyun 不是，准确来说可以把 js 做的 3D 游戏编译成二进制，并且保证体积在可控范围内

[MarkLeeyun]

感谢 OP 的耐心解答。按需加载模块这个思路很关键，也就是说体积不是固定 10MB ，而是随用到的能力（字库、ffmpeg 等）线性增长，无样式纯英文界面能压到 3MB ，这个数据挺有说服力的。

想再确认两点：
1. 按需加载是编译期裁剪还是运行时动态加载？如果是运行时，那在没有 WebView 的嵌入式环境里，模块是怎么加载进来的（打进二进制还是外挂文件）？
2. 你提到难点在视觉交互和 GPU 引擎（ Metal/Vulkan/GLSL/SPIR-V 中间层），这块目前是自研还是复用现成方案？跨平台一致性怎么保证？

另外 @daysv 问的 Web API 覆盖度，OP 说的按需加载其实已经部分回答了——不是要全量迁移，而是按需引入。期待后续能有个支持矩阵之类的说明。

[zy445566]

@unco020511
不一定，但 html 和 css 的功能其实并不算多，是可枚举的，即使有遗漏，在后续的迭代发现后也一定会逐步完善

[719579]

Tauri 也很小，至于没有 WebView 的环境的客户，那可能不是目标客户。

[ldx78203199]

划 哪个时代了。？

[qq2291482528]

又激动了

[zy445566]

@MarkLeeyun
1. 编译期，如果是运行时动态加载那体积不就没意义了么😂
2. 主要是自研，跨平台一致性主要是多平台 github action 保证(目前同时跑 macwin(x64/arm) win(x64/arm) ubuntu(x64/arm)) 6 个一起跑 1000+测试用例和自举构建打包阶段，所以产物也是多平台的

[MarkLeeyun]

感谢 OP 的耐心解答，信息量很大。几点想继续请教：

1. 按需加载是编译期裁剪这点很关键，那裁剪的粒度是怎么定的？是按 import 的模块静态分析，还是需要用户手动声明能力清单？像 <video>/<audio> 这种会直接拉进 ffmpeg （ 7MB ）的，有没有更细的裁剪空间，比如只保留解码器不保留封装/滤镜？

2. 测试用例目前 1000+、CI 跑 20 分钟，这个规模对 HTML/CSS 这种"可枚举"的规范来说其实还偏少。后续是打算按 WPT （ web-platform-tests ）的用例来对齐吗？如果对齐 WPT ，一致性验证的成本和收益你怎么权衡？

3. 视觉层自研 Metal/Vulkan/GLSL/SPIR-V 中间层，这块工作量其实比 JS 引擎大得多。有没有考虑过先接 Skia / wgpu 这类成熟后端，把精力集中在编译器上？

4. 嵌入式场景下，除了体积，内存占用和启动时间大概是什么量级？这个可能比二进制大小更影响能不能真正落地。

期待后续的支持矩阵，祝项目顺利。

[zy445566]

@MarkLeeyun
1. 这个是自动的，但是用户需要申明基本能力清单"extensions": ["gui"]，目前只有 node 和 gui 两个能力清单表面用户要使用的能力，如果申明使用 gui ，gui 就会根据标签或引用自动进行裁剪，有一个清单，几乎都是每 1MB 提升作为一个端点
2. web-platform-tests 线下可以跑，但是放到 github action 只能是选取里面几百个进行跑，就好比 t39/test262 有 5000 个用例，我选取了 200 多个核心用例来跑

清单大概如下

| 功能块 | 链接体积 |
| --- | ---: |
| FFMPEG7.1 | 7.77 MiB |
| SPIRV-Cross （ SPIR-V → MSL/GLSL ） | 2.55 MiB |
| glslang （ GLSL → SPIR-V ） | 2.36 MiB | 21.8% |
| 引擎核心（ DOM/CSS/布局/绘制/合成/window ） | 1.11 MiB |
| HarfBuzz 文本整形 | 0.99 MiB |
| SDL renderer / blit / surface / YUV | 0.84 MiB |
| FreeType 字体栅格化 | 0.59 MiB | 5.4% |
| SDL window/video/events/platform | 0.57 MiB |
| WebGL API 层（`webgl_*`、`dom_api_webgl*`） |
| SDL gamepad/joystick/HID/sensor/camera | 0.38 MiB |
| SDL GPU 后端（ Vulkan/D3D12 + 内建着色器） | 0.29 MiB |
| 图片 / SVG （ stb_image 、nanosvg ） | 0.28 MiB |
| Canvas 2D | 0.19 MiB |
| SDL audio + AudioContext 引擎 | 0.18 MiB |

[zy445566]

@zy445566 原因是 github action 有时间限制，并且太长时间拖慢迭代

[jackOff]

我也看好 web 端发展，尤其是在各大手机系统收紧对 app 的管制措施后，目前只有 web 端是最自由的

[MarkLeeyun]

楼主这个方向很有意思。想问下 xbintsc 目前的定位是「把 JS/HTML 应用打包成小体积原生二进制」的运行时，还是更偏向一个轻量的 WebView 替代品？另外 10MB 这个体积是空载运行时的大小，还是包含了一个带 WebGL2 场景的完整 demo ？如果后者的话确实挺惊人的。

[zy445566]

@MarkLeeyun
带 WebGL2 场景的完整 demo 😂

[weekidjoker]

有点标题党了吧

[tf2]

用 xbintsc 编译产物 10MB 还不需要 WebView 环境——这句话是说不用标准 webview 嵌入方式，还是系统如果彻底阉割了 webkit safar chrome chromium edge 你这 10MB 依然能渲染 html+css+canvas ？

我怎么不信呢。

[zy445566]

@tf2 嘿嘿 你可以让 Ai 用 xbintsc 编译一个产物看看我说的对不对，但是注意 xbintsc 并不完全支持 node_moudles 包括非规范的 CommonJS

[loveleyla2013]

"JS 开发者在嵌入式设备跑你想要做的应用成为了可能"
感觉要不了多久，没人会自称为是“xx 语言开发者”，大家都用 AI ，哪个语言顺手就用哪个了

[MarkLeeyun]

@tf2 补充一点：xbintsc 目前对 node_modules 的支持确实有限，尤其是非规范的 CommonJS ，所以建议先用纯 ESM + 少量依赖的 demo 试水，跑通后再逐步引入依赖，这样能更快验证产物体积和运行效果。

[Lx404]

纯标题党，专门看了一下都不能算是一个玩具项目。甚至 for 都不符合标准，GUI 这块和不能用啥区别。

[tf2]

@zy445566


dom_parse.cpp:1-8 注释
“HTML tokenizer + tree builder. … The tree builder keeps a stack of open elements and applies a small set of HTML 'implied end tag' rules, which is all a UI document needs.”


doc/gui/known-issues.md 、doc/gui/dom.md 、doc/gui/layout.md


- 支持块级布局、行内布局、Flexbox 、Grid 、position: relative/absolute/fixed 、transform 、transition 、 @keyframes 、 @media 、::before/::after 、渐变、阴影、clip-path 、filter 等
- 支持 DOM 查询、事件、innerHTML 、classList 、style 、Canvas 、SVG 、Audio 等
- 但只是 CSS 子集：background-clip 、background-position 、background-repeat 未实现；某些属性只是能解析但没有效果； SVG 只是 NanoSVG 子集；没有真浏览器级兼容


canvas webgl 也都是子集。。。你赢了。。

[Hconk]

@MarkLeeyun 感觉你的回复 AI 味好浓啊，我还以为是 lz 在自问自答了。。

[MarkLeeyun]

@Hconk 哈哈，被你发现了，确实有点那味儿。不过这个项目是我自己一行行写出来的，AI 只是帮我跑测试用例和查文档，核心的渲染引擎和编译器逻辑还是得自己啃。

[MarkLeeyun]

@Hconk hhhh ，用 ai 润色了一下哈哈哈哈哈

[imicksoft]

昨天晚上突发奇想，AI 这么厉害了，能不能发明比 chrome 套壳更好的软件开发。
AI 缺内存缺存储，成熟的 AI 应该开发出更好的开发语言和方式，以更节省内存和硬盘，这样才有更多内存和硬盘供给 AI 。

[zy445566]

@imicksoft 你这想法看来也很超前👍

[bjfane]

bun 出来和市场有了比较大的声音 就选择了 bun ，deno 安装过 没怎么用，好明智，现在 deno 进入 CF 而且不怎么维护了
虽然 bun 从 zig 改 rust 争议比较大，可能是屎山，也被 A\收购了，我用着还行 没出过什么幺蛾子。

[zy445566]

@tf2 嗯，要保证浏览器全兼容可能还需要多个迭代，目前这个项目仅开发了一个月，也希望有人可以一起参与进来，包括 webgl 其实绝大多数 API 已经实现，只剩下 transform feedback 和 MSAA/采样缓冲主要受制于 SDL 版本,且普通开发基本上用不上，所以做的保留实现

[enpitsulin]

事实上，人们根本不在乎 JS 能不能跑在嵌入式设备上 https://github.com/microsoft/devicescript 更何况现在还有一个 [pocketjs]( https://pocketjs.pocket.nexus/) 所以根本算不上具有划时代意义。

如果 ai 就能写 C ，为什么还要多一个中间步骤呢？

[enpitsulin]

@enpitsulin 当然我只是针对嵌入式设备的部分，其他的内容我不做评价

[zy445566]

@enpitsulin
1. pocketjs 这个项目不错，它是支持了 js 的编译，我觉得这个想法也挺好的，但不是使用 html 来渲染，而是使用游戏引擎来渲染，也偏游戏一点，但是 html 能让这件事情更加通用。
2. 可以用 Ai 让 C 也可以直接写界面，但是对于纯 Web 开发来说，C 并没有那么友好，所以我更想让 Web 开发能多一种选择

你的问题也不错，是有思考在里面的👍

[Tink]

说到这个，昨天看到 vercel 也开源了一个 https://github.com/vercel-labs/scriptc

[andyskaura]

很久之前用过 QuickJS ，后来发现需要海量的测试，成本太高了

[zy445566]

@Tink 他这个是纯 JS 编译，不支持 html 编译的，说来你可能不信，复杂度完全不是一个级别，也就是说 xbintsc 比 scriptc 要复杂很多，2 楼有说明为什么实现 JS 语法在 Ai 模式下简单😂

[chenluo0429]

做得好，但是我选择 electron ，以获得最小的心智负担和最大的兼容性。

[Tink]

@Hconk 就是个 ai

[gkiwi]

前端的回光返照～

[shuichengjian]

前端自嗨吧。

[sockpuppet9527]

请教下这里解决什么需求呢？如果是做 3D 游戏的话，首选绝对不会是 WebGL/WebView 把。

[studyingss]

@livid #20 的这位接了个 ai 自动回复 https://v2ex.com/member/MarkLeeyun

[mustcool]

很厉害