WebAssembly’s post-MVP future
hacks.mozilla.org
WebAssembly’s post-MVP future
1–10 of 207 posts
Re: WebAssembly’s post-MVP future
#2Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals.
> Skill: 64-bit addressing
As a WASM backend implementer in an environment w/ only 32-bit addresses, I hope people don't move to 64-bit addresses too soon. Are we really reaching the limits here already?
> Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A portable WebAssembly system interface.
Yes please, but dev'd outside of WebAssembly. This is needed for interoperability between languages. Even just strings would be nice. A stdlib interface to rule them all, so to speak. If kept modular and avoided a lot of bikeshedding and had a full test suite, it could have a great benefit even outside of WASM.
Re: WebAssembly’s post-MVP future
#3WASM's gc story will be tough to outline, it's going through its own MVP cycle in omitting finalizers & weak references
Re: WebAssembly’s post-MVP future
#4The threading description is highly misleading, the current proposal being implemented is based on WebWorkers, they are not just native OS threads with a small overhead
Re: WebAssembly’s post-MVP future
#5Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals . > Skill: 64-bit addressing As a WASM backend implementer in an environment w/ only 32-bit addresses, I hope people don't move to 64-bit addresses too soon. Are we really reaching the limits here already? > Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A portable WebAssembly system interface. Yes pl…
Agreed on the stdlib concept. I'm sure people are working on it, the benefit would be massive. Just the amount of mobile data transfer that could be saved by 1MB of software pre-distributed to all browsers would be huge.
I wonder if anyone is trying to do it based on the javascript integrity hashes. In theory, if you took the top 100 javascript libraries and established a blessed build pipeline that would produce reference builds that would be bundled to the browser, and if anyone loaded a resource with an integrity hash matching the browser's pre-installed versions, it could just load from disk instead. That would give people who can tolerate less frequent library releases the ability to use all that functionality without networking related page load costs, and would provide a fallback since CDN's could host the file anyway if the browser doesn't have it.
Re: WebAssembly’s post-MVP future
#6Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals . > Skill: 64-bit addressing As a WASM backend implementer in an environment w/ only 32-bit addresses, I hope people don't move to 64-bit addresses too soon. Are we really reaching the limits here already? > Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A portable WebAssembly system interface. Yes pl…
I've been following wasmjit quite closely and they are implementing a PWSIX interface for WebAssembly.
Re: WebAssembly’s post-MVP future
#7I wonder if eventually with some of the stuff like GC in place, you could write a javascript JIT on top of wasm. I'm only half kidding. It would be pretty neat if wasm became a kind of universal IR that different (AOT and JIT) compilers could target.
Re: WebAssembly’s post-MVP future
#8I wonder if eventually with some of the stuff like GC in place, you could write a javascript JIT on top of wasm. I'm only half kidding. It would be pretty neat if wasm became a kind of universal IR that different (AOT and JIT) compilers could target.
JIT is pretty hard to do with wasm. There's a strict separation between code and data in wasm, for security reasons. You can't jump into the heap. So the best you could do is to generate your new JITted code as a separate wasm module.
Re: WebAssembly’s post-MVP future
#9The threading description is highly misleading, the current proposal being implemented is based on WebWorkers, they are not just native OS threads with a small overhead
That's true for the "threading MVP", but there is also discussion about adding "pure wasm threads" as a follow-up which avoids worker overhead/limitations.
Re: WebAssembly’s post-MVP future
#10I wonder if eventually with some of the stuff like GC in place, you could write a javascript JIT on top of wasm. I'm only half kidding. It would be pretty neat if wasm became a kind of universal IR that different (AOT and JIT) compilers could target.
JIT is pretty hard to do with wasm. There's a strict separation between code and data in wasm, for security reasons. You can't jump into the heap. So the best you could do is to generate your new JITted code as a separate wasm module.
Ah interesting, thanks for clarifying. I'm way out of my depth here, but this could become possible if a future version of wasm provided the option to dynamically load code? After some googling, that's what this [1] seems to be talking about.
[1] https://webassembly.org/docs/future-features/#platform-indep...