undefined | Better HN

0 pointssli8y ago0 comments

I am extremely unclear on whatever point you're trying to make, here, because it really does seem to come from a place of ignorance on WASM and JS. It makes no sense.

It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access, even though it's planned[1]. There are even VDOMs[2] for WASM already. Future WASM implementations that include DOM access can absolutely, and for many folks will, replace Javascript.

[1]: https://github.com/WebAssembly/design/blob/master/FAQ.md

[2]: https://github.com/mbasso/asm-dom

0 comments

austincheney8y ago

> It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access

I am not going to say never. It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority.

Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security so that people who are JavaScript challenged can feel less insecure.

tptacek8y ago

Which of the security concerns browser Javascript deals with do you think are intrinsic to the language, as opposed to the bindings the browser provides the language? If the security issues are in the bindings (ie: when and how I'll allow you to originate a request with credentials in it), those concerns are "portable" between languages.

tedunangst8y ago

Not sure if this is directly relevant, but there have been all sorts of type confusion bugs when resizing arrays, etc. Stuff in the base language. They exist independent of API, but merely because the language is exposed.

austincheney8y ago

It isn't due to the language but to context of known APIs provided to the language that can only be executed a certain way by the language.

How would a browser know to restrict a web server compiled into bytecode specifically to violate same origin? The browser only knowns to restrict this from JavaScript because such capabilities are allowed only from APIs the browser provides to JavaScript.

1 more reply

steveklabnik8y ago

> I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority.

I linked to the latest proposal downthread; people are absolutely working on this.

mr_toad8y ago

It will take more than just DOM access to replace Javascript. Just off the top of my head you'd also need access to the event loop, XHR, websockets, audio & video, webRTC, Canvas, 3D, Filesystem, cookies & storage, encryption, Web Workers and more.

j / k navigate · click thread line to collapse

0 pointssli8y ago0 comments

I am extremely unclear on whatever point you're trying to make, here, because it really does seem to come from a place of ignorance on WASM and JS. It makes no sense.

[1]: https://github.com/WebAssembly/design/blob/master/FAQ.md

[2]: https://github.com/mbasso/asm-dom

0 comments

austincheney8y ago

> It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access

I am not going to say never. It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority.

Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security so that people who are JavaScript challenged can feel less insecure.

tptacek8y ago

tedunangst8y ago

austincheney8y ago

It isn't due to the language but to context of known APIs provided to the language that can only be executed a certain way by the language.

1 more reply

steveklabnik8y ago

> I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority.

I linked to the latest proposal downthread; people are absolutely working on this.

mr_toad8y ago

j / k navigate · click thread line to collapse