Size Change: 0 B

Total Size: 3.09 MB

_{compressed-size-action}

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @Copilot, @kleisauke.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: Copilot, kleisauke.

Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@adamsilverstein I've opened a new pull request, #74635, to work on those changes. Once the pull request is ready, I'll request review from you.

@adamsilverstein I've opened a new pull request, #74636, to work on those changes. Once the pull request is ready, I'll request review from you.

Yes, the generated code looks quite nice 🙂 It can be simplified at some places:

• the isRPCMessage check could be simplified or even completely eliminated. It currently does almost complete linting of the message structure. Usually you just check something like message.type === 'my-rpc-protocol'. And it could be eliminated because we competely control the postMessage channel between the worker and its creator (who owns the handle). It's not like sending messages to iframes which are "public" objects, available to any script through DOM API, where the iframe must be very careful about who it talks to.
• we probably don't need such a generic findTransferables implementation which finds transferables in any deeply nested field of any object. We could limit our APIs so that a transferable (i.e., a big binary buffer with image data) is always a standalone parameter.

But otherwise it looks good.

However! One alternative we should explore is using the @remote-ui/rpc library. That's also part of the Shopify stack, like @shopify/web-worker, and used internally by web-worker. That's basically a 1:1 replacement for @wordpress/worker-threads, and it has MIT licence, a compatible one. If we could use that, then the custom code we need for our "wasm in workers" scenario could be much smaller.

Yes, the generated code looks quite nice 🙂 It can be simplified at some places:

• the isRPCMessage check could be simplified or even completely eliminated. It currently does almost complete linting of the message structure. Usually you just check something like message.type === 'my-rpc-protocol'. And it could be eliminated because we competely control the postMessage channel between the worker and its creator (who owns the handle). It's not like sending messages to iframes which are "public" objects, available to any script through DOM API, where the iframe must be very careful about who it talks to.
• we probably don't need such a generic findTransferables implementation which finds transferables in any deeply nested field of any object. We could limit our APIs so that a transferable (i.e., a big binary buffer with image data) is always a standalone parameter.

But otherwise it looks good.

@jsnajdr - Excellent, thanks for the feedback. I can work on these changes specifically while also considering the alternative you suggested...

However! One alternative we should explore is using the @remote-ui/rpc library. That's also part of the Shopify stack, like @shopify/web-worker, and used internally by web-worker. That's basically a 1:1 replacement for @wordpress/worker-threads, and it has MIT licence, a compatible one. If we could use that, then the custom code we need for our "wasm in workers" scenario could be much smaller.

Which exact library are you referring to here?

I see https://github.com/developit/remote-ui from from Jason but not recently updated and the Shopify library it is forked from https://github.com/Shopify/remote-dom (renamed to remote dom at some point).

However! One alternative we should explore is using the @remote-ui/rpc library. That's also part of the Shopify stack, like @shopify/web-worker, and used internally by web-worker. That's basically a 1:1 replacement for @wordpress/worker-threads, and it has MIT licence, a compatible one. If we could use that, then the custom code we need for our "wasm in workers" scenario could be much smaller.

I asked Claude to analyze this option and got this response:

Analysis: @remote-ui/rpc as Alternative to @wordpress/worker-threads

Summary

@remote-ui/rpc is not a suitable replacement for @wordpress/worker-threads in the WASM image processing use case due to a fundamental limitation: it does not support ArrayBuffer or typed array transfer.

Critical Finding: ArrayBuffer Support

From the @remote-ui/rpc documentation, the following types are explicitly unsupported:

• Map, Set, WeakMap, WeakSet
• ArrayBuffer, typed arrays
• URL, RegExp
• Class instances

This is a blocking issue for the WASM image processing use case, which relies heavily on transferring large image buffers (often 50MB+) between the main thread and worker with zero-copy semantics.

Feature Comparison

Different Design Goals

@remote-ui/rpc

Designed for Shopify's UI extensibility model where:

• Extension code runs in a sandboxed worker
• UI components need event handlers/callbacks passed across the boundary
• Functions are proxied with automatic retain/release memory management
• Focus is on developer ergonomics for UI interactions

@wordpress/worker-threads

Designed for efficient binary data processing where:

• Large binary buffers (images, WASM memory) transfer between threads
• Zero-copy ArrayBuffer transfer is essential for performance
• Focus is on efficient data transfer, not function proxying

Current Implementation Details

How @wordpress/vips Uses Worker Threads

Main Thread: vipsResizeImage(id, 50MB buffer, ...)
  → wrap() creates CALL message with buffer
  → findTransferables() detects ArrayBuffer
  → postMessage with [buffer] in transfer list (zero-copy)
  → Worker receives buffer ownership
  → Worker processes with WASM (wasm-vips)
  → Worker returns new processed buffer
  → Main thread receives result with zero-copy

Transferables Auto-Detected by @wordpress/worker-threads

From packages/worker-threads/src/transferables.ts:

• ArrayBuffer
• MessagePort
• ImageBitmap
• OffscreenCanvas
• ReadableStream
• WritableStream
• TransformStream
• TypedArrays (Uint8Array, etc.)

What Would Be Required to Use @remote-ui/rpc

To use @remote-ui/rpc for this use case, you would need one of:

1. Add binary data support to @remote-ui/rpc - Major upstream change, unlikely to be accepted as it doesn't align with the library's design goals

2. Wrap @remote-ui/rpc with transferable handling - Would require writing the same transferable detection code that already exists in @wordpress/worker-threads, negating any simplicity benefit

3. Serialize binary data differently - e.g., Base64 encoding, which would:

   • Increase payload size by ~33%
   • Require encoding/decoding overhead
   • Eliminate zero-copy benefits
   • Destroy performance for large images

Code Size Comparison

@wordpress/worker-threads (717 lines total)

 57 lines - index.ts (exports)
206 lines - main-thread.ts (wrap, terminate)
152 lines - rpc.ts (message protocol)
140 lines - transferables.ts (auto-detection)
 79 lines - types.ts (TypeScript types)
 83 lines - worker-thread.ts (expose)

This is already minimal and purpose-built for the use case.

Recommendation

Keep @wordpress/worker-threads for the following reasons:

1. Fundamental incompatibility: @remote-ui/rpc cannot transfer ArrayBuffer/TypedArray, which is the core requirement for WASM image processing

2. Already minimal: The current implementation is only 717 lines and well-designed for its purpose

3. Different problems: The libraries solve different problems - function proxying vs. binary data transfer

4. No benefit: Switching would require adding the same transferable handling code, providing no simplification

Alternative Approaches to Explore

If the goal is to reduce custom code or use established libraries, consider:

1. Comlink (Google) - Supports transferables, similar API to worker-threads, MIT license

   • https://github.com/GoogleChromeLabs/comlink

2. workerize - Simpler but may not have full transferable support

3. threads.js - Full-featured worker library with transferable support

However, the current @wordpress/worker-threads implementation is already simple, well-tested, and fit for purpose.

Sources

• @remote-ui/rpc npm package
• Shopify remote-dom/rpc GitHub
• Remote rendering: Shopify's take on extensible UI
• @shopify/web-worker npm package

• the isRPCMessage check could be simplified or even completely eliminated. It currently does almost complete linting of the message structure. Usually you just check something like message.type === 'my-rpc-protocol'. And it could be eliminated because we competely control the postMessage channel between the worker and its creator (who owns the handle). It's not like sending messages to iframes which are "public" objects, available to any script through DOM API, where the iframe must be very careful about who it talks to.

Simplified in b98f484

• we probably don't need such a generic findTransferables implementation which finds transferables in any deeply nested field of any object. We could limit our APIs so that a transferable (i.e., a big binary buffer with image data) is always a standalone parameter.

Simplied in 55a5b22

@swissspidy I went ahead and removed HEIF support in be86016 which I am hopeful won't break anything :)

However! One alternative we should explore is using the @remote-ui/rpc library. That's also part of the Shopify stack, like @shopify/web-worker, and used internally by web-worker. That's basically a 1:1 replacement for @wordpress/worker-threads, and it has MIT licence, a compatible one. If we could use that, then the custom code we need for our "wasm in workers" scenario could be much smaller.

@jsnajdr I took another pass at simplifying our library, leveraging comctx https://github.com/molvqingtai/comctx in #74702

This rcp library is MIT licensed and actively maintained (although not incredibly popular).

Which exact library are you referring to here?

This is an interesting question 🙂 There is the @remote-ui/rpc package published on NPM. Version 1.4.7, last published in June 2025 by the shopify-dep user. MIT license, recently updated, doesn't look bad.

But where are the sources? Not easy to find, but turns out they are in the Shopify/remote-dom repo. Just not in the main branch, but in the special remote-ui branch. I have no idea what that means 🙂 What is the relationship between remote-ui and remote-dom and what it says about the development and maintentance of remote-ui.

Note: remote-ui has been completely rewritten to use native DOM APIs and now has a new name, Shopify/remote-dom#267. The original @remote-ui libraries documented here will continue to work, but only bugfixes will be made on this project going forward. We recommend you follow the migration guide to adopt the new, more flexible DOM environment used by Remote DOM.

@swissspidy I went ahead and removed HEIF support in be86016 which I am hopeful won't break anything :)

FWIW, this would break AVIF support. Note that wasm-vips doesn't support HEIC as it includes patent-encumbered HEVC-related logic.

@kleisauke super - thanks for jumping in to clarify that! I will revert that commit - we certainly want AVIF support. I was under the impression from previous discussions that we needed to unbundle the vips heif support because of the licensing issues.

@remote-ui/rpc is not a suitable replacement for @wordpress/worker-threads in the WASM image processing use case due to a fundamental limitation: it does not support ArrayBuffer or typed array transfer.

This would be an additional reason why the original @shopify/web-worker library is unsuitable for the vips package. In addition to the Babel/webpack plugin issues, it wouldn't be able to to transfer image data to the worker and back, because it internally uses @remote-ui/rpc. I wonder if this ever worked at all in the media-experiments project.

I don't know how you got to this conclusion. It definitely works in that plugin. IIRC they added ArrayBuffer support at some point, but it was not documented in the readme.

I don't know how you got to this conclusion. It definitely works in that plugin. IIRC they added ArrayBuffer support at some point, but it was not documented in the readme.

This was from Claude so possible out of date or just wrong. Thanks for clarifying.

I don't know how you got to this conclusion. It definitely works in that plugin.

That's the conclusion of the Claude analysis in #74629 (comment). Which probably relied solely on the (outdated) information in the README.

Now when we settled on comctx it no longer matters that much, though.

Closing in favor of #74785 which leverages comctx.