11 ms·

WASI 0.2.0 and Why It Matters

niutech 3y ago
Sadly, still no Framebuffer API for WASI GUI apps (https://github.com/WebAssembly/WASI/issues/174 https://github.com/WebAssembly/WASI/issues/174).
- ilaksh 3y ago
  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.
  - baq 3y ago
    I hope safari implements these things so I could reasonably run a wasm build of firefox on ios
  - phickey 3y ago
    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/WASI-12-14.md#wasi-eoy-2023-thank-you https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contributors so far. By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.md https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .
    - niutech 3y ago
      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-6f2a6fe23081 https://medium.com/wasmer/wasmer-io-devices-announcement-6f2... Is it possible to include a similar FB API in the next versions of WASI?
- nynx 3y ago
  Framebuffers aren’t really a useful abstraction anymore. They can be implemented on top of webgpu anyway.
  - niutech 3y ago
    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 <canvas> may be its implementation in web browsers. See also: https://medium.com/wasmer/wasmer-io-devices-announcement-6f2a6fe23081 https://medium.com/wasmer/wasmer-io-devices-announcement-6f2...
    - demurgos 3y ago
      > 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.
- mendyberger 3y ago
  There's something related WASI GUI apps that I've been working on for the last few months. Hope to provide details soon.
  - seanisom 3y ago
    Excited to see this! There's a need demonstrated need for WASI apps that can draw to a screen/canvas outside of a browser, and hope to see this as another community-driven contribution to WASI.
ilaksh 3y ago
That's amazing to see those things in WASI finally. But they also mention components. Does that mean components are part of the web assembly standard now? And am I correct in assuming that components are an option for projects where the functionality of WASI still isn't adequate?
- mc_woods 3y ago
  The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get existing wasi binaries to run preview2, and of course, preview2 binaries won't work on non-preview 2 runtimes...
  - flohofwoe 3y ago
    Ooof, that sounds like a mess tbh (traditionally, WASI could be described as "POSIX for WASM", and IMHO this sort of focus was just right, easy to communicate, easy to use). When reading through all the things going into WASI Preview 2 (basically "everything and the kitchen sink", except for async/await(!) which goes into Preview 3) my first thought was: ok, this is what the second-system-effect looks like in practice.
    - zilti 3y ago
      There is WASIX as a "POSIX for WASM"
    - tedmielczarek 3y ago
      I'd encourage you to read up on the component model. The talk by Luke Wagner linked in other comments is incredibly informative if you can make time to watch it. It's not about replacing WASI, it's about providing a coherent model for both implementing APIs like WASI and also providing structure and tooling for integrating codebases together in a sensible way using WebAssembly.
PedroBatista 3y ago
About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical perspective. For SO MUCH effort over a decade I feel it's more and more a nerd kingdom where it's full "of cool things" and much more work on creating and resolving problems that were solved years and decades ago and I still miss the point of all of this, I get the "big promise" but 10 years have passed and still nothing. Also, I see a lot of Rust ( and I mean a lot ) attached to Wasm. Sorry but it's not going to happen, it just isn't. Rust is a systems programming language and Wasm has been pretty much another eternal tech demo. Real "mid" - as the gen-z says - use cases and products are needed and Rust is not going to cut it for a general product audience. This whole thing seems more like a "Run Rust in the browser" than a common runtime to run every language in the browser. And since "running stuff on the browser" is kinda of old news, these new "wasm runtimes" ( which I get it and support ) in reality are basically a basic shitty proto-JVM.. again what's the point of all of this having spend 10 years? The "devx" ( always a sucker for a new marketing term :) ) is HORRIBLE! Ever tried to compile a moderately complex ( and useful ) C program to wasm? On a positive note, I wish success to Wasm/WASI because it's a cool idea and can open a lot of doors. If not for the actual reality and implementation of things, I'm optimistic about the general idea. Sorry for my "ignorance" and if I hurt anyone's feelings.
- ramses0 3y ago
  So..... think of it this way: HTML was built for the "internet", but works just as well for plain local files (eg: file:///one.html => file:///two.html). JS was added to HTML, and much gnashing of teeth ensued. JS (minified), HTML (generated), CSS (compiled), Flash, Java Applets, etc... move away from the "original" internet (Hyper-Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens". What if instead of shipping `my_application.html`, we could ship `my_application.exe`, and "break free" of needing the UI's being written in HTML, JS, CSS, etc. What some of this WASM/WASI/etc... seems to be trending towards is building up enough of a foundation amongst interoperable _CLIENTS_ that have ZERO dependency on HTML, JS, CSS, and instead you get much closer to: curl 'https://example.com/one.html' => curl 'wasm://example.com/one.app' ...to the extent that "the internet" has hit a complexity wall of what's possible (manageable, maintainable) with HTML+JS+CSS, the people tackling WASM seem to be saying: Forget trying to coerce a buggy browser into running my `for ...` loops (and rendering my graphics) correctly, and you can't realistically decompile or hand-edit the HTML+JS+CSS for 99.9% of the stuff your browser is rendering... how can we _skip_ the HTML,JS,CSS and get directly at "the VM" and run what we actually want. Secondarily (but importantly, and interestingly): How can we make 'webapp.wasm.exe' support everything that a "native" app would need (eg: GL, GPU, Bluetooth, Local Files, USB devices, Camera, Sensors, etc...) There's likely mega-trillions (no exaggeration!) of effort that's been poured into tooling for "the internet", what is the unifying effort/effect that would unlock that for local app development? How can I get `msword.exe` to run "on the internet" for free? How can I get `make clean ; make install ; make wasm` working for any internet connected client? As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator" that could conceivably run `msword.exe` transparently to the user, but still allow you to use `msword.exe` indistinguishably from the "original" native app (bridging the local filesystem, exposing virtual devices, etc). See also https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... ... circa a decade(!) ago!
pjmlp 3y ago
WASI aka redoing CLR Common Language Specification. https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://ecma-international.org/publications-and-standards/standards/ecma-335/ https://ecma-international.org/publications-and-standards/st... > This Standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consideration the unique characteristics of those environments.
- Capricorn2481 3y ago
  I've seen you comment this on a lot WASM posts (often as a criticism) so I have to ask, as someone who doesn't have knowledge of either, what is bad about this? Even if Web Assembly only has a subset of what CLR offers, isn't it a good thing a standard has been created that people are actually able to implement? If Microsoft was not aligned with developers in the early 2000's, that failure is on them.
  - pjmlp 3y ago
    Presenting as if it was the first done anyone has done any of this, UNCOL was the first time such ideas came to be, in 1958. Plenty of historical attempts to dive into, since 1958. Now we have startups redoing Java and .NET application servers, with Kubernetes, WebAssembly, WASI, and YAML spaghetti, because that is so much better. Edge devices running bytecode? That is so last century.
    - dartos 3y ago
      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.
      - pjmlp 3y ago
        De facto standard is still a standard.
deleted 3y ago
[deleted]
shadowgovt 3y ago
At a glance (at this blog post, and at the WASI project on GitHub) I still can't quite wrap my head around what WASI is and why it matters. What problem is it solving?
- arccy 3y ago
  your holy pure functions are a bit useless if they can't interact with the world (system)
- 0x457 3y ago
  WASM is a language. By itself, it's not very useful because you're limited to what language constructs provide - not much. There are extensions to the core spec for embedding wasm. For example, there is "WebAssembly JavaScript Interface" for working with wasm inside JavaScript, which is what used by browsers today. Spec we use in browser today is really just about how to interact with JS, so JS must provide everything that isn't in core: want to make an http request, then you need to call JavaScript (i.e. Fetch API) and so on. People wanted to run WASM outside the browser because it's a neat abstraction - compile one of the many languages to WASM and run it "anywhere" (yay java). Since outside the browser, we can't lean on JS for providing access to the outside world, plus that bridge has an overhead, so no bueno. WASI extends core spec with interface to outside system: - files i/o - network i/o - etc In addition, WASI has a built-in capability framework (a la Capsicum in FreeBSD which it drew inspiration from). So WASI is a interface to a host system with security and isolation in mind.
  - shadowgovt 3y ago
    Ah, okay. That is cool. It doesn't solve a problem I have (if I'm compiling to a target outside the browser, I'm going to compile to LLVM --> native, not wasm) but I respect why that's exciting.
    - v7n 3y ago
      You can write a program that has the capability to run isolated WASM modules written by others, without caring about the source language. Export some functions from your host program and you have a neat system for, say, user-written extensions.
andoband 3y ago
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/ https://blog.sunfishcode.online/wasi-preview2/
- dom96 3y ago
  Thanks for sharing. I often wondered why we didn’t just create a subset of POSIX for the web and wasm, this seems to answer my questions.
  - elviejo 3y ago
    Other team ask themselves that question and created WASIX. I'm looking into it. Because to me it seems only logical, to have POSIX that can work on the web.
    - 0x457 3y ago
      This is about WASI and WASI is outside the web browser.
      - phickey 3y ago
        WASI Co-chair here: WASI is for the Web as well as beyond. The jco project (https://github.com/BytecodeAlliance/jco https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.
- jauntywundrkind 3y ago
  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 https://youtu.be/tAACYA1Mwv4
6gvONxR4sf7o 3y ago
I really want polyglot programming to become easier. What are the barriers remaining for wasm/wasi to provide a foundation for a truly polyglot FFI? It seems like it was the promise from the beginning, but I lost track a long time ago.
- noworriesnate 3y ago
  Extism is a polyglot plugin framework that has support for a lot of languages. It supports passing strings back and forth but that’s it for now IIUC. I’ve started incorporating it into a project of mine and really like it.
- jauntywundrkind 3y ago
  Now that there's a canonical ABI as specified by component-model, it seems like the good work can start. As recommended elsewhere in the comments, there's a pretty damned fine talk my Luke Wagner that covers wasm components & the promise. He talks about cross-platform was 18m35s in: https://youtu.be/tAACYA1Mwv4#t=18m35s https://youtu.be/tAACYA1Mwv4#t=18m35s
- n42 3y ago
  I’m by no means an expert here, but it seems with WASI preview 2, component model, and GC all converging around the same time, things are looking more optimistic than ever
- childintime 3y ago
  Fermyon is practicing it. Initial stages, awaiting finalization of the standards, but it works.
spankalee 3y ago
I'll be very happy when Preview 3 with async support is out. GC + async makes WASM a suitable runtime for languages like JavaScript and Dart so that we don't have to have JS + WASM runtimes where the JS doesn't integrate with WASI well, or WASI runtimes that don't support JS that well (compiling SpiderMonkey to WASM isn't great).
- phickey 3y ago
  We have already made big improvements in using SpiderMonkey on WASM, and have more work in progress that will enable SpiderMonkey to have "native"-like codegen for WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/ https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/ An additional benefit of using a fast JS runtime inside of WASM, even on a WASM engine that natively supports JS, is to use a Wasm Component as a security boundary around JS code. This could be used as an means of isolating supply-chain security issues, or allowing users to provide (untrusted) JS code that extends an existing system while having a clear and strong boundary on how untrusted JS code can affect the host JS code.
zilti 3y ago
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.
- niutech 3y ago
  This is called PWAs. They are easily installable and can contain WASM.
  - zilti 3y ago
    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.
    - GeneralMaximus 3y ago
      JavaFX programs needed the Java runtime too, and they were still just Java apps. How is the JRE different from Safari or Edge? Or is my understanding of JavaFX incorrect, and it somehow turned applets into native binaries when you dragged them out of the browser?
      - niutech 3y ago
        That's correct, JavaFX needs JRE, as well as Java Web Start.
ImHereToVote 3y ago
Does anyone know if there are discussions on integrating WebAssembly into actual OS's? Would be great to have something that Java promised to be, but wasn't.
MR4D 3y ago
> "The simplest “hello world” example looks like..." And then gives code that reminds me of Enterprise JavaBeans from the early 2000's. Thankfully, later on we get: > "Let me show you an example of the ideal Wasm hello world application..." And then have code that's clean, logical, and simple to read. TBH, I almost gave up after seeing that first bit of code, but thankfully I kept reading. Having a standard interface will go a long way to creating a very nice future.
andybug 3y ago
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 needs to be passed by reference. To that end, I've implemented Resources. However, getting data out of a resource still requires copying (wasm-bindgen makes the return types from accessors owned Vec<>). I've resorted to just passing u32 memory offsets since all of the modules are sharing one Memory. Would love some guidance on this as I've scoured the Internet and simply can't find the right solution, if there even is one.
- phickey 3y ago
  The bytecode alliance zulip is the best place to discuss that: https://bytecodealliance.zulipchat.com/ https://bytecodealliance.zulipchat.com/

Sadly, still no Framebuffer API for WASI GUI apps (https://github.com/WebAssembly/WASI/issues/174 https://github.com/WebAssembly/WASI/issues/174).

ilaksh 3y ago
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.
- baq 3y ago
  I hope safari implements these things so I could reasonably run a wasm build of firefox on ios
- phickey 3y ago
  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/WASI-12-14.md#wasi-eoy-2023-thank-you https://github.com/WebAssembly/meetings/blob/main/wasi/2023/... . That is a great growth for our project from a few years ago when that issue was filed, but as you can see from what people are working on, its all much more foundational pieces than a graphics interface. Also, if you look at who is employing those contributors, its largely vendors who are interested in WASI in the context of serverless. That doesn't mean WASI is limited to only serverless, but that has been the focus from contributors so far. By rolling out WASI on top of the WASM Component Model we have built a sound foundation for creating WASI proposals that support more problem domains, such as embedded systems (@mc_woods and his colleagues are helping with this), or graphics if someone is interested in putting in the work. Our guide to how to create proposals is found here: https://github.com/WebAssembly/WASI/blob/main/Contributing.md https://github.com/WebAssembly/WASI/blob/main/Contributing.m... .
  - niutech 3y ago
    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-6f2a6fe23081 https://medium.com/wasmer/wasmer-io-devices-announcement-6f2... Is it possible to include a similar FB API in the next versions of WASI?
nynx 3y ago
Framebuffers aren’t really a useful abstraction anymore. They can be implemented on top of webgpu anyway.
- niutech 3y ago
  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 <canvas> may be its implementation in web browsers. See also: https://medium.com/wasmer/wasmer-io-devices-announcement-6f2a6fe23081 https://medium.com/wasmer/wasmer-io-devices-announcement-6f2...
  - demurgos 3y ago
    > 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.
mendyberger 3y ago
There's something related WASI GUI apps that I've been working on for the last few months. Hope to provide details soon.
- seanisom 3y ago
  Excited to see this! There's a need demonstrated need for WASI apps that can draw to a screen/canvas outside of a browser, and hope to see this as another community-driven contribution to WASI.

ilaksh 3y ago

That's amazing to see those things in WASI finally. But they also mention components. Does that mean components are part of the web assembly standard now? And am I correct in assuming that components are an option for projects where the functionality of WASI still isn't adequate?

mc_woods 3y ago
The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get existing wasi binaries to run preview2, and of course, preview2 binaries won't work on non-preview 2 runtimes...
- flohofwoe 3y ago
  Ooof, that sounds like a mess tbh (traditionally, WASI could be described as "POSIX for WASM", and IMHO this sort of focus was just right, easy to communicate, easy to use). When reading through all the things going into WASI Preview 2 (basically "everything and the kitchen sink", except for async/await(!) which goes into Preview 3) my first thought was: ok, this is what the second-system-effect looks like in practice.
  - zilti 3y ago
    There is WASIX as a "POSIX for WASM"
  - tedmielczarek 3y ago
    I'd encourage you to read up on the component model. The talk by Luke Wagner linked in other comments is incredibly informative if you can make time to watch it. It's not about replacing WASI, it's about providing a coherent model for both implementing APIs like WASI and also providing structure and tooling for integrating codebases together in a sensible way using WebAssembly.

PedroBatista 3y ago

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical perspective. For SO MUCH effort over a decade I feel it's more and more a nerd kingdom where it's full "of cool things" and much more work on creating and resolving problems that were solved years and decades ago and I still miss the point of all of this, I get the "big promise" but 10 years have passed and still nothing. Also, I see a lot of Rust ( and I mean a lot ) attached to Wasm. Sorry but it's not going to happen, it just isn't. Rust is a systems programming language and Wasm has been pretty much another eternal tech demo. Real "mid" - as the gen-z says - use cases and products are needed and Rust is not going to cut it for a general product audience. This whole thing seems more like a "Run Rust in the browser" than a common runtime to run every language in the browser. And since "running stuff on the browser" is kinda of old news, these new "wasm runtimes" ( which I get it and support ) in reality are basically a basic shitty proto-JVM.. again what's the point of all of this having spend 10 years? The "devx" ( always a sucker for a new marketing term :) ) is HORRIBLE! Ever tried to compile a moderately complex ( and useful ) C program to wasm? On a positive note, I wish success to Wasm/WASI because it's a cool idea and can open a lot of doors. If not for the actual reality and implementation of things, I'm optimistic about the general idea. Sorry for my "ignorance" and if I hurt anyone's feelings.

ramses0 3y ago
So..... think of it this way: HTML was built for the "internet", but works just as well for plain local files (eg: file:///one.html => file:///two.html). JS was added to HTML, and much gnashing of teeth ensued. JS (minified), HTML (generated), CSS (compiled), Flash, Java Applets, etc... move away from the "original" internet (Hyper-Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens". What if instead of shipping `my_application.html`, we could ship `my_application.exe`, and "break free" of needing the UI's being written in HTML, JS, CSS, etc. What some of this WASM/WASI/etc... seems to be trending towards is building up enough of a foundation amongst interoperable _CLIENTS_ that have ZERO dependency on HTML, JS, CSS, and instead you get much closer to: curl 'https://example.com/one.html' => curl 'wasm://example.com/one.app' ...to the extent that "the internet" has hit a complexity wall of what's possible (manageable, maintainable) with HTML+JS+CSS, the people tackling WASM seem to be saying: Forget trying to coerce a buggy browser into running my `for ...` loops (and rendering my graphics) correctly, and you can't realistically decompile or hand-edit the HTML+JS+CSS for 99.9% of the stuff your browser is rendering... how can we _skip_ the HTML,JS,CSS and get directly at "the VM" and run what we actually want. Secondarily (but importantly, and interestingly): How can we make 'webapp.wasm.exe' support everything that a "native" app would need (eg: GL, GPU, Bluetooth, Local Files, USB devices, Camera, Sensors, etc...) There's likely mega-trillions (no exaggeration!) of effort that's been poured into tooling for "the internet", what is the unifying effort/effect that would unlock that for local app development? How can I get `msword.exe` to run "on the internet" for free? How can I get `make clean ; make install ; make wasm` working for any internet connected client? As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator" that could conceivably run `msword.exe` transparently to the user, but still allow you to use `msword.exe` indistinguishably from the "original" native app (bridging the local filesystem, exposing virtual devices, etc). See also https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... ... circa a decade(!) ago!

pjmlp 3y ago

WASI aka redoing CLR Common Language Specification. https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://ecma-international.org/publications-and-standards/standards/ecma-335/ https://ecma-international.org/publications-and-standards/st... > This Standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consideration the unique characteristics of those environments.

Capricorn2481 3y ago
I've seen you comment this on a lot WASM posts (often as a criticism) so I have to ask, as someone who doesn't have knowledge of either, what is bad about this? Even if Web Assembly only has a subset of what CLR offers, isn't it a good thing a standard has been created that people are actually able to implement? If Microsoft was not aligned with developers in the early 2000's, that failure is on them.
- pjmlp 3y ago
  Presenting as if it was the first done anyone has done any of this, UNCOL was the first time such ideas came to be, in 1958. Plenty of historical attempts to dive into, since 1958. Now we have startups redoing Java and .NET application servers, with Kubernetes, WebAssembly, WASI, and YAML spaghetti, because that is so much better. Edge devices running bytecode? That is so last century.
  - dartos 3y ago
    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.
    - pjmlp 3y ago
      De facto standard is still a standard.

deleted 3y ago

[deleted]

shadowgovt 3y ago

At a glance (at this blog post, and at the WASI project on GitHub) I still can't quite wrap my head around what WASI is and why it matters. What problem is it solving?

arccy 3y ago
your holy pure functions are a bit useless if they can't interact with the world (system)
0x457 3y ago
WASM is a language. By itself, it's not very useful because you're limited to what language constructs provide - not much. There are extensions to the core spec for embedding wasm. For example, there is "WebAssembly JavaScript Interface" for working with wasm inside JavaScript, which is what used by browsers today. Spec we use in browser today is really just about how to interact with JS, so JS must provide everything that isn't in core: want to make an http request, then you need to call JavaScript (i.e. Fetch API) and so on. People wanted to run WASM outside the browser because it's a neat abstraction - compile one of the many languages to WASM and run it "anywhere" (yay java). Since outside the browser, we can't lean on JS for providing access to the outside world, plus that bridge has an overhead, so no bueno. WASI extends core spec with interface to outside system: - files i/o - network i/o - etc In addition, WASI has a built-in capability framework (a la Capsicum in FreeBSD which it drew inspiration from). So WASI is a interface to a host system with security and isolation in mind.
- shadowgovt 3y ago
  Ah, okay. That is cool. It doesn't solve a problem I have (if I'm compiling to a target outside the browser, I'm going to compile to LLVM --> native, not wasm) but I respect why that's exciting.
  - v7n 3y ago
    You can write a program that has the capability to run isolated WASM modules written by others, without caring about the source language. Export some functions from your host program and you have a neat system for, say, user-written extensions.

andoband 3y ago

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/ https://blog.sunfishcode.online/wasi-preview2/

dom96 3y ago
Thanks for sharing. I often wondered why we didn’t just create a subset of POSIX for the web and wasm, this seems to answer my questions.
- elviejo 3y ago
  Other team ask themselves that question and created WASIX. I'm looking into it. Because to me it seems only logical, to have POSIX that can work on the web.
  - 0x457 3y ago
    This is about WASI and WASI is outside the web browser.
    - phickey 3y ago
      WASI Co-chair here: WASI is for the Web as well as beyond. The jco project (https://github.com/BytecodeAlliance/jco https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.
jauntywundrkind 3y ago
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 https://youtu.be/tAACYA1Mwv4

6gvONxR4sf7o 3y ago

I really want polyglot programming to become easier. What are the barriers remaining for wasm/wasi to provide a foundation for a truly polyglot FFI? It seems like it was the promise from the beginning, but I lost track a long time ago.

noworriesnate 3y ago
Extism is a polyglot plugin framework that has support for a lot of languages. It supports passing strings back and forth but that’s it for now IIUC. I’ve started incorporating it into a project of mine and really like it.
jauntywundrkind 3y ago
Now that there's a canonical ABI as specified by component-model, it seems like the good work can start. As recommended elsewhere in the comments, there's a pretty damned fine talk my Luke Wagner that covers wasm components & the promise. He talks about cross-platform was 18m35s in: https://youtu.be/tAACYA1Mwv4#t=18m35s https://youtu.be/tAACYA1Mwv4#t=18m35s
n42 3y ago
I’m by no means an expert here, but it seems with WASI preview 2, component model, and GC all converging around the same time, things are looking more optimistic than ever
childintime 3y ago
Fermyon is practicing it. Initial stages, awaiting finalization of the standards, but it works.

spankalee 3y ago

I'll be very happy when Preview 3 with async support is out. GC + async makes WASM a suitable runtime for languages like JavaScript and Dart so that we don't have to have JS + WASM runtimes where the JS doesn't integrate with WASI well, or WASI runtimes that don't support JS that well (compiling SpiderMonkey to WASM isn't great).

phickey 3y ago
We have already made big improvements in using SpiderMonkey on WASM, and have more work in progress that will enable SpiderMonkey to have "native"-like codegen for WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/ https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/ An additional benefit of using a fast JS runtime inside of WASM, even on a WASM engine that natively supports JS, is to use a Wasm Component as a security boundary around JS code. This could be used as an means of isolating supply-chain security issues, or allowing users to provide (untrusted) JS code that extends an existing system while having a clear and strong boundary on how untrusted JS code can affect the host JS code.

zilti 3y ago

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.

niutech 3y ago
This is called PWAs. They are easily installable and can contain WASM.
- zilti 3y ago
  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.
  - GeneralMaximus 3y ago
    JavaFX programs needed the Java runtime too, and they were still just Java apps. How is the JRE different from Safari or Edge? Or is my understanding of JavaFX incorrect, and it somehow turned applets into native binaries when you dragged them out of the browser?
    - niutech 3y ago
      That's correct, JavaFX needs JRE, as well as Java Web Start.

ImHereToVote 3y ago

Does anyone know if there are discussions on integrating WebAssembly into actual OS's? Would be great to have something that Java promised to be, but wasn't.

MR4D 3y ago

> "The simplest “hello world” example looks like..." And then gives code that reminds me of Enterprise JavaBeans from the early 2000's. Thankfully, later on we get: > "Let me show you an example of the ideal Wasm hello world application..." And then have code that's clean, logical, and simple to read. TBH, I almost gave up after seeing that first bit of code, but thankfully I kept reading. Having a standard interface will go a long way to creating a very nice future.

andybug 3y ago

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 needs to be passed by reference. To that end, I've implemented Resources. However, getting data out of a resource still requires copying (wasm-bindgen makes the return types from accessors owned Vec<>). I've resorted to just passing u32 memory offsets since all of the modules are sharing one Memory. Would love some guidance on this as I've scoured the Internet and simply can't find the right solution, if there even is one.

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