How far has WebAssembly come? From Photoshop to the checkout

What goes into a Photoshop brushstroke?

Open a photograph, select a brush and draw a line. To the person drawing, this is one gesture. To the developer, drawing the toolbar, reading the pen position and changing the pixels are different jobs. Reimplement a desktop brush for the browser and the first challenge is reproducing the same stroke, including years of small adjustments to the original.

In their account of taking Photoshop to the web, Adobe and Chrome engineers describe compiling existing C++ with Emscripten to WebAssembly (Wasm) and combining it with a web interface. Reusing that image-processing work is a benefit a speed benchmark can easily miss. ^[1]

Wasm is a common instruction format that compilers can target. A developer can write a routine in C++ or Rust, then distribute a module that a browser or standalone runtime validates and executes. Think of a printing plate that fits two presses. The plate does not need to describe how to feed the paper, but each press still has limits on the size of sheet it accepts.

What became easier with 3.0?

When Wasm arrived in major browsers in 2017, arithmetic and operations on contiguous memory were natural fits. The core specification grew, reaching its 3.0 milestone in September 2025. To understand the changes, consider the obstacles a particular program encountered. ^[2]

A 32-bit address can distinguish 4 GiB of bytes. More addressable space does not guarantee that a phone can open a huge photograph. Even a small compressed file can require decoded pixels, a working copy and undo history at the same time. Peak memory on the target device matters more than the download size for that operation. Support also varies by feature and runtime. ^[3]

Which part of a brushstroke gets faster?

A 4,000 by 3,000 image with one byte each for red, green, blue and alpha occupies 48 MB decoded. Separate input and output buffers bring that to 96 MB. This is a sizing calculation, not a measured memory profile. It reveals allocation and copying costs before we have timed a single instruction.

Calling a Wasm function from JavaScript for each pixel crosses the boundary 12 million times. Pass the buffer once and the same correction can run in a single call. Applying one operation to consecutive pixels also makes the loop a candidate for SIMD instructions that act on several values together. A page that spends most of its time waiting for a network response gains little from a faster pixel loop.

Measure the first download and initialization on a fresh device, the time for subsequent images and the delay until the user sees a result. A long synchronous routine on the main thread can still freeze a button. Moving work to a worker may improve responsiveness even when the computation itself takes just as long.

When does the visitor actually wait?

A developer may already have the module and test photo cached. A traveler on a slow connection can see the interface immediately, then wait for the engine only after pressing Edit. Record page open, first interaction, preview and completed save as separate timestamps. Deferring a download moves waiting time. Also try replacing the photo mid-operation. A late result for the old photo must not overwrite the current preview.

Ask whether the job requires changing the displayed appearance or producing a new file for another application. A display-only effect may need no decoded buffer in application code. An exported image requires the saved pixels to agree with what the user saw. Reuse also has a maintenance dimension: sharing a decoder can share test fixtures and fixes, but both target environments still need a regression check after a toolchain upgrade.

One technology, two quite different jobs

SQLite's browser distribution brings an existing SQL engine onto the device. A field guide could build a local index and remain searchable in an area with poor reception. Running the query and keeping the database after the tab closes are separate requirements. SQLite documents origin-private file system (OPFS) options with different worker and concurrency requirements. Quotas and persistence can also change in private browsing. ^[4]

With Shopify Functions, Shopify runs an extension against inputs such as cart data and consumes its output to apply business logic such as discounts. Merchants can introduce distinct rules while the platform controls how results affect checkout. The benefit here is a predictable place to plug in someone else's code. Plans and distribution methods affect which features merchants can use. ^[5]

In both examples the host matters. A Wasm instruction cannot on its own open a file picker or change an order. The host chooses which capabilities to supply and what to do with a returned value. Preventing out-of-bounds memory access and ensuring appropriate use of customer information supplied by the host are separate design questions.

Outside the browser, what does WASI 0.3 add?

Taking a module to a server raises a practical question. How does it access a clock, file or network connection? WASI defines interfaces for such host capabilities. Core Wasm 3.0 describes instructions and types. WASI 0.3, announced in June 2026, describes how software works with its surroundings. Their version numbers track different projects. ^[6]

The Component Model allows components written in different languages to exchange strings and records through typed contracts. A major development in WASI 0.3 is asynchronous work. An HTTP body can be represented as a stream, allowing another component to process portions as they arrive. This can avoid accumulating an entire response in memory. Designers still need to decide what happens when a consumer slows down or cancels.

Portability is easiest to estimate one dependency at a time. A conversion routine may travel unchanged while a graphical interface or a cloud provider's authentication flow needs a new adapter. List the host interfaces the routine needs and check that both deployment targets implement compatible versions.

What adoption numbers can tell us about the future

The 2025 Web Almanac observed Wasm on 0.35% of desktop sites and 0.28% of mobile sites in its sample. These figures measure neither the share of users nor the share of computation. An editor opened after login and a server-side checkout function are hard to capture with a public page crawl. The denominator matters for a technology concentrated in particular features. ^[7]

Over the next few years, bringing existing engines onto devices looks promising. Document search and image conversion can benefit from keeping input off a remote service. A large initial download for a feature used once a year could erase that advantage. Watch for substantial features shipping successfully on inexpensive devices, an indicator more informative than a list of supported languages.

On servers, distributing extensions is another plausible direction. A converter or business rule with narrow inputs and outputs can evolve separately from its host. Standardized asynchronous I/O helps, but operators still need to trace a stalled request to the right component. Production examples that carry one component between runtimes while retaining visibility into errors, latency and permissions would strengthen this forecast. These are conditions to watch as of November 2026.

Search that already moved onto the device

In January 2026 the VS Code team described docfind, a Rust and Wasm search engine for its documentation. The site build constructs an index and ships a Wasm module containing the search data. By the time a visitor types a query, the expensive job of building that index is over. ^[8]

Moving the index also changes updates. A server-side index can incorporate a correction for the next query. When clients download an index, results depend on the version each client holds. Cache invalidation becomes part of search design. Public manuals are a natural fit. With departmental documents, even a search suggestion might disclose a restricted title. Partition the index by what each reader may receive, or keep access-controlled queries on the server.

A small experiment for your own application

For photo correction, make just the processing routine interchangeable. Use the same input and expected output. Check rounding and edge pixels before comparing speed, since an implementation that quietly skips work can appear faster. Test both thumbnails and full-resolution photos. Setup may dominate one while the pixel loop dominates the other.

Keep one-off visits separate from batches of dozens of photos. Frequency determines whether initialization pays off and whether the module belongs in the first download. Define success for the finished job: offline editing could justify a slower conversion, while a small administrative display might not justify a new toolchain. The decision differs depending on whether you value speed, reuse, local processing or constrained extensions.

References

1. [1]Photoshop engineering case study ↩
2. [2]Wasm 3.0 completion announcement ↩
3. [3]Official feature matrix ↩
4. [4]SQLite persistence options ↩
5. [5]Shopify Functions ↩
6. [6]WASI 0.3 announcement ↩
7. [7]HTTP Archive methodology and results ↩
8. [8]The engineering account ↩