News for hackers. Stuff that matters.
Re:The State of WebAssembly 2022 by dustingetz on Monday June 20, 2022 @01:23PM (#31812964)
1. what's the functional programming story - immutable data structures, garbage collection?

2. WASM's best use seems to be to cross-compile C++ GUI apps in a browser (like Unity engine). Ok, but it's not platform native, so will this feel like weird Java desktop GUIs all over again? The best apps are native

3. Web apps are I/O bound. How does wasm help?

Re:The State of WebAssembly 2022 by jillesvangurp on Tuesday June 21, 2022 @02:20AM (#31820551)
1) Kotlin just shipped an experimental wasm compiler with 1.7.0 that is not actively marketed at this point but starting to work. They are depending on a few feature flags in chrome to turn on experimental garbage collection and a few other things. Jetbrains decided a while ago to build on and wait for the standardized wasm functionality for memory management and garbage collection instead of shipping their own version of that (like blazor does). My guess is that once this stabilizes, a lot of other languages will start targeting wasm more actively.

2) Actually, wasm is showing up in a lot of js/ts applications as an optimization. Mostly developers don't even notice their npms are pulling in some wasm. For example react does this apparently. What is native is a pretty fuzzy notion these days. A lot of mobile apps are hybrids that lean heavily on embedded browser components.

3) IO gets done by the browser via native libraries. The Javascript facade for this is pretty narrow (browser fetch API basically). If you are manipulating lot of data (e.g. graphics) in binary form, having some native code with actual types is helpful.

Re:The State of WebAssembly 2022 by int_19h on Monday June 20, 2022 @03:11PM (#31814372)
wasm is a low-level architecture - it gives you a linear heap to play with however you want. If you want immutable data structures and GC on top of that, you can certainly do that, in the same exact way we do it on other platforms.

The weird Java desktop GUIs were weird not because they weren't native code, but because the standard Java UI didn't use native UI APIs, nor did it even try to at least look native (as e.g. Qt does). But, just as there are native UI libraries for Java, there could be the same for wasm. It's just too early to tell, given how immature the whole wasm-outside-of-browser story is in general.

Re:The State of WebAssembly 2022 by pjmlp on Monday June 20, 2022 @01:27PM (#31813015)
Thanks to WebGL, all plugins are back, that is how WASM helps.

Have a look at Grain for a ML like language with GC runtime.

Re:The State of WebAssembly 2022 by dustingetz on Monday June 20, 2022 @01:34PM (#31813113)
Javascript already has WebGL? What is wasm adding
Re:The State of WebAssembly 2022 by remexre on Monday June 20, 2022 @01:48PM (#31813280)
Re:The State of WebAssembly 2022 by trusktr on Wednesday June 29, 2022 @11:38AM (#31921692)
Two things:

- speed up in some cases - ability to compile the same app to native

Re:The State of WebAssembly 2022 by dgb23 on Monday June 20, 2022 @01:59PM (#31813411)
A smaller, lower level target than JS. In a sense the better question is “what does it remove”.