浏览器能跑机器学习，你的App还在用表单思维？

2025年的浏览器已经能直接调用GPU跑物理模拟、处理音频流、甚至本地推理神经网络。但打开大多数网页，你看到的还是表单和仪表盘——就像给超跑装了拖拉机的引擎盖。

jsday开发者大会刚在博洛尼亚结束，演讲者Sylwia Lask现场演示了一个「文字爆炸」效果：输入文字→转成粒子→鼠标一划，文字炸成碎片。完全没用，但有点上瘾。背后技术组合值得拆开看：WebAssembly（网页汇编）管CPU密集计算，WebGPU（网页图形处理器接口）直接调度显卡。两者不是替代关系，是互补设计。

正方：浏览器原生API已经够用了

先看这个demo的第一阶段。文字输入后，先用普通JavaScript和Canvas 2D渲染成位图。演讲者明确说：这种任务经典API完全够用，没必要搬去别处。

这是很多人忽略的事实。浏览器花了二十年优化DOM操作和Canvas 2D，对于大部分UI场景，性能瓶颈根本不在渲染层，而在业务逻辑的垃圾代码。强行上WebAssembly反而增加编译包体积和内存开销。

数据说话：HTTP Archive统计，2024年中位网页的JavaScript体积已经膨胀到1.3MB，其中相当比例是根本没用的polyfill和重复依赖。在没搞清楚瓶颈之前，盲目追求「高性能技术栈」是典型的过早优化。

反方：但特定场景下，差距是2-3倍起步

demo的第二阶段把位图传给WebAssembly做粒子映射。演讲者跑了对照测试：同样算法，WebAssembly比JavaScript快2-3倍。而且这不是最优情况——代码故意写得复杂，让WebAssembly有事可做。

关键细节：WebAssembly跑的是预编译的低级代码，跳过了JavaScript的解析和即时编译环节。对于像素级遍历、矩阵运算这类CPU密集型任务，这个差距会进一步放大。

WebGPU的部分更激进。它不像WebGL那样套着OpenGL的抽象层，而是直接暴露现代GPU的计算管线。意味着你能用浏览器做通用GPU计算（通用图形处理器计算），不只是画图。机器学习推理、物理模拟、大规模并行数据处理，这些过去需要原生应用的场景，现在网页里就能跑。

核心判断：技术选型要看「计算密度」

演讲者的demo设计很说明问题。她没有全用新技术，而是Canvas 2D + WebAssembly + WebGPU各干各擅长的：UI渲染走经典API，像素计算走WebAssembly，并行爆炸效果走WebGPU。

这个分层思路比「全栈WebAssembly」或「纯JavaScript够用论」都更务实。判断标准只有一个：你的任务计算密度有多高？

计算密度 = 数据量 × 操作复杂度 / 延迟容忍度

表单验证、路由跳转、简单动画，计算密度低，JavaScript足够。图像滤镜、音频分析、游戏物理，密度中等，WebAssembly有优势。实时视频处理、神经网络推理、粒子系统，密度极高，必须上WebGPU甚至两者组合。

为什么这件事现在重要

两个趋势在交汇。一是浏览器能力持续扩张，WebGPU 2023年才定稿，现在Chrome、Edge、Firefox已全部支持，Safari也在跟进。二是用户对「网页版」的期待在提高，Figma、Photoshop网页版、Google Earth已经证明，浏览器能承载专业级工具。

但技术能力不等于产品决策。很多团队的问题不是「能不能用」，而是「敢不敢用」和「会不会用」。WebAssembly的学习曲线陡峭，需要理解内存管理和编译工具链；WebGPU直接暴露GPU细节，着色器代码写错直接黑屏。

演讲者的repo（github.com/sylwia-lask/text-goes-boom）和现场demo（sylwia-lask.github.io/text-goes-boom）提供了一个最小可运行样本。她特别警告：JS canvas基准测试会让CPU明显发热——这恰恰是性能对比的直观证据。

行动建议

如果你负责技术选型，下次遇到性能瓶颈时，先问自己三个问题：瓶颈在计算还是渲染？数据量是否值得搬上GPU？团队是否有能力维护非JavaScript代码？

如果三个都是yes，这个demo证明浏览器已经准备好了。如果有一个no，经典方案可能更稳妥。技术没有银弹，但有明确的适用边界——而2025年的边界，比大多数人想象的更宽。