Adobe Developers Use WebAssembly to Improve Users’ Lives
Adobe has been vocal about how it is developing and relying on WebAssembly to support its customer-user experience — and a lot of interesting research is being done for future developments.
Adobe’s resource-intensive application Photoshop when running on a PC is now available on the browser. The user accesses the commands and functionality of Photoshop without having to download the software (again, thanks to Wasm). Adobe has worked with the Google Chrome team to bring the latest WebAssembly features to its web applications such as Pthreads, OPFS (origin private file system) Access Handles and DWARF (debugging with attributed record formats) debugging support. Supported browsers include Google Chrome, Microsoft Edge (version 102 and above (64-bit)) and Firefox (version 111 and above on desktop).
As Dr. Thomas Steiner, developer relations engineer at Google, described in a “Chrome for Developers” video “Bringing Adobe’s Creative Cloud to the Web: Starting with Photoshop,” it became obvious that WebAssembly’s power for distributing applications early on, following initial skepticism. “Whenever I was asked by one of our partners if they should be building for the web, I would always say, ‘Yes, unless you’re building something like Photoshop.’ I used Photoshop as the generic example for an app that I could never imagine to be built on the web — boy, was I wrong,” Steiner said. Then, during a demo, “Adobe blew everyone’s minds, including mine,” Steiner said.
Photoshop’s availability to run on the browser is largely due to Adobe’s use of open source emscripten. Emscripten is a compiler toolchain for Wasm modules for C or C++. This means that you can use emscripten to compile code written in C or C++ or other languages that use LLVM into WebAssembly that can be run not only on the browser but in Node.js or other WebAssembly runtimes.
However, while Emscripten offers an excellent way to port C++ runtimes to WebAssembly, each individual project can often require a lot of work, according to a blog post. This work may involve configuring the C++ code or, in the case of Photoshop, adapting encryption for use in other WebAssembly modules. Unfortunately, Photoshop had been run on browsers previously, but it was too slow, even with Chrome.
According to the blog post “Photoshop’s Journey to the Web,” Nabeel Al-Shamma, a retired principal scientist at Adobe, and Thomas Nattestad, a project manager at Google, Google and Adobe collaborated to address associated bottlenecks to run Photoshop in the browser. This collaboration was crucial for porting Photoshop to the web through WebAssembly on Chrome. Additionally, significant work was done on exception-based error handling, which Emscripten wasn’t well-configured for, according to Al-Shamma and Nattestad. They described how they worked with the WebAssembly community group in the W3C to improve the tooling for handling these errors when porting C++ runtimes to WebAssembly.
Furthermore, WebAssembly offers advanced performance primitives, including SIMD instructions, to enhance application performance in browsers or web apps, Al-Shamma and Nattestad wrote. As an example, they mentioned Halide, which is essential for Adobe’s performance on the web. It provides a 3-4x speedup on average and, in some cases, an 80-160x speedup, they wrote.
Moreover, there was a major effort to offer WebAssembly debugging support, as detailed in the blog post. Chrome provides support for stepping through source code, setting breakpoints, pausing on exceptions and variable inspection with rich type support. Additionally, basic support for evaluation in the DevTools console is available, Al-Shamma and Nattestad wrote.
More to Come
Adobe is also working with Wasm and the WASI component standard to allow users to sign a document in Adobe Sign or edit an image in Adobe’s Lightroom. But this effort remains a work in progress: “Hopefully we will someday, but not yet,” Colin Murphy, senior software engineer at Adobe, told The New Stack. “We aren’t using WASI in production yet, just Wasm in the browser for now.”
Indeed, many of Adobe’s capabilities to extend applications across the Web on the browser with Wasm and beyond hinge on the WASI standard. WebAssembly’s WASI Preview 2 was recently released with promise for the future. The WASI standardization work has been in progress for a long time, predating much of the widespread use of WebAssembly in applications and it’s still not completely ready.
Wasm’s evolution has led to the need for a component model and especially its relationship to WASI, which is the standard Interface or API linking the web assembly modules to the components. A WebAssembly component plays a critical role in how runtimes that run inside WebAssembly modules are deployed.
Once finalized, a component model that will enable WebAssembly to not just see its expanding use beyond web browsers and servers — but will be able to allow users to deploy different applications running inside numerous lightweight modules at very high speeds across thousands of endpoints simultaneously through a component interface called the without changing one iota of code.
“The release of WASI Preview 2 is an important milestone for the WASI standard, not only in that it is a stable target for platforms and language toolchains but also in that it is no longer simply an interface that allows Wasm outside of the browser,” Murphy said. “The WASI component model is a divergence from browser Webassembly and allows for radical new ways of building backend systems.”
The Jco toolchain allows for WebAssembly components to be transpiled to ES6 modules, but native support in browser engines for components does not seem likely for quite some time, Murphy said. “I’m optimistic that Adobe will continue to be a leader in Wasm/WASI just as it has in browser WebAssembly. Almost every microservice at Adobe could be reimplemented with Wasm/WASI,” Murphy said.
Others at Work
Adobe and the aforementioned Google are certainly not the only entities hard at work on developing the WebAssembly standard. Those companies using it to stream video include Netflix, Amazon Prime, Disney and others. Microsoft is not very verbose about much of its previous work in WebAssembly (Microsoft could not comment for a previous article when queried) but it has been confirmed the company has already begun to use WebAssembly to support its operations mostly while continuing to actively contribute to the development of Wasm for the community. In Microsoft’s case, its work with WebAssembly dates back years. Microsoft Flight Simulator for some years now has used WebAssembly for mod protection, for example, when it was shown to improve both security and portability for add-ons distributed as WebAssembly modules. Excel Online uses WebAssembly for calculating Lambda functions.
Most of Microsoft’s work now consists of investing in the upcoming component model and WASI. For example, Microsoft is expanding the Azure Kubernetes Service WASI NodePool preview and giving its services additional hypervisor protection per request on top of the Wasm sandbox with the Hyperlight project. Outside of the edge browser, Microsoft is investing mainly in server-based Wasm and the Wasm component ecosystem surrounding the Bytecode Alliance, as well as in infrastructure and language tooling to enable productive use and WASI, of course.
