「浏览器已经能跑复杂计算、调用GPU、处理音频、模拟物理、甚至运行机器学习模型了。」这是Sylwia Łaś在jsday大会后的感慨。但紧接着是一个扎心的转折：「可大多数时候，我们还是把它当成填表单、看仪表盘的工具。」
这句话像一根刺。我们花了二十年把浏览器喂成一头性能怪兽，结果大多数人还在用上世纪的思路写代码。
Łaś做了一件很工程师的事：不是写篇文章抱怨，而是直接造了个「完全没用但有点上瘾」的Demo。你输入文字，文字变成粒子，鼠标一拖——炸了。就这么简单的东西，背后藏着WebAssembly和WebGPU的联手演出。
WebAssembly和WebGPU：一对被拆散的设计
这两个技术经常被分开讨论，但Łaś坚持要把它们绑在一起说。原因很简单：它们天生互补。
WebAssembly（网页汇编）跑在CPU上，让浏览器能直接执行编译后的底层代码。WebGPU则打开GPU的大门，而且是「相对直接、相当强力」的那种开放，不是过去那种遮遮掩掩的抽象层。
CPU负责串行逻辑，GPU擅长并行暴力。一个管怎么算，一个管算多快。分开聊容易掉进「这个能替代JavaScript吗」的无聊争论，合在一起才能看见真正的可能性。
Łaś的Demo分三步走：第一步用原生Canvas 2D把文字渲成位图——这里经典API完全够用，没必要硬上新技术；第二步把位图丢进WebAssembly，跑一个「故意过度设计」的粒子映射算法；第三步，GPU接管渲染。
中间那步特意做得复杂，就为了逼WebAssembly干点重活。结果Benchmark出来：比纯JavaScript实现快2-3倍。而且这还不是最优情况——代码里还留着不少可以优化的空间。
正方：浏览器原生性能已经过剩
支持这一派的人会搬出Łaś的第一组数据。她的粒子系统里，纯JavaScript版本在普通笔记本上能跑多少帧？没明说，但「2-3倍提升」暗示 baseline 并不差。换句话说，现代浏览器的JavaScript引擎（V8、SpiderMonkey、JavaScriptCore）已经被优化到了极致。
他们的论据很实际：大多数应用根本碰不到性能天花板。表单验证、数据可视化、甚至轻量级的图像处理，JavaScript足够流畅。强行引入WebAssembly和WebGPU，反而增加构建复杂度、调试难度、和团队学习成本。
更关键的是生态惯性。npm上有超过200万个包，绝大多数假设你在写JavaScript。WebAssembly的模块系统、内存管理、和宿主环境的交互，每一步都是摩擦。WebGPU更惨——API设计还在快速迭代，今天写的代码明年可能就要重写。
这一派的结论是：新技术是「可以但没必要」。除非你在做Figma级别的图形编辑器、或者Photoshop级别的图像处理，否则别折腾。
反方：我们严重低估了用户的期待
反对派会指着Łaś的Demo说：看见没？这只是个「完全没用」的文字爆炸效果，就已经能榨出2-3倍性能差。如果是真正吃算力的场景呢？
他们列出的战场很具体：浏览器里的实时视频编辑、端侧AI推理（比如Stable Diffusion的Web版）、千人同屏的协作白板、基于物理的3D模拟。这些不是「未来可能」，是已经有人在做的「现在进行式」。
Figma用了WebAssembly，Notion的同步引擎有Rust重写版本，Adobe把Photoshop搬进了浏览器。这些不是炫技，是商业决策——当竞品能做到「秒开、秒渲、秒响应」时，用户的耐心阈值被永久抬高了。
更深层的论点关于「平台能力」的重新定义。浏览器曾经是「能跑就行」的轻量容器，现在它是唯一真正的跨平台运行时。iOS、Android、Windows、macOS、Linux、甚至游戏主机，都有浏览器。掌握WebAssembly+WebGPU，等于用一套代码打通所有硬件加速能力。
这一派承认门槛高，但反驳也很干脆：2008年写Ajax也很痛苦，2013年学React也被人骂过度工程。技术曲线的陡峭是暂时的，先发优势是永久的。
我的判断：性能不是奢侈品，是分层策略
两派都有道理，但都在犯同一个错误：把「用不用」当成二元选择。
Łaś的Demo其实给出了更聪明的答案——分层。Canvas 2D做它擅长的事，WebAssembly啃硬骨头，WebGPU管暴力并行。没有为了技术而技术，每个环节都问了一句：这里是不是瓶颈？
这才是2025年该有的工程思维。不是「全栈WebAssembly」或「纯JavaScript原教旨」，而是「哪里卡，就换哪里的引擎」。
具体建议可以拆成三条：
第一，建立性能基线。在动手优化前，用Chrome DevTools的Performance面板跑一遍，确认瓶颈真的在计算而非网络或渲染。Łaś的2-3倍提升建立在一个前提上：她先证明了粒子映射确实是热点。
第二，WebAssembly的切入点是「移植」而非「重写」。如果你有成熟的C++/Rust代码库（图像编解码、加密算法、物理引擎），编译到WASM是低风险高回报。从零开始用AssemblyScript写业务逻辑？大概率是过度工程。
第三，WebGPU目前只适合两类人：图形/ML领域的专家，或者有明确计算密集型需求的团队。API还在变，调试工具还在长，普通团队进去就是当小白鼠。但如果你有3D渲染、矩阵运算、或神经网络推理的需求，现在入场不算早——因为等生态成熟，竞争格局也固化了。
一个被忽视的变量：热力学
Łaś在Demo链接后面加了个括号备注：「JS canvas benchmark可能让你的CPU相当暖和」。这看似玩笑，其实是性能优化的隐藏维度。
2-3倍的速度提升，往往意味着2-3倍的功耗。在插电的桌面端无所谓，在笔记本电池、手机、平板上就是生死线。WebAssembly的CPU效率通常优于JavaScript，但WebGPU的GPU调用是另一回事——移动端的GPU有严格的功耗墙，撞上去就降频，性能曲线断崖式下跌。
这意味着「快」和「省」有时候是矛盾的。Łaś的Demo没提功耗数据，但真实的工程决策必须考虑。一个「更快」但「更烫」的方案，在移动场景可能不如「够快且凉快」的保守实现。
这也解释了为什么分层策略更务实：让合适的硬件干合适的活，而不是把所有压力堆到单一计算单元。
为什么这件事现在重要
浏览器正在经历一场静默的「运行时升级」。WebAssembly和WebGPU不是两个孤立的技术点，它们共同定义了一个新的能力边界：浏览器可以承载的应用复杂度，正在从「网页」向「原生应用」逼近。
这个变化的商业含义被低估了。当Photoshop能在浏览器里跑，Adobe的订阅模式就从「软件销售」变成了「服务入口」。当Figma证明了实时协作白板可行，Miro、FigJam、乃至Notion的路线图都被迫调整。性能不再是技术团队的KPI，是产品定义的边界条件。
更隐蔽的影响在人才市场。会写React和会调WASM内存布局的工程师，薪资曲线正在分叉。不是后者一定更好，而是后者的稀缺性在上升——因为门槛确实高，且需求确实在涨。
Łaś的Demo是个完美的隐喻：看似无用的文字爆炸，炸开的是对平台能力的重新想象。她没说的是，这种想象需要付出代价——学习成本、调试痛苦、和API过时的风险。但她也证明了，代价是可以管理的，只要你不是全盘押注，而是精准切入。
最后，如果你好奇这个「完全没用但有点上瘾」的东西长什么样，链接在这里：https://sylwia-lask.github.io/text-goes-boom/。建议用Chrome打开，拖鼠标的时候注意风扇转速——这是2025年最真实的性能Benchmark。
热门跟贴