Our great sponsors
-
iswasmfast
Performance comparison of WebAssembly, C++ Addon, and native implementations of various algorithms in Node.js.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Uno Platform
Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
-
At a glance, the bindings for wasm copy the data,
https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185...
If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things).
If it's not that, then a 10x difference suggests you are running into some kind of a VM bug or limitation.
I know what WASI is, my point is that there is no where near parity with existing posix implementations. I have been following the bytecode alliance and webassembly communities for a while and they are all still firmly in the design phase. You only need to look at the networking API [0] and the thread has not been updated for two months, with prior to that folks asking is the work even happening still
[0] https://github.com/WebAssembly/WASI/issues/370
Regarding WAPM [2] and how its development had become a bit dormant, expect news about it soon. Can't wait to share what we have been working on!
[1] https://wasmer.io
I have low faith in the current WebAssembly GC proposal. It's been such a daunting task that they've started talking about "mini-mini MVPs". The GC proposal does not do what most people think it does, the current draft is basically impossible for most languages to target, and even contributors are finding it difficult to reach consensus [0]. It might be a while before it becomes useful.
[0] https://github.com/WebAssembly/gc/issues/254
> WebAssembly will never have direct access to the DOM
I haven’t been paying much attention to WASM proposals for the last few years, but I thought that direct DOM access (avoiding JavaScript trampolining) was one of the driving goals of the reference type, interface type and garbage collection proposals. https://github.com/WebAssembly/proposals/issues/16 mentions “call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript”, and WASM’s high level goals document <https://github.com/WebAssembly/design/blob/main/HighLevelGoa...> lists “access browser functionality through the same Web APIs that are accessible to JavaScript” (not “through JavaScript”, but “through the same APIs”). Am I misunderstanding things?
> WebAssembly will never have direct access to the DOM
I haven’t been paying much attention to WASM proposals for the last few years, but I thought that direct DOM access (avoiding JavaScript trampolining) was one of the driving goals of the reference type, interface type and garbage collection proposals. https://github.com/WebAssembly/proposals/issues/16 mentions “call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript”, and WASM’s high level goals document <https://github.com/WebAssembly/design/blob/main/HighLevelGoa...> lists “access browser functionality through the same Web APIs that are accessible to JavaScript” (not “through JavaScript”, but “through the same APIs”). Am I misunderstanding things?
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 start.
Well then.
Most syscalls are straightforward to expose through WASI, but signal handling, memory mapping, and shmem will be very painful. Probably fork too. My guess is that these syscalls will not be exposed, or exposed in some highly attenuated way [2], and so WASI can be a lever to create better APIs for this stuff. Signals really are terrible.
1: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bott...
2: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bott...
Might be a notable exception but i have almost a thousand of those exceptions :-P. Also while Steam itself is needed for the initial download, some games can just be copied to another place and work fine, especially indie games that do not bother with DRM. A bigger issue is the Steamworks APIs but if you only care about singleplayer games there are drop-in replacements like Goldberg's emulator[0] which is opensource (LGPL).
(also there are more places to buy DRM-free games than only GOG - e.g. itch.io, Zoom Platform, GamersGate and Humble Store to name a few - though GOG has most of the games)
[0] https://gitlab.com/Mr_Goldberg/goldberg_emulator