4 ms·
Wasm in the browser can only communicate by going through browser APIs. Most ad / analytics / tracker blocking works by intercepting HTTP requests, so they wil
by the_duke 4y ago
Wasm in the browser can only communicate by going through browser APIs. Most ad / analytics / tracker blocking works by intercepting HTTP requests, so they will work just as well for Wasm code.
WASM that uses the regular DOM for rendering also doesn't really change blocking capabilities.
The only real issue is visual/selector based blocking when frameworks do their own rendering via canvas, webgl or webgpu. Flutter does this. But doing your own rendering comes with a lot of overhead, both in download sizes, startup time and performance.
Applications might do that (with lot's of caveats), but most websites never will. So I'm not that concerned.
Wasm is certainly much lower level than JS, but also much higher level than Assembly. It's far from an opaque binary blob. All the minified and partially even obfuscated JS is not that much better.
- chii 4y ago> but most websites never will only because it's harder to do that right now than just describing a document via html. But there will come a time when it's trivially easy to write a full app in the browser via wasm, and the outcome will be that the user can either accept or reject the entire app, rather than selectively choose the part of the app to view or use.
- paulgb 4y agoYou’re right, but it’s worth noting that nothing about that is particular to wasm. A JS app could equally avoid the DOM and render its own UI components via WebGL/WebGPU.
- lowwave 4y agowasm is just fast at doing that that's all. However, do make us to think we need another API for general JS without WebGL and GPU access.
- pmoriarty 4y ago"there will come a time when it's trivially easy to write a full app in the browser via wasm" This will be facilitated by libraries and frameworks that do all the low-level heavy lifting for the developer, who'll be able to concentrate on higher level concerns.