Node.js 26.12.0: Clearer errors for unsupported WebAssembly, new WebSocket masking functions

1. Distinguishing failure causes in unsupported environments

WebAssembly runs separately compiled modules. The error-handling change states that importing such a module without WebAssembly support raises ERR_WEBASSEMBLY_NOT_SUPPORTED. This signals missing functionality with an error that programs can catch and handle.

However, this change should not be read as making previously working features fail. The review discussion described it as reporting existing errors more appropriately.

The fast-call path for external library functions is also covered. Even if other call requirements are met, a failed check for readable, executable memory support reports ERR_RX_MEMORY_NOT_SUPPORTED. Support is also checked after callback allocation fails, while platform-specific static call linkage and other errors are preserved.

The documentation also states that no fallback is guaranteed when required execution capabilities are missing. Catching an error does not mean the feature will run another way. Regression tests were added for execution with just-in-time compilation disabled and environments with Linux system-call restrictions.

2. Moving repetitive WebSocket operations into built-in functions

A WebSocket client masks each outgoing frame, or transmission unit, by repeatedly applying a 4-byte key. The server reverses this with the same operation. Exclusive OR yields 1 when the two bits differ, so applying the same key again restores the original data.

http.websocketMask() takes a source and an output location to perform masking, while http.websocketUnmask() reverses it in the received buffer itself. These functions target WebSocket's fixed key length, not general-purpose data masking.

The argument signatures match the existing native add-on bufferutil. Libraries using it can therefore check for the new functions and switch. The proposal's author put the add-on's installation rate at about 3% of ws downloads, saying the remaining users mainly rely on JavaScript loops.

3. Preparing the key remains the caller's responsibility

The mask is accepted as an ArrayBufferView over a memory region. The review retained compatibility with the existing add-on rather than accepting a proposal to also support numeric arrays. The author suggested taking a 4-byte slice from a communication library's existing buffer to avoid allocating an array for each frame. The original expression was:

buffer.subarray(bufIdx, bufIdx += 4)

This obtains a memory region for the key, rather than showing a complete call to the new functions. Built-in operations do not remove the need to select keys. The specification cited in the review requires a fresh, unpredictable key for each frame. The discussion also noted that the server receives data that is already masked.

4. Performance gains must be read alongside input size

The WebSocket change's commit description reported roughly 20 times the speed of JavaScript loops for 1 KiB inputs and 40 times for 64 KiB. It listed gains over the existing add-on for inputs of 32 bytes or more. However, the author said loops were faster below 24 bytes because of internal function-call overhead. The measurement hardware and operating system were not specified.

The benefit is moving repetitive operations to a built-in implementation without installing a separate add-on. Library developers still need to consider feature detection for older versions and path selection by input size. These operation-level speed differences should therefore not be read as throughput gains for an entire WebSocket service.

This release matters more to developers working with restricted execution environments and WebSocket implementations than to those seeking broader general application features.