… 总而言之，网站所有者已经对我体验的控制太多（相对于我以及像浏览器扩展程序这样的软件作者代表我行事的情况），而wasm会让他们拥有更多的控制权。如果我主要在互联网上运行复杂的应用程序，那可能还说得过去。但我并不是：我主要使用它来查找简单的数据资源，主要是由像你这样的普通人撰写的文本和网址。当任何人任何地方想要将一些信息传达给世界，并考虑如何最好地做到这一点时，99% 的时间，他们首先想到的是在互联网上发布一些文本，也许还有一段视频或其他类型的数据。我看到你刚才表达的这种情绪会妨碍这种文本或其他类型的数据流向我——通过使这个过程更加复杂，更难以由用户自定义，并给广告商之类的“中间人”更多机会从这种信息流中获利。…
源讨论LinkedIn 在两个标签页中使用了 2.4 GB 内存原帖 456 条评论 · 导入时统计这是关于“wasm不会取代JavaScript”这个论点我看到被忽视的部分，也是为什么我对实际上几乎没有进展感到如此沮丧。 对于大多数简单的应用程序来说，不需要优化，对于它们来说，JavaScript已经足够。 但是对于复杂的交互式网络应用程序来说，这真的非常重要。 想想看： - vscode - facebook - jira - linkedin - reddit 这些应用程序没有理由会慢、单线程且消耗数GB的内存——但这却是技术的限制。 我亲身知道Atlassian为了节省几毫秒的加载时间，已经花费数百万美元以不同形式构建打包工具。 只要让我用Rust编写前端，如果浏览器检测到没有JavaScript在运行——就不要启动JavaScript引擎。 顺便说一下，改善SharedWorker的体验，这样我就可以在标签页之间有效共享数据。…
完整原文把你的经验，加入这段讨论。
> 现在的情况是，我可以使用扩展程序修改网页 这与WASM没有直接关系，你真正需要的是仅DOM渲染，你理论上会拒绝使用画布和WebGL渲染。但你可以用WASM创建DOM节点。唯一的区别是WASM不太容易反编译，但我无法想象你真的会去取消压缩和修补JavaScript，对吧？
完整原文1) Wasm不会阻止你运行这些客户端脚本（例如，移除固定元素）。这仍然只是一个脚本，在页面渲染后或发生DOM变化时修改DOM。 2) Wasm使提供静态内容变得实际，因为服务器端渲染是经济的。我之前的雇主每年在SSR服务器上花费数千万美元——如果后端可以仅将客户端作为wasm运行，几乎所有的费用都会被消除。 3) 抓取器（如puppeteer）会更快且更节省资源，因为它们不需要启动JavaScript运行时来加载页面。 4) 你不用Electron应用程序吗？ 5) 你可能不用，但其他人使用丰富的交互式网络应用程序。想想这会为世界带来多少能源消耗和成本节约。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。