Live data from Hacker News

WASI 0.2.0 and Why It Matters

wasmcloud.com

91–100 of 110 posts

Re: WASI 0.2.0 and Why It Matters

#91
post #90

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…

The bytecode alliance zulip is the best place to discuss that: https://bytecodealliance.zulipchat.com/

Re: WASI 0.2.0 and Why It Matters

#92
post #5
post #2

Sadly, 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.

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...

Re: WASI 0.2.0 and Why It Matters

#93
post #70
post #4

Earlier 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…

Thanks for your explanation! Could you please have a look at this proposal of I/O Devices? https://medium.com/wasmer/wasmer-io-devices-announcement-6f2... Is it possible to include a similar FB API in the next versions of WASI?

Re: WASI 0.2.0 and Why It Matters

#95
post #92
post #5

Earlier 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...

> WebGPU is only in web browsers and WASM runs everywhere.

"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

#96
post #94
post #68

I 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.

No. PWAs are not a thing on desktops, they still need the entire browser, and they are still just a browser page. That's a far cry from what JavaFX enabled.

Re: WASI 0.2.0 and Why It Matters

#97

Another 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

If you are looking for one video in this thread to watch this is it. ^

Luke crushed it.

Re: WASI 0.2.0 and Why It Matters

#98
post #89
post #61

Earlier 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.…

I have a think skin, something that appears to be missing on current cancellation culture.

Re: WASI 0.2.0 and Why It Matters

#99
post #87
post #54

Earlier 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…

I don't have time to waste teaching history of bytecodes to those that think WebAssembly is the be all, end all of bytecode formats.

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

#100
post #51
post #29

Earlier 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.

[deleted]
Post reply on HN