News for hackers. Stuff that matters.
Re:Breaking the WASM/JS communication performance barrier by MuffinFlavored on Saturday July 26, 2025 @02:41PM (#44696135)
I think there is a ton of room left on the table here for innovation.

Context: as far as I know Electron is still the king if you want to do (unsafe but performant) "IPC/RPC" between native and a webview.

All of the other options that exist in other languages (Deno, Rust, you name it) do the same "stringified JSON back and forth" which really isn't great for performance in my opinion.

It'd be cool if (obviously in a sandboxed or secure way) you could opt in to something albeit a bit reckless, but some way to provide native methods for the WASM part of V8 and its WebView (thinking Electron-esque here) to call.

Re:Breaking the WASM/JS communication performance barrier by boomskats on Saturday July 26, 2025 @03:08PM (#44696281)
I'm not sure if I'm understanding you correctly, but vanilla wasm ipc works by sharing linear memory, where it's up to the implementation to choose the data encoding (arrow/proto/whatever). In the case of wasm-bindgen's dom manipulation api, the implementation serialises individual commands and sends them over the boundary, with any string params for each command being deserialised individually, and this project improves on that by batching them all into one big string thus reducing the deserialisation overhead. However, the string encoding is specific to that use case - it's not a general wasm ipc mechanism.

VSCode IPC is kinda similar as it's designed to facilitate comms over an enforced process isolation barrier to protect the main thread from slow extensions etc. but it's actually IPC there (as in, there are multiple processes at the os level). The wasm/js stuff is handled within the same v8 context - it's not actually ipc.

(Happy to be corrected here, but this is my understanding)

Re:Breaking the WASM/JS communication performance barrier by MuffinFlavored on Saturday July 26, 2025 @04:25PM (#44696707)
https://github.com/webview/webview_deno

Tell me how you'd do "native C/C++ FFI (to like a .so or .dylib or .dll)" between the webview using WASM or anything other than "WebKit's built in JSON-string based IPC"

Like a <button> that triggers a DLL call. How would you achieve it with WASM? How does WASM act as the bridge to the DOM and/or native? It doesn't, right?

Re:Breaking the WASM/JS communication performance barrier by Evan-Almloff on Saturday July 26, 2025 @06:20PM (#44697369)
Most of the optimizations apply equally to calling into webview JS from a native application for something like dom manipulation. There is a wry example that uses the system webview in the repo: https://github.com/ealmloff/sledgehammer_bindgen/blob/master...
Re:Breaking the WASM/JS communication performance barrier by MuffinFlavored on Saturday July 26, 2025 @06:54PM (#44697545)
https://github.com/ealmloff/sledgehammer_bindgen/blob/master...

This is fetch(), which I have to imagine is much less performant than Electron with a require('native-module')

Re:Breaking the WASM/JS communication performance barrier by nicoburns on Saturday July 26, 2025 @07:12PM (#44697640)
We're building a brand new webview that has a native code (Rust) API to the DOM. That way your native extension doesn't have to go through JavaScript at all. Currently it doesn't have any JS support, but it could be added.

https://github.com/DioxusLabs/blitz/

Re:Breaking the WASM/JS communication performance barrier by MuffinFlavored on Saturday July 26, 2025 @09:54PM (#44698286)
How could/would you do "DOM event -> native FFI dlsym-type call"?
Re:Breaking the WASM/JS communication performance barrier by nicoburns on Sunday July 27, 2025 @07:34AM (#44700535)
You could either use Dioxus-Native which combines Blitz with Dioxus (a React-like framework but in Rust).

Or you could implement the EventHandler trait https://docs.rs/blitz-dom/latest/blitz_dom/trait.EventHandle...

In either case you will recieve the event as a Rust struct passed to a Rust function. So you could call Rust depdencies directly, and C dependencies would just require Rust bindings.

Re:Breaking the WASM/JS communication performance barrier by MuffinFlavored on Sunday July 27, 2025 @07:53AM (#44700656)
I see. It's a new rendering engine, not "Blink/WebKit/etc.". Am I right that WebKit does not support what you and I are discussing equivalent wise? Passing structs or "binary" events?
Re:Breaking the WASM/JS communication performance barrier by nicoburns on Sunday July 27, 2025 @09:01AM (#44701033)
> I see. It's a new rendering engine, not "Blink/WebKit/etc."

Correct

> Am I right that WebKit does not support what you and I are discussing equivalent wise? Passing structs or "binary" events?

I'm not sure. If I wanted to do this I'd probably look into https://ultralig.ht/ which is a commercial fork of webkit. See: https://docs.ultralig.ht/docs/calling-a-c-function-from-js

Re:Breaking the WASM/JS communication performance barrier by MuffinFlavored on Sunday July 27, 2025 @03:22PM (#44703831)
Great link, thanks.

I'm probably being conceited but the fact that some company somewhere thought it was a good idea to add this feature for commercial efforts probably makes me think it's missing from the open source world.

Given your knowledge on Dioxus, do you think Dioxus/Tauri/Wry will eventually support something like this? I guess it's kind of niche.

Re:Breaking the WASM/JS communication performance barrier by nicoburns on Sunday July 27, 2025 @08:42PM (#44706071)
> Given your knowledge on Dioxus, do you think Dioxus/Tauri/Wry will eventually support something like this?

Something webkit based? Almost certainly not from a Dioxus perspective. We may add JavaScript support to Blitz at some point though. I believe Tauri have been looking at a WPE backend which may be able to support these kind of things, but I wouldn't hold your breath.