你的浏览器浪费了90%的算力

WebAssembly比JavaScript快2-3倍，WebGPU能直接调用显卡——但这些技术出道多年，为什么大多数应用还在用2008年的方式跑？

jsday大会刚结束，演讲者Sylwia Lask做了一个"文字爆炸"的演示：输入文字→转成粒子→鼠标一拖，文字炸开。完全没用，但会上瘾。

这个demo的巧妙在于，它把两条技术路线拧在一起用了。不是炫技，是逼你重新思考：浏览器的边界到底在哪？

正方：浏览器早就该这么用了

演讲者的核心论据很直接。浏览器已经不是"表单和仪表盘"的工具了——它能跑复杂计算、调GPU、处理音频、模拟物理、甚至跑机器学习模型。

她的demo分三步：

第一步用原生JavaScript+Canvas 2D把文字渲染成位图。这一步故意没上新技术，因为"经典API已经足够好"。

第二步把位图丢给WebAssembly，跑一个"故意过度设计"的粒子映射算法。这里测出WASM比JS快2-3倍——而且不是最优情况，代码里还塞了些花哨操作。

第三步粒子渲染上WebGPU，直接对话显卡。

结果是：纯JavaScript方案在几百个粒子时就卡死，WASM+WebGPU能流畅跑上万个。

这个差距不是渐进优化，是数量级的。

演讲者还提到一个细节：WebGPU的API设计是"相对直接且强大"的，不是那种被层层封装后的残血版。这意味着开发者能真正控制硬件，而不是被框架牵着走。

她的判断很干脆——"大多数应用比它们需要的更慢"，不是因为硬件不够，是因为我们没在用。

反方：快2-3倍，值得折腾吗？

但反对的声音同样真实。

首先，这个demo的"有用性"被演讲者自己盖章认证："完全没用"。粒子文字爆炸能证明技术可行性，但离业务场景有多远？

大多数Web应用的核心瓶颈根本不是计算性能——是网络延迟、是DOM操作、是第三方脚本、是设计师要求的动画帧数。WebAssembly解决的是CPU密集型任务，但你的电商页面卡顿，大概率是因为埋点代码塞了太多。

其次，技术债成本被低估了。WebAssembly需要编译链路，WebGPU的着色器代码要手写，调试工具链远不如JavaScript成熟。一个需要"故意过度设计"才能看出优势的方案，在真实业务里可能意味着维护噩梦。

更隐蔽的问题是团队能力。能写高性能WASM的工程师，和能写产品级JavaScript的工程师，往往是两拨人。招聘、协作、代码审查的成本，2-3倍性能提升能覆盖吗？

还有一个演讲者没提的事实：WebGPU的浏览器支持至今不完整。Chrome和Edge可以，Safari和Firefox的支持还在推进。这意味着你写的代码，有一部分用户根本跑不了。

技术圈有个老毛病：把"能做"当成"该做"。浏览器能跑机器学习模型，不代表你的后台管理系统需要它。

我的判断：这不是性能问题，是权力问题

双方都有理，但辩论的框架本身需要拆穿。

演讲者说的"大多数应用更慢"，反方说的"不值得折腾"——这两个陈述可以同时为真。真正的分歧在于：谁在定义"需要"？

过去十年，Web开发的权力结构是框架和平台说了算。React告诉你虚拟DOM更好，Chrome DevTools告诉你怎么优化渲染管线，Webpack的配置复杂度已经超出人类理解范围。开发者越来越像管道工，在抽象层之间接水管。

WebAssembly和WebGPU的颠覆性，不在于快多少，在于它们把硬件访问权还给了开发者。这是权力结构的转移。

演讲者的demo之所以用"没用但上瘾"的场景，恰恰是在测试这个权力的边界——当技术约束被移除，你能造出什么？

这个思路对25-40岁的科技从业者特别重要。你们经历过jQuery到React的迁移，经历过移动端H5的泡沫，经历过小程序的生态割据。你们应该能识别出一种模式：每次平台能力跃迁，最先受益的不是现有应用的优化，而是全新品类的诞生。

WebGL没能让电商页面更快，但催生了浏览器里的3D设计工具。WebAssembly没加速新闻网站，但让Figma能在浏览器里跑C++写的渲染引擎。WebGPU的真正战场，可能是你现在还想象不到的应用形态。

演讲者在GitHub开源了代码，demo可以在线跑。建议你做两件事：

第一，打开控制台看性能面板，对比纯JS和WASM+WebGPU的帧率差距。数字会说话。

第二，想想你手头的产品，有没有被"浏览器只能干这个"的预设限制住。不是让你重写技术栈，是检查你的假设。

浏览器已经进化成通用计算平台，但我们的开发习惯还停在表单和仪表盘。这个gap里藏着机会——属于先动手的人。