Props to the team, this is great work. I've been trialing Preview 2 for the last couple of months to good results. I do have one problem though and can't seem to find a good way forward. My use case is to use WASM for the data processing modules in a tile-based simulation game/engine. This involves passing around large (many MB) buffers. For any semblance of performance the data cannot be copied between modules and n…
WASI 0.2.0 and Why It Matters
91–100 of 110 posts
Re: WASI 0.2.0 and Why It Matters
#92Sadly, still no Framebuffer API for WASI GUI apps ( https://github.com/WebAssembly/WASI/issues/174 ).
Framebuffers aren’t really a useful abstraction anymore. They can be implemented on top of webgpu anyway.
Re: WASI 0.2.0 and Why It Matters
#93Earlier quoted context omitted.
I have always suspected that sort of thing is somehow blocked by Google because it would make mean web assembly runtimes don't need web browsers. Although now that there is actually a significant update to WASI, perhaps it's possible that they are just actually that slow? Or maybe both are true. Probably I am just a "conspiracy nut". I mean I definitely am, but in this case it might just be paranoia.
WASI Co-chair here. Nothing in WASI is "somehow blocked by Google", or indeed blocked by anyone at all. Graphics support in WASI hasn't been developed simply because nobody has put energy into developing graphics support in WASI. At the end of 2023 we counted around 40 contributors who have been working on WASI specifications and implementations: https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That…
Re: WASI 0.2.0 and Why It Matters
#94I wish we'd get what JavaFX promised: Programs running in the browser that can be installed by simply dragging them out of the browser.
Re: WASI 0.2.0 and Why It Matters
#95Earlier quoted context omitted.
Framebuffers aren’t really a useful abstraction anymore. They can be implemented on top of webgpu anyway.
WebGPU is only in web browsers and WASM runs everywhere. There should be a standard cross-platform API for WASM GUI apps. Framebuffer is the lowest common denominator and may be its implementation in web browsers. See also: https://medium.com/wasmer/wasmer-io-devices-announcement-6f2...
"Web" indicates where it started / was standardized, not where it runs. WebAssembly runs everywhere, WebGPU does too.
Re: WASI 0.2.0 and Why It Matters
#96I wish we'd get what JavaFX promised: Programs running in the browser that can be installed by simply dragging them out of the browser.
This is called PWAs. They are easily installable and can contain WASM.
Re: WASI 0.2.0 and Why It Matters
#97Another good write-up which gives more context to this release, and it touches on POSIX in relation to the component model. https://blog.sunfishcode.online/wasi-preview2/
This does such a good job laying out the real fundamentals of what's happening. Capabilities model, component-model; it's well covered and nicely tied together. The WasmCom keynote What is a component? (and why?) by Luke Wagner is also a great intro. https://youtu.be/tAACYA1Mwv4
Luke crushed it.
Re: WASI 0.2.0 and Why It Matters
#98Earlier quoted context omitted.
Pardon me, I thought there was some rigor involved, my mistake.
Papers are not the only way to show rigor and are not even sufficient. Should we insult you with a huge list of rigorous enough things that were not designed in a paper? Or perhaps a list of unrigorous papers? I hope you are not using a computer with a common OS and the tools it comes with because you might be in for some sadness and sorrow. Or maybe your snark is unwarranted and you should take a step back on this.…
Re: WASI 0.2.0 and Why It Matters
#99Earlier quoted context omitted.
Doesn't change the fact it was done before, and it is only the most recent example, plenty of bytecode formats to explore since 1958.
I'm answering a comment of yours that exclusively mentions CLI. You can't blame anyone for not reusing the un-reusable. You are not contradicting me on this so let's forget about CLI, it doesn't matter it was done before since it's not a viable option or wasn't at the time WASI was being created. Or actually refute this if you think this is wrong. Now, you are extending the scope to "all bytecode formats ever created…
Whatever you consider me to be, it is your opinion, keep it for yourself, share it with the world, whatever.
Re: WASI 0.2.0 and Why It Matters
#100Earlier quoted context omitted.
What’s old is new again. Edge devices running bytecode has its uses. Being an old idea doesn’t discredit it (neural networks were first described in the 70s) At least WASI is a standard unlike flash or Java applets.
De facto standard is still a standard.