Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking the WASM/JS communication performance barrier

github.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Breaking the WASM/JS communication performance barrier

#21

Post by MuffinFlavored »

boomskats wrote: post #18
MuffinFlavored wrote: post #17

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…

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 impr…

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 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

#22

Post by Evan-Almloff »

MuffinFlavored wrote: post #21
boomskats wrote: post #18

Earlier quoted context omitted.

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 impr…

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 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?

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

#23

Post by MuffinFlavored »

Evan-Almloff wrote: post #22
MuffinFlavored wrote: post #21

Earlier quoted context omitted.

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 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?

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...

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

#24

Post by nicoburns »

MuffinFlavored wrote: post #17

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…

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

#25

Post by zetafunction »

continuational wrote: post #10
theSherwood wrote: post #7

Earlier quoted context omitted.

100%. If we could get a DomString8 (8-bit encoded) interface in addition to the existing DomString (16-bit encoded) and a way to wrap a buffer in a DomString8, we could have convenient and reasonably performant interfaces between WASM and the DOM.

The extra DOM complexity that would entail seems like a loss for the existing web.

At least some of the implementation complexity is already there under the hood. WebKit/Blink have an optimization to use 8-bit characters for strings that consist only of latin1 characters.

Re: Breaking the WASM/JS communication performance barrier

#26

Post by theSherwood »

continuational wrote: post #10
theSherwood wrote: post #7

Earlier quoted context omitted.

100%. If we could get a DomString8 (8-bit encoded) interface in addition to the existing DomString (16-bit encoded) and a way to wrap a buffer in a DomString8, we could have convenient and reasonably performant interfaces between WASM and the DOM.

The extra DOM complexity that would entail seems like a loss for the existing web.

The current situation is that we have limited uptake of WASM. This is due, in part, to lack of DOM access. We could solve that but we would have to complicate WASM or complicate the DOM. Complicating WASM would seem to undermine its purpose, burdening it forever with the complexity of the browser. The DOM, on the other hand, is already quite complex. But providing a fresh interface to the DOM would make it possible to bypass some of the accretions of time and complexity. The majority of the cost would be to browser implementors as opposed to web developers.

Re: Breaking the WASM/JS communication performance barrier

#28

Post by monster_truck »

vanderZwan wrote: post #20
boomskats wrote: post #19

Earlier quoted context omitted.

How would splitting it into substrings be different from decoding individual strings from an allocation/gc perspective? If anything I'd assume splitting a substring was more efficient - i expect there's a ton of optimisations in js for sliced strings or whatever as it's been around for ages.

I imagine it's faster during creation because there's fewer allocations for a backing array for the string content (one, basically, unless they move stuff around). But then that can also mean holding on to the entire backing array even if only one of the strings is still "alive", unless there are optimizations for reclaiming memory in those situations too.

I'm pretty sure turbofan handles this, you might need to do a little hoisting or tagging

Re: Breaking the WASM/JS communication performance barrier

#29

Post by MuffinFlavored »

nicoburns wrote: post #24
MuffinFlavored wrote: post #17

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…

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/

How could/would you do "DOM event -> native FFI dlsym-type call"?

Re: Breaking the WASM/JS communication performance barrier

#30

Post by nicoburns »

MuffinFlavored wrote: post #29
nicoburns wrote: post #24

Earlier quoted context omitted.

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/

How could/would you do "DOM event -> native FFI dlsym-type call"?

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.

Post reply on HN