Transferring data from the main thread to the worker thread could be costly depending on the size of the data in question.
However, there are some drawbacks to this approach. Considering that WebAssembly is often used for processing intensive code, pairing it with Web Workers can be a great combination. This keeps the main browser thread free to continue rendering and handling user interactions. The critical aspect of putting a WebAssembly module in a Web Worker is that it removes the overhead of fetching, compiling and initialising a WebAssembly module off the main thread, and in turn calling the given functions in a module.
#Firefox gbrowser postmessage code#
Why Put Your WebAssembly Code in a Web Worker? Here we combine Web Workers and WebAssembly to get the consistency and potential performance benefits of WebAssembly, alongside the benefit of working in a separate thread with Web Workers.
WebAssembly solves the first core issue, which is getting predictable, near native performance across browsers and environments. WebAssembly provides a compact binary compilation target format, allowing developers to start with a selection of strongly typed languages like C/C++ and Rust, as well as languages like Go and TypeScript. Recently we have seen the growth of another specification, WebAssembly (WASM), a new code type for the web. Web Workers allow for offloading processing onto a separate thread keeping the main thread free. Since 2010 we’ve had a standardised way to manage interactivity for long, non-DOM related tasks. One issue is getting predictable running times across browsers and JavaScript engines that optimise different code paths differently, as well as producing code that doesn’t interfere with user experience. When building web apps, writing processing intensive code can be a challenge.
0 kommentar(er)
