71–80 of 110 posts
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?
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 p…
There are compelling applications for WASM in the embedded space, here we run C / C++ applications and WASM supports this well. We can also run other languages compiled to WASM too. On the server side this is less clear. Typically we don't write system level languages server side - we use other languages, like Ruby, Python, JavaScipt etc. These interpreted languages can run in WASM, but only as language interpreter i…
The jco project (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.
> These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient.
The Bytecode Alliance has made big improvements to SpiderMonkey performance on WASM/WASI systems, and has work in progress to take advantage of SpiderMonkey's "native" codegen targeting WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We targeted JS first for this work because it is the most popular language with our customers and users, but we expect that this will show the path to adding similar improvements to Ruby, Python, and other languages commonly thought of as "interpreted".
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).
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.
Earlier quoted context omitted.
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.
This is about WASI and WASI is outside the web browser.
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?
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.
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.
Earlier quoted context omitted.
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 shi…
> 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" I looked into this and... holy crap! We are there. Not for modern programs quite yet, sure, but this is amazing. You can use Windows 2000 from your browser, running inside an x86 emulator for WASM. https://copy.sh/v86/?profile=windows2000
Is is kinda heavy? Yeah. The hard disk footprint is substantial. But it works fine for writing some Python, compiling a few dependencies and bringing up a browser to test stuff. Even on a six-year-old laptop, it runs OK.
If the client application needs 1990's capabilities, "chuck it in a VM" will work today, and it will only be limited by protocol support, I/O access, and OS integration. There are substantial accessibility problems presented by VMs - seemingly basic things like clipboard support are disagreeable and require a "smart emulator" inserting itself to provide that feature.
Perhaps the right direction to take is to develop MAME to contain every accessibility feature. It already emulates all the old hardware.
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?
Yes, the component model is a standard developed under the umbrella of the W3C's WebAssembly Community Group.
That said, while it is relatively stable and hasn't changed much in the last year or so, the component model has not graduated through all the phases of the standardization process yet. It doesn't, for example, have a formal specification yet, although its canonical ABI does have a reference implementation in Python.
Earlier quoted context omitted.
This just seems like an odd way to put people down, though. Some of us are not going to know the origin of most things that we use, but the reason for that is because those things weren't successful and web assembly is (relatively).
When people are present stuff as new they should have done their research, otherwise we will never get free from the computing fashion industry. It is like microservices bandwagon nowadays, apparently distributed computing "Network is the Computer", computing agents, distributed objects, and service oriented architectures, also failed by the wayside.