51–60 of 103 posts
Earlier quoted context omitted.
WebAssembly doesn't beat JavaScript in performance, and that is embarrassing.
it is faster, but there is unacceptable loss when passing data to/from js, definitely an area needing improvement (or having to do it less) https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…
I agree. This is saddening. It seems to often happen in "standard first" scenarios for some reason. I was very happy when CloudABI and POSIX were picked as prior art inspiration. Now it feels like it moved from "what would we need to get things done and achieve our goals?" to "what could be done and which goals could we achieve?" Maybe I am missing something, but are the recent changes something that people requested…
Component model enable both using one thing.
Earlier quoted context omitted.
less copying and more keeping in the spirit of, as it has clearly shown it is a model that is built to last
That's like saying "the US Constitution has clearly shown it's a model that is built to last" Sometimes bad designs stick around due to pure inertia
Since this is related to Webassembly, Browsers, the Web. The web has a lot of historically baggage, that one might have to work around at times, sometimes more sometimes less. There are good bits and not so good bits and in the end a lot of the time more modern web applications (whether you think they are good or bad) as well as web browsers jump through hoops to do things. For many applications there would be better protocols. But it became the dominant standard, a standard that is actually being used a lot and that is why it has become a success story. It wasn't a hundred times better than everything else. It simply was something that people managed to implement successfully and something where they were willing to deal with shortcomings, because there are great benefits in implementing the same standard as everyone else.
Don't know much about the US constitution, but it seems that it was largely good enough to make people work together that otherwise might have ended up fighting each other. That's what you'd get if everyone had a different idea about what a good constitution is. Maybe things are unclear, and maybe there are uproars because of things, but it doesn't even get to that if people don't agree on a standard or a constitution in first place.
And while over the years I often imagined how great it would be if everyone just used that better standard that has been there for a long time and nobody uses and is completely forgotten, if it ever had any popularity, then everything would be so much better and greater and I wouldn't have to do that senseless thing I am doing now. But if that standard doesn't allow for people to agree with it by implementing it it's essentially worthless (outside of maybe "prior art" consideration).
And like it or not we currently live in a world where designs persist due to pure inertia. But we know that obviously people are willing to implement these which means when a standard comes along that is similar to what already is there then having many people adapting it is realistic. Otherwise it's that super interesting university project that never makes it into anything in the real world.
Earlier quoted context omitted.
I agree. This is saddening. It seems to often happen in "standard first" scenarios for some reason. I was very happy when CloudABI and POSIX were picked as prior art inspiration. Now it feels like it moved from "what would we need to get things done and achieve our goals?" to "what could be done and which goals could we achieve?" Maybe I am missing something, but are the recent changes something that people requested…
Yes, you missed people asking for years: away to do interop between languages in WASM, a way to interact with browser APIs without JavaScript from WASM. Component model enable both using one thing.
Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…
If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.
Earlier quoted context omitted.
I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available. - Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: W…
> - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4 At 18:00 the speaker states something like "It should not be Systems Interface but Standard Interfaces" which honestly sounds like a different project. As an implementer or even as just a user in general, can it be trusted that tomorrow it isn't something completely different? Seems like an odd standard to follow. (EDIT a…
If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.
I tinkered with https://extism.org and basically the use case is that they suggest, namely you can extend software in another programming language but without having to setup a container or VMs on the client. They "just" run the code in the browser and it can be JavaScript, sure, but can also be Python, Go, whatever. It's quite specific though as I'm working on support programming in the browser. If you are not deep…
https://bytecodealliance.org/articles/WASI-0.3
The current link is just the release notes and covers only the interface-level changes. The announcement post goes into more detail on what's new in WASI 0.3, how it differs from WASI 0.2, and includes examples.
Earlier quoted context omitted.
> I was able to compile the Dart VM (the compiler + analyzer + VM) to wasm and run it on the web Is this really a representative use-case of WASM/WASI? Would'n it be much better to compile Dart to WASM (the Dart SDK even supports "dart compile wasm")?
this is a confusing question; why would it be much better to e.g. compile a C program for x86 linux musl but not the C compiler?
With Dart specifically, "dart compile wasm" already exists precisely for that purpose. Compiling the entire Dart VM (a multi-hundred-thousand-line C++ codebase) to Wasm and then running Dart inside that is a clever in-browser IDE trick, but it's heavy, indirect, and not what Wasm/WASI was designed to showcase. It also sidesteps WasmGC, which is exactly the kind of Wasm evolution that makes Dart-to-Wasm compelling.