141–150 of 251 posts
I'm paying attention, but we are still in the hype phase. "near-native performance" yeah a few seconds per hour. With all the jit and garbage collection, it's way too unreliable for anything that needs real-time performance and more than a pittance of CPU power. Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentati…
Earlier quoted context omitted.
So, honest question. if we're compiling our code to run on servers, why are we compiling it to run on a bytecode interpreter rather than native? My single use for docker is to containerize / isolate, not to run across architectures. I get the in-browser optimized / compiled code. That makes sense.
Wasm doesn't have to run in an interpreter. Many of the runtimes (like Wasmtime, Wasmer) compile the Webassembly to native machine code first. But that native code is still constrained by the Wasm security/sandboxing model, which includes memory isolation. (there is no direct memory sharing between the host and a Webassembly instance) A few benefits why it is even useful in a server context: You can distribute a sing…
Earlier quoted context omitted.
Agree with sibling comment - the JS ecosystem has a huge momentum behind it and probably isn't going away anytime soon. On the web, Wasm has currently found the most success with compute-intensive applications, since the JS Wasm bridge is still pretty expensive. There are already some Wasm-based frameworks like https://platform.uno/ that work on the web, but things like React/React-native and Flutter have a huge head…
React is for connecting state to the DOM and managing the redraws. I don’t see how Wasm could ever replace React, if you want to deal with UI. It’s a different thing.
Earlier quoted context omitted.
React is for connecting state to the DOM and managing the redraws. I don’t see how Wasm could ever replace React, if you want to deal with UI. It’s a different thing.
If we get to a point where interacting with browser DOM is comparably fast with Wasm, either through JS or with native APIs, then we could see Wasm replace React. That said, you're right that we probably won't see anything of that sort in the short term.
Edit: I guess you mean you’d compile your React app to Wasm, no?
Earlier quoted context omitted.
Wasm doesn't have to run in an interpreter. Many of the runtimes (like Wasmtime, Wasmer) compile the Webassembly to native machine code first. But that native code is still constrained by the Wasm security/sandboxing model, which includes memory isolation. (there is no direct memory sharing between the host and a Webassembly instance) A few benefits why it is even useful in a server context: You can distribute a sing…
One thing I am missing here. Docker, as much as it has the shortcomings you list, has an entire fleet of posix libraries, utils and tools at its availability. This has meant 99% of applications could wholesale lift their application and deploy it within a container. When I look at WASM/WASI there is no networking API, no storage API, crypto, etc etc. I can see its value for offloading parts of a web application that…
I think a big reason is that it was pushed by Mozilla, but they laid off all the related employees, and now no-one is really allocating resources to push it forward.
Plus it's still blocked by related proposal like interface types.
Earlier quoted context omitted.
One thing I am missing here. Docker, as much as it has the shortcomings you list, has an entire fleet of posix libraries, utils and tools at its availability. This has meant 99% of applications could wholesale lift their application and deploy it within a container. When I look at WASM/WASI there is no networking API, no storage API, crypto, etc etc. I can see its value for offloading parts of a web application that…
Yeah, progress on WASI has been painfully slow. I think a big reason is that it was pushed by Mozilla, but they laid off all the related employees, and now no-one is really allocating resources to push it forward. Plus it's still blocked by related proposal like interface types.
Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)
Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not , under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work wit…
[0] Yes, there is a pun buried in there.
Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages. Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition. IDLs and code generato…
Any language would be able to decode byte streams according to provided schema into intermediate formats (same semantics, different implementations) with a library, and then decode that significantly easier to understand data into application-specific formats.
Rust's Serde is almost there, but uses dynamic structure instead of using a schema that allows custom types.
Earlier quoted context omitted.
If we get to a point where interacting with browser DOM is comparably fast with Wasm, either through JS or with native APIs, then we could see Wasm replace React. That said, you're right that we probably won't see anything of that sort in the short term.
But how? React is a library to implement and structure your architecture in a certain way. Wasm is just a language. Wouldn’t you need a React-like framework in Wasm to get the same benefits? Edit: I guess you mean you’d compile your React app to Wasm, no?
More clearly: once Wasm interactions with the browser are fast, a new framework + Wasm could replace React + JS.
Earlier quoted context omitted.
TIL that Wasm doesn't have GC. But I did observe periodic CPU spikes and app freezes with Wasm+WebGL. So now I wonder where they came from. As for TensorFlow, no I deliberately compared their CPU-only Xnnpack backend against Wasm. So both didn't use the GPU. But obviously Sse3 and avx also help a lot. Emscripten is a compiler while Wasm is an execution backend. I think it makes sense to treat them as separate because…
> TIL that Wasm doesn't have GC. But I did observe periodic CPU spikes and app freezes with Wasm+WebGL. So now I wonder where they came from. Very likely you are observing those spikes because, AFAIK (and I could be out of date here). The WASM -> JS bridge isn't a free one to cross and was likely allocating stuff onto Javascript's GC. WASM is/was hyper isolated and sandboxed from javascript so any of the javascript A…