8 ms·

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls. But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer in between. You need a lot of inherently slow and unsafe glue code to make anything work. Part is WASM related, part of it wasm-bindgen. What were they thinking? I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often. That it fits the purpose more of heaving longer running compute in the background and bring over some chunk of data in the end. Why create a generic bytecode execution platform and limit the use case so much? Not everyone is building an in-browser crypto miner. The whole WASM story is confusing to me.

BlackFly 1y ago
My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the browser people aren't interested in. This is just my take since I am not internal to those organizations. But you have the whole web assembly component model and browsers just do not seem interested in picking that up at all. So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access. The browser is the main driving force for WASM, as I see it, because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container. So WASM doesn't really have much impetus to improve beyond compute.
- boomskats 1y ago
  > So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access I don't think this is entirely fair or accurate. This isn't how Wasm runtimes work. Making it possible for the sandbox to explicitly request specific resource access is not quite the same thing as what you're implying here. > The browser is the main driving force for WASM, as I see it This hasn't been the case for a while. In your first paragraph you yourself say that 'the people furthering WASM are [...] building a whole new VM ecosystem that the browser people aren't interested in' - if that's the case, how can the browser be the main driving force for Wasm? It's true, though, that there's verey little revenue in browser-based Wasm. There is revenue in enterprise compute. > because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container Not exactly true when you consider that docker containers are orders of magnitude bigger, slower to mirror and start up, require architecture specific binaries, are not great at actually 'containing' fallout from insecure code, supply chain vulns, etc.. The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. They just rarely make it to the hn frontpage, because they really are boring. However, the Wasm push in enterprise compute is real, and the value is real. But you're right that the ecosystem and its sponsorship is still struggling - in some part due to lack of support for the component model by the browser people. The component model support introduced in go 1.25 has been huge though, at least for the (imho bigger) enterprise compute use case, and the upcoming update to the component model (wasi p3) should make a ton of this stuff way more usable. So it's a really interesting time for Wasm.
  - serbuvlad 1y ago
    > The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. What are you talking about? Alpine container image is <5MB. Debian container image (if you really need glibc) is 30MB. wasmtime is 50MB. If a service has a multi-gig container, that is for other stuff than the Docker overhead itself, so would also be a multi-gig app for WASM too. Also, Docker images get overlayed. So if I have many Go or Rust apps running on Alpine or Debian as simple static binaries, the 5MB/30MB base system only exists once. (Same as a wasmtime binary running multiple programs).
    - rkangel 1y ago
      These numbers are true, but you'd be amazed and the number of organisations that have containers that are just based on ubuntu:latest, and don't strip package cache etc.
      - nightpool 1y ago
        Surely moving those containers to alpine would be 1000x easier than rewriting everything in wasm though.
      - serbuvlad 1y ago
        ubuntu:latest is also 30MB, like Debian. Obviously an unoptimized C++/Python stack that depends on a billion .so's (specific versions only) and pip packages is going to waste space. The advantage of containers for these apps is that it can "contain" the problem, without having to rewrite them. The "modern" languages: Go and Rust produce apps that depend either only on glibc (Rust) or on nothing at all (Rust w/ musl and Go). You can plop these binaries on any Linux system and they will "just work" (provided the kernel isn't ancient). Sure, the binaries can be fat, but it's a few dozen megabytes at the worst. This is not an issue as long as you architect around it (prefer busybox-style everything-in-a-binary to coreutils-style many-binaries). Moreover, a VM isn't much necessary, as these programming languages can be easily cross-compiled (especially Go, for which I have the most experience). Compared to C/C++ where cross-compiling is a massive pain which led to Java and it's VM dominating because it made cross-compilation unnecessary, I can run `GOOS=windows GOARCH=arm64 go build` and build a native windows arm64 binary from x86-64 Linux with nothing but the standard Go compiler. The advantage of containers for Rust and Go lies in orchestration and separation of filesystem, user, ipc etc. namespaces. Especially orchestration in a distributed (cluster) environment. These containers need nothing more than the Alpine environment, configs, static data and the binary to run. I fail to see what problem WASM is trying to solve in this space.
- pjmlp 1y ago
  Meanwhile the people using already established VM ecosystems, don't a value dropping several decades of IDEs, libraries and tools, for yet another VM redoing more or less the same, e.g. application servers in Kubernetes with WASM containers.
  - mananaysiempre 1y ago
    Already-established single-vendor VM ecosystems.
    - pjmlp 1y ago
      On the contrary, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines https://en.wikipedia.org/wiki/List_of_Java_virtual_machines And looking at other bytecode based systems, enough runtimes with multiple vendors. https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode
      - mananaysiempre 1y ago
        I don’t know, I feel myself shifting the goalposts here, but at the same time, I don’t feel I’m unjustified in doing that. You’re probably not going to complain that the list of JVMs you linked is incomplete, even though there are probably small-scale JVMs in SIM cards and other such minuscule environments that are not listed there, and those could easily be something entirely unique that was written by a couple of guys in a room in 1997 and last had a feature added to it in 2000. So I can’t help observing the non-obsolete JVMs not targeting an embedded usecase (and thus capable of supporting the kind of tools you’re referring to) are all either research projects or OpenJDK-based (or both). Harmony is dead. GCJ is dead. (Does Dalvik count?..) Oracle has already perpetrated half of a rugpull on OpenJDK and mostly murdered the JCP, and that ratchet only ever goes in one direction. And the tooling of the kind you describe is mostly sold by a handful of companies for a handful of notable languages, none of which were born outside the JVM context: Kotlin is the last entrant there, and it is very good, but the tooling is also very distinctly a single-vendor thing to the point that Google didn’t roll their own. (Both Clojure and Scala are lovely, but I don’t think they’re on the same side of notable as Java or Kotlin. Groovy still exists.) Jython was almost the last holdout for targeting the JVM, and it’s also effectively dead. JRuby is... surprisingly alive? But I don’t believe it has tooling worth a damn. I guess what I want to say is, for a very long time—though not for the entirety of its history—it’s been an ecosystem centered on Java and not really on the JVM. Microsoft’s CLR actually made a fair attempt at, let’s say, multilingualism for significantly longer, but after the DLR flopped that was mostly the end of that. And, of course, instead of a Java-centric ecosystem it was from the start a Microsoft-centric ecosystem, and after the stunts they’ve pulled (most recently) with their VSCode extensions and language servers I don’t trust any development tool Microsoft releases to continue to exist in any given form for any given duration. So I don’t think there’s really anything mature that would be VM-centric in the way that Wasm is, that would furthermore not go up in smoke if a single vendor decided to pull out. That’s not to say I think Wasm is the pinnacle of computing–I think it’s pretty wasteful, actually, and annoyingly restrictive in what languages it can support. I just don’t think it really retreads the paths of any of the (two) existing prominent VM-based platforms.
weinzierl 1y ago
For performant WASM/JS interchange you might be interested in Sledgehammer Bindgen. https://github.com/ealmloff/sledgehammer_bindgen https://github.com/ealmloff/sledgehammer_bindgen
WhereIsTheTruth 1y ago
WASM is not a web scripting language Trying to shoehorn Rust as a web scripting language was your second mistake Your first mistake was to mix Rust, TypeScript and JavaScript only just to add logic to your HTML buttons I swear, things get worse every day on this planet
- sakesun 1y ago
  Actually, WASM will enable many languages better for web scripting than Javascript.
  - weinzierl 1y ago
    WASM certainly had the potential for this, but I am afraid without direct DOM access it is never going to happen.
    - breve 1y ago
      It is happening. Leptos is an example: https://www.leptos.dev/ https://www.leptos.dev/ Dioxus is another: https://dioxuslabs.com/ https://dioxuslabs.com/ C# with Avalonia for a different use case: https://avaloniaui.net/ https://avaloniaui.net/ Avalonia solitaire demo: https://solitaire.xaml.live/ https://solitaire.xaml.live/ Avalonia Visual Basic 6 clone: https://bandysc.github.io/AvaloniaVisualBasic6/ https://bandysc.github.io/AvaloniaVisualBasic6/ Blazor can run as WebAssembly on the client side if you choose that runtime mode: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... Beyond the browser, Wasmer does WebAssembly on the serverside: https://wasmer.io/ https://wasmer.io/ Fermyon too: https://www.fermyon.com/ https://www.fermyon.com/ Extism is a framework for an application to support WebAssembly plugins: https://extism.org/ https://extism.org/
      - CrimsonRain 1y ago
        how'd you compare dioxus and leptos?
chrismorgan 1y ago
> Why create a generic bytecode execution platform and limit the use case so much? How would you make such a thing without limiting it in some such way?
- nothrabannosir 1y ago
  By giving it dom support
  - fabrice_d 1y ago
    Which meant having garbage collection working accross the WASM/JS barrier. This is now possible, but was not exactly trivial to design. It's a good thing that this was not rushed out.
  - chrismorgan 1y ago
    Check the context of the quote. DOM support is unrelated, it was about the Rust/TypeScript interface.
    - nothrabannosir 1y ago
      What I got from gp is that interface is necessary because the wasm environment itself is limited. Quote: > You need a lot of inherently slow and unsafe glue code to make anything work. Idea being that with dom support you’d need less unsafe glue code. Of course I was being glib but it is the point of TFA after all.
fsloth 1y ago
WASM as it is, is good enough for non-trivial graphics and geometry workloads - visibility culling (given octree/frustum), data de-serialization (pointclouds, meshes), and actual BREP modeling. All of these a) are non-trivial to implement b) would be a pain to rewrite and maintain c) run pretty swell in the wasm. I agree WASM has it’s drawbacks but the execution model is mostly fine for these types of task where you offload the task to a worker and are fine waiting a millisecond or two for the response. The main benefit for complex tasks like above is that when a product needs to support isomorphic web and native experience - quite many use cases actually in CAD, graphics & gis) - based on complex computation you maintain, the implementation and maintenance load drops to a half. Ie these _could_ be eg typescript but then maintaining feature parity becomes _much_ more burdensome.
flohofwoe 1y ago
> I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often. It's fine and fast enough as long as you don't need to pass complex data types back and forth. For instance WebGL and WebGPU WASM applications may call into JS thousands of times per frame. The actual WASM-to-JS call overhead itself is negligible (in any case, much less than the time spent inside the native WebGL or WebGPU implementation), but you really need to restrict yourself to directly passing integers and floats for 'high frequency calls'. Those problems are quite similar to any FFI scenario though (e.g. calling from any high level language into restricted C APIs).
api 1y ago
> You need a lot of inherently slow and unsafe glue code to make anything work. That describes much of modern computing.
Muromec 1y ago
>The whole WASM story is confusing to me. Think of it as a backend and not as library and it clicks.
- sfvisser 1y ago
  Yes, but that’s exactly what I’m trying to avoid.
whizzter 1y ago
The confusion is perhaps due to your usage focus and the security constraints browser compiler makers face to make something secure. First off, remember that initially all we had was JS, then Asm.JS was forced down Apple throats by being "just" a JS compatible performance hack (remember that Google had tried to introduce NaCl beforehand but never got traction). You can still see the Asm.JS lineage in how Wasm branching opcodes work (you can always easily decompose them into while loops together with break and continue instructions). The target market for NaCl, Asm.JS and Wasm seems to have been focused on enabling porting C/C++ games even if other usages was always of interest, so while interop times can be painful it's usually not a major factor. Secondly, As a compiler maker (and to look at performance profiles), I usually place languages into 3 categories. Category 1: Plain-memory-accessors, objects are usually a pointer number + offsets for members, more or less manually managed memory. Cache friendlyness is your own worry, CPU instructions are always simple. C, C++, Rust, Zig, Wasm/Asm.JS, etc goes here. Category 2: GC'd offset-languagses, while we still have pointers(now called references) they're usually restricted from being directly mutated, instead going through specialized access instructions, however as with category 1 the actual value can often be accessed with the pointer+offset and object layouts are _fixed_ so less freedom vs JS but higher perf. Also there can often be GC-specific instructions like read/write-barriers associated with object accesses. Performance for actual instructions is still usually good but GC's can affect access patterns to increase costs and some GC collection unpredictability. Java, C#, Lisps, high perf functional languages,etc usually belong here (with exceptions). Category 3: GC'd free-prop languages, objects are no longer of fixed size (you can add properties after creation), runtimes like V8 tries their best to optimize this away to approach Category 2 languages but abuse things enough and you'll run out a performance cliff. Every runtime optimization requires _very careful_ design of fallbacks that can affect practically almost any other part of the runtime (these manifest as type-confusion vulnerabilities if you look at bug-reports) as well as how native-bindings are handled. JS, Python, Lua, Ruby, etc goes here. Naturally some languages/runtimes can straddle these lines (.NET/CIL has always been able to run C as well as later JS, Ruby and Python in addition to C# and today C# itself is gaining many category 1 features), I'm mostly putting the languages into the categories where the majority of user created code runs. To get back to the "troubles" of Wasm<->JS, as you noticed they are of category 1 and 3, since Wasm is "wrapped" by JS you can usually reach into Wasm memory from JS since it's "just an buffer", the end-user security implications are fairly low since the JS has well defined bounds checking (outside of performance costs). The other direction is a pure clusterf from a compiler writers point of view, remember that most of these optimizations of Cat 3 languages have security implications? Allowing access would require every precondition check to be replicated on the Wasm side as well as in the main JS runtime (or build a unified runtime but optimization strategies are often different). The new Wasm-GC (finally usable with Safari since late last year) allows GC'd Catgory 2 languages to be built directly to Wasm (and not ship their own GC via Cat 1 emulation like C#/Blazor) or be compiled to JS, and even here they punted any access to category 3 (JS) objects, basically marking them as opaque objects that can be referred and passed back to JS (improvement over previous WASM since there is no extra GC synching as one GC handles it all but still no direct access standardized iirc). So, security has so far taken a center stage over usability. They fix things as people complain but it's not a fast process.
jokoon 1y ago
WASM is just hotfixing javascript to use any language people want. It's all about javascript being popular and being the standard language, js is not a great language, but it's standard across every computer, which dwarfs anything that can be said about js. Adjusting browsers so they can use WASM was easy to do, but telling browser vendors to make the DOM work was obviously more difficult, because they might handle the DOM in various ways. Not to mention js engines are very complicated.
ifwinterco 1y ago
The entire DOM API is very coupled to JS, it's all designed with JS in mind, any new and future proposed changes are thought about solely through the lens of JS. If they introduced a WASM API it would perpetually be a few months/years behind the JS one, any new features would have to be implemented in both etc. I can see why it's not happened (edit) And yes, I think the intention of WASM was either heavy processing, or UI elements more along the lines of what used to be done with Java applets etc. potentially using canvas and bypassing the DOM entirely, not as an alternative to JS for doing `document.createElement`
- wffurr 1y ago
  >> The entire DOM API is very coupled to JS, Is it though? I thought it was all specified in WebIDL and all the browser vendors generate C++ headers from it too.

BlackFly 1y ago

My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the browser people aren't interested in. This is just my take since I am not internal to those organizations. But you have the whole web assembly component model and browsers just do not seem interested in picking that up at all. So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access. The browser is the main driving force for WASM, as I see it, because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container. So WASM doesn't really have much impetus to improve beyond compute.

boomskats 1y ago
> So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access I don't think this is entirely fair or accurate. This isn't how Wasm runtimes work. Making it possible for the sandbox to explicitly request specific resource access is not quite the same thing as what you're implying here. > The browser is the main driving force for WASM, as I see it This hasn't been the case for a while. In your first paragraph you yourself say that 'the people furthering WASM are [...] building a whole new VM ecosystem that the browser people aren't interested in' - if that's the case, how can the browser be the main driving force for Wasm? It's true, though, that there's verey little revenue in browser-based Wasm. There is revenue in enterprise compute. > because outside of the browser the need for sandboxing is limited to plugins (where LUA often gets used) since otherwise you can run a binary or a docker container Not exactly true when you consider that docker containers are orders of magnitude bigger, slower to mirror and start up, require architecture specific binaries, are not great at actually 'containing' fallout from insecure code, supply chain vulns, etc.. The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. They just rarely make it to the hn frontpage, because they really are boring. However, the Wasm push in enterprise compute is real, and the value is real. But you're right that the ecosystem and its sponsorship is still struggling - in some part due to lack of support for the component model by the browser people. The component model support introduced in go 1.25 has been huge though, at least for the (imho bigger) enterprise compute use case, and the upcoming update to the component model (wasi p3) should make a ton of this stuff way more usable. So it's a really interesting time for Wasm.
- serbuvlad 1y ago
  > The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. What are you talking about? Alpine container image is <5MB. Debian container image (if you really need glibc) is 30MB. wasmtime is 50MB. If a service has a multi-gig container, that is for other stuff than the Docker overhead itself, so would also be a multi-gig app for WASM too. Also, Docker images get overlayed. So if I have many Go or Rust apps running on Alpine or Debian as simple static binaries, the 5MB/30MB base system only exists once. (Same as a wasmtime binary running multiple programs).
  - rkangel 1y ago
    These numbers are true, but you'd be amazed and the number of organisations that have containers that are just based on ubuntu:latest, and don't strip package cache etc.
    - nightpool 1y ago
      Surely moving those containers to alpine would be 1000x easier than rewriting everything in wasm though.
    - serbuvlad 1y ago
      ubuntu:latest is also 30MB, like Debian. Obviously an unoptimized C++/Python stack that depends on a billion .so's (specific versions only) and pip packages is going to waste space. The advantage of containers for these apps is that it can "contain" the problem, without having to rewrite them. The "modern" languages: Go and Rust produce apps that depend either only on glibc (Rust) or on nothing at all (Rust w/ musl and Go). You can plop these binaries on any Linux system and they will "just work" (provided the kernel isn't ancient). Sure, the binaries can be fat, but it's a few dozen megabytes at the worst. This is not an issue as long as you architect around it (prefer busybox-style everything-in-a-binary to coreutils-style many-binaries). Moreover, a VM isn't much necessary, as these programming languages can be easily cross-compiled (especially Go, for which I have the most experience). Compared to C/C++ where cross-compiling is a massive pain which led to Java and it's VM dominating because it made cross-compilation unnecessary, I can run `GOOS=windows GOARCH=arm64 go build` and build a native windows arm64 binary from x86-64 Linux with nothing but the standard Go compiler. The advantage of containers for Rust and Go lies in orchestration and separation of filesystem, user, ipc etc. namespaces. Especially orchestration in a distributed (cluster) environment. These containers need nothing more than the Alpine environment, configs, static data and the binary to run. I fail to see what problem WASM is trying to solve in this space.
pjmlp 1y ago
Meanwhile the people using already established VM ecosystems, don't a value dropping several decades of IDEs, libraries and tools, for yet another VM redoing more or less the same, e.g. application servers in Kubernetes with WASM containers.
- mananaysiempre 1y ago
  Already-established single-vendor VM ecosystems.
  - pjmlp 1y ago
    On the contrary, https://en.wikipedia.org/wiki/List_of_Java_virtual_machines https://en.wikipedia.org/wiki/List_of_Java_virtual_machines And looking at other bytecode based systems, enough runtimes with multiple vendors. https://en.wikipedia.org/wiki/Bytecode https://en.wikipedia.org/wiki/Bytecode
    - mananaysiempre 1y ago
      I don’t know, I feel myself shifting the goalposts here, but at the same time, I don’t feel I’m unjustified in doing that. You’re probably not going to complain that the list of JVMs you linked is incomplete, even though there are probably small-scale JVMs in SIM cards and other such minuscule environments that are not listed there, and those could easily be something entirely unique that was written by a couple of guys in a room in 1997 and last had a feature added to it in 2000. So I can’t help observing the non-obsolete JVMs not targeting an embedded usecase (and thus capable of supporting the kind of tools you’re referring to) are all either research projects or OpenJDK-based (or both). Harmony is dead. GCJ is dead. (Does Dalvik count?..) Oracle has already perpetrated half of a rugpull on OpenJDK and mostly murdered the JCP, and that ratchet only ever goes in one direction. And the tooling of the kind you describe is mostly sold by a handful of companies for a handful of notable languages, none of which were born outside the JVM context: Kotlin is the last entrant there, and it is very good, but the tooling is also very distinctly a single-vendor thing to the point that Google didn’t roll their own. (Both Clojure and Scala are lovely, but I don’t think they’re on the same side of notable as Java or Kotlin. Groovy still exists.) Jython was almost the last holdout for targeting the JVM, and it’s also effectively dead. JRuby is... surprisingly alive? But I don’t believe it has tooling worth a damn. I guess what I want to say is, for a very long time—though not for the entirety of its history—it’s been an ecosystem centered on Java and not really on the JVM. Microsoft’s CLR actually made a fair attempt at, let’s say, multilingualism for significantly longer, but after the DLR flopped that was mostly the end of that. And, of course, instead of a Java-centric ecosystem it was from the start a Microsoft-centric ecosystem, and after the stunts they’ve pulled (most recently) with their VSCode extensions and language servers I don’t trust any development tool Microsoft releases to continue to exist in any given form for any given duration. So I don’t think there’s really anything mature that would be VM-centric in the way that Wasm is, that would furthermore not go up in smoke if a single vendor decided to pull out. That’s not to say I think Wasm is the pinnacle of computing–I think it’s pretty wasteful, actually, and annoyingly restrictive in what languages it can support. I just don’t think it really retreads the paths of any of the (two) existing prominent VM-based platforms.

weinzierl 1y ago

For performant WASM/JS interchange you might be interested in Sledgehammer Bindgen. https://github.com/ealmloff/sledgehammer_bindgen https://github.com/ealmloff/sledgehammer_bindgen

WhereIsTheTruth 1y ago

WASM is not a web scripting language Trying to shoehorn Rust as a web scripting language was your second mistake Your first mistake was to mix Rust, TypeScript and JavaScript only just to add logic to your HTML buttons I swear, things get worse every day on this planet

sakesun 1y ago
Actually, WASM will enable many languages better for web scripting than Javascript.
- weinzierl 1y ago
  WASM certainly had the potential for this, but I am afraid without direct DOM access it is never going to happen.
  - breve 1y ago
    It is happening. Leptos is an example: https://www.leptos.dev/ https://www.leptos.dev/ Dioxus is another: https://dioxuslabs.com/ https://dioxuslabs.com/ C# with Avalonia for a different use case: https://avaloniaui.net/ https://avaloniaui.net/ Avalonia solitaire demo: https://solitaire.xaml.live/ https://solitaire.xaml.live/ Avalonia Visual Basic 6 clone: https://bandysc.github.io/AvaloniaVisualBasic6/ https://bandysc.github.io/AvaloniaVisualBasic6/ Blazor can run as WebAssembly on the client side if you choose that runtime mode: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... Beyond the browser, Wasmer does WebAssembly on the serverside: https://wasmer.io/ https://wasmer.io/ Fermyon too: https://www.fermyon.com/ https://www.fermyon.com/ Extism is a framework for an application to support WebAssembly plugins: https://extism.org/ https://extism.org/
    - CrimsonRain 1y ago
      how'd you compare dioxus and leptos?

chrismorgan 1y ago

> Why create a generic bytecode execution platform and limit the use case so much? How would you make such a thing without limiting it in some such way?

nothrabannosir 1y ago
By giving it dom support
- fabrice_d 1y ago
  Which meant having garbage collection working accross the WASM/JS barrier. This is now possible, but was not exactly trivial to design. It's a good thing that this was not rushed out.
- chrismorgan 1y ago
  Check the context of the quote. DOM support is unrelated, it was about the Rust/TypeScript interface.
  - nothrabannosir 1y ago
    What I got from gp is that interface is necessary because the wasm environment itself is limited. Quote: > You need a lot of inherently slow and unsafe glue code to make anything work. Idea being that with dom support you’d need less unsafe glue code. Of course I was being glib but it is the point of TFA after all.

fsloth 1y ago

WASM as it is, is good enough for non-trivial graphics and geometry workloads - visibility culling (given octree/frustum), data de-serialization (pointclouds, meshes), and actual BREP modeling. All of these a) are non-trivial to implement b) would be a pain to rewrite and maintain c) run pretty swell in the wasm. I agree WASM has it’s drawbacks but the execution model is mostly fine for these types of task where you offload the task to a worker and are fine waiting a millisecond or two for the response. The main benefit for complex tasks like above is that when a product needs to support isomorphic web and native experience - quite many use cases actually in CAD, graphics & gis) - based on complex computation you maintain, the implementation and maintenance load drops to a half. Ie these _could_ be eg typescript but then maintaining feature parity becomes _much_ more burdensome.

flohofwoe 1y ago

> I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often. It's fine and fast enough as long as you don't need to pass complex data types back and forth. For instance WebGL and WebGPU WASM applications may call into JS thousands of times per frame. The actual WASM-to-JS call overhead itself is negligible (in any case, much less than the time spent inside the native WebGL or WebGPU implementation), but you really need to restrict yourself to directly passing integers and floats for 'high frequency calls'. Those problems are quite similar to any FFI scenario though (e.g. calling from any high level language into restricted C APIs).

api 1y ago

> You need a lot of inherently slow and unsafe glue code to make anything work. That describes much of modern computing.

Muromec 1y ago

>The whole WASM story is confusing to me. Think of it as a backend and not as library and it clicks.

sfvisser 1y ago
Yes, but that’s exactly what I’m trying to avoid.

whizzter 1y ago

The confusion is perhaps due to your usage focus and the security constraints browser compiler makers face to make something secure. First off, remember that initially all we had was JS, then Asm.JS was forced down Apple throats by being "just" a JS compatible performance hack (remember that Google had tried to introduce NaCl beforehand but never got traction). You can still see the Asm.JS lineage in how Wasm branching opcodes work (you can always easily decompose them into while loops together with break and continue instructions). The target market for NaCl, Asm.JS and Wasm seems to have been focused on enabling porting C/C++ games even if other usages was always of interest, so while interop times can be painful it's usually not a major factor. Secondly, As a compiler maker (and to look at performance profiles), I usually place languages into 3 categories. Category 1: Plain-memory-accessors, objects are usually a pointer number + offsets for members, more or less manually managed memory. Cache friendlyness is your own worry, CPU instructions are always simple. C, C++, Rust, Zig, Wasm/Asm.JS, etc goes here. Category 2: GC'd offset-languagses, while we still have pointers(now called references) they're usually restricted from being directly mutated, instead going through specialized access instructions, however as with category 1 the actual value can often be accessed with the pointer+offset and object layouts are _fixed_ so less freedom vs JS but higher perf. Also there can often be GC-specific instructions like read/write-barriers associated with object accesses. Performance for actual instructions is still usually good but GC's can affect access patterns to increase costs and some GC collection unpredictability. Java, C#, Lisps, high perf functional languages,etc usually belong here (with exceptions). Category 3: GC'd free-prop languages, objects are no longer of fixed size (you can add properties after creation), runtimes like V8 tries their best to optimize this away to approach Category 2 languages but abuse things enough and you'll run out a performance cliff. Every runtime optimization requires _very careful_ design of fallbacks that can affect practically almost any other part of the runtime (these manifest as type-confusion vulnerabilities if you look at bug-reports) as well as how native-bindings are handled. JS, Python, Lua, Ruby, etc goes here. Naturally some languages/runtimes can straddle these lines (.NET/CIL has always been able to run C as well as later JS, Ruby and Python in addition to C# and today C# itself is gaining many category 1 features), I'm mostly putting the languages into the categories where the majority of user created code runs. To get back to the "troubles" of Wasm<->JS, as you noticed they are of category 1 and 3, since Wasm is "wrapped" by JS you can usually reach into Wasm memory from JS since it's "just an buffer", the end-user security implications are fairly low since the JS has well defined bounds checking (outside of performance costs). The other direction is a pure clusterf from a compiler writers point of view, remember that most of these optimizations of Cat 3 languages have security implications? Allowing access would require every precondition check to be replicated on the Wasm side as well as in the main JS runtime (or build a unified runtime but optimization strategies are often different). The new Wasm-GC (finally usable with Safari since late last year) allows GC'd Catgory 2 languages to be built directly to Wasm (and not ship their own GC via Cat 1 emulation like C#/Blazor) or be compiled to JS, and even here they punted any access to category 3 (JS) objects, basically marking them as opaque objects that can be referred and passed back to JS (improvement over previous WASM since there is no extra GC synching as one GC handles it all but still no direct access standardized iirc). So, security has so far taken a center stage over usability. They fix things as people complain but it's not a fast process.

jokoon 1y ago

WASM is just hotfixing javascript to use any language people want. It's all about javascript being popular and being the standard language, js is not a great language, but it's standard across every computer, which dwarfs anything that can be said about js. Adjusting browsers so they can use WASM was easy to do, but telling browser vendors to make the DOM work was obviously more difficult, because they might handle the DOM in various ways. Not to mention js engines are very complicated.

ifwinterco 1y ago

The entire DOM API is very coupled to JS, it's all designed with JS in mind, any new and future proposed changes are thought about solely through the lens of JS. If they introduced a WASM API it would perpetually be a few months/years behind the JS one, any new features would have to be implemented in both etc. I can see why it's not happened (edit) And yes, I think the intention of WASM was either heavy processing, or UI elements more along the lines of what used to be done with Java applets etc. potentially using canvas and bypassing the DOM entirely, not as an alternative to JS for doing `document.createElement`

wffurr 1y ago
>> The entire DOM API is very coupled to JS, Is it though? I thought it was all specified in WebIDL and all the browser vendors generate C++ headers from it too.