Earlier quoted context omitted.
There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code. Of course, why not just use a small HTML+JS shim for your WASM?
Because there is value in ditching legacy cruft.
WebAssembly becomes a W3C Recommendation
71–80 of 248 posts
Re: WebAssembly becomes a W3C Recommendation
#72Earlier quoted context omitted.
I think we're still waiting for a WASM-only OS, though :)
I think I remember reading something on HN about some kind of tool for running WASM in some kind of kernel module to speed up app performance. EDIT: here it is: https://medium.com/wasmer/running-webassembly-on-the-kernel-...
Re: WebAssembly becomes a W3C Recommendation
#73i wonder what are the security implications. how many new vulnerabilities will be uncovered, machines infected, and viruses implemented in wasm. the concept of wasm doesn't really fly with zero-trust internet
Any website can already do that with asm.js. WASM does not change the security model of browsers.
Re: WebAssembly becomes a W3C Recommendation
#74i wonder what are the security implications. how many new vulnerabilities will be uncovered, machines infected, and viruses implemented in wasm. the concept of wasm doesn't really fly with zero-trust internet
Re: WebAssembly becomes a W3C Recommendation
#75Earlier quoted context omitted.
There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code. Of course, why not just use a small HTML+JS shim for your WASM?
Because there is value in ditching legacy cruft.
Re: WebAssembly becomes a W3C Recommendation
#76It's really uncanny how Gary Bernhardt predicted it all [0] a few years ago. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Seems like the obvious next step is using WebAssembly outside the browser so we can really go full-circle on this one EDIT: some quick googling shows it's already being done https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
If you want to provide a plugin or extension interface, and want to give those plugins a limited interface rather than making them all-powerful, embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language.
Also see https://hacks.mozilla.org/2019/08/webassembly-interface-type... for an illustrated description of how that'll work smoothly across languages.
Re: WebAssembly becomes a W3C Recommendation
#77Earlier quoted context omitted.
> If you knew about [x], there's nothing surprising about [y] You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
"The future will be just like the past, but with a different name". I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
Re: WebAssembly becomes a W3C Recommendation
#78Earlier quoted context omitted.
It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. Currently, JS is used as a mediator between the two - so you do need some JS (but it could well be JS that you never have to write yourself). I recall one of the spec authors saying in an HN thread that a GC would be added eventually, back in the infan…
> because the DOM and JS (meaning the GC) are very coupled. This wasn't the intention when the script tag was introduced. It's interesting that the web standardized on one programming language.