Thomas Nattestad on web.dev

Build in-browser WordPress experiences with WordPress Playground and WebAssembly

2023-04-12T00:00:00Z

When you first see WordPress Playground, it seems like an ordinary site–maybe except for the colorful background. It's anything but. What you're actually looking at is an entire WordPress tech stack, including PHP and a database, running directly in your browser.

In this post, Adam Zieliński (lead of WordPress Playground) and Thomas Nattestad (Product Manager for V8) explore:

How WordPress Playground can help you as a WordPress developer.
How it works under the hood.
What it means for the future of WordPress.

Use WordPress without installation, embed it in your app, and even control it with JavaScript #

You can use and customize the WordPress embedded at playground.wordpress.net for free. There's no cloud infrastructure and support to pay for, because that site lives entirely in your browser–no one else can visit it. It's also temporary. As soon as you refresh the page, it's gone. You can get as many of these sites as you want for prototyping, trying out plugins, and quickly exploring ideas.

You can even use them to test your code in different environments using the built-in PHP and WordPress version switcher:

WordPress Playground is an entirely new way of using WordPress. Its full power, however, is only unlocked by including it in your app. The easy way is to embed WordPress Playground in an <iframe> and configure it using the query parameters API. That's what the official showcase does. When you select, for example, the Pendant theme and the Coblocks plugin, the embedded iframe gets updated to point to https://playground.wordpress.net/?theme=pendant&plugin=coblocks.

The iframe is an easy way of getting started, but it's also limited to just the basic configuration option. If you need more than that, there is another, more powerful API.

The WordPress Playground JavaScript client enables full control over the embedded site #

You can control the entire WordPress site, including the filesystem and PHP, using the full API available via the @wp-playground/client npm package. The following example shows to use it—check the interactive tutorial for even more examples:

import {
  connectPlayground,
  login,
  connectPlayground,
} from '@wp-playground/client';

const client = await connectPlayground(
  document.getElementById('wp'), // An iframe
  { loadRemote: 'https://playground.wordpress.net/remote.html' },
);
await client.isReady();

// Login the user as admin and go to the post editor:
await login(client, 'admin', 'password');
await client.goTo('/wp-admin/post-new.php');

// Run arbitrary PHP code:
await client.run({ code: '<?php echo "Hi!"; ?>' });

// Install a plugin:
const plugin = await fetchZipFile();
await installPlugin(client, plugin);

Use WebAssembly PHP even without WordPress #

WordPress Playground is not a monolith. WebAssembly PHP is released independently from WordPress and you can use it separately as well. For the web, you may use the @php-wasm/web npm package optimized for a low bundle size, and in Node.js you can lean on @php-wasm/node which provides more PHP extensions. Adam used the former to add interactive PHP snippets to this WP_HTML_Tag_Processor tutorial. Here's a sneak peek of how to use it:

import { PHP } from '@php-wasm/web';
const php = await PHP.load('8.0', {
  requestHandler: {
    documentRoot: '/www',
  },
});

// Create and run a script directly
php.mkdirTree('/www');
php.writeFile('/www/index.php', `<?php echo "Hello " . $_POST['name']; ?>`);
php.run({ scriptPath: '/www/index.php' });

// Or use the familiar HTTP concepts:
const response = php.request({
  method: 'POST',
  relativeUrl: '/index.php',
  data: { name: 'John' },
});
console.log(response.text); // Hello John

At this point you must be thinking–how does that even work? Great question! Let's dive into the internals and find out. Buckle up!

Under the hood, there's WebAssembly PHP, a SQL translator, and an in-browser server #

PHP runs as a WebAssembly binary #

PHP doesn't just work in the browser out of the box. WordPress Playground developed a dedicated pipeline to build the PHP interpreter to WebAssembly using Emscripten. Building vanilla PHP isn't overly complex–it only takes adjusting a function signature here, forcing a config variable there, and applying a few small patches. Here's how you can build it yourself:

git clone https://github.com/WordPress/wordpress-playground
cd wordpress-playground && npm install
# Below, you can replace "8.2" with any other valid PHP version number.
npm run recompile:php:web:8.2

However, vanilla PHP builds aren't very useful in the browser. As a server software, PHP doesn't have a JavaScript API to pass the request body, upload files, or populate the php://stdin stream. WordPress Playground had to build one from scratch. The WebAssembly binary comes with a dedicated PHP API module written in C and a JavaScript PHP class that exposes methods like writeFile() or run().

Because every PHP version is just a static .wasm file, the PHP version switcher is actually pretty boring. It simply tells the browser to download, for example, php_7_3.wasm instead of, say, php_8_2.wasm.

Database is supported with a SQL translation layer #

WordPress requires MySQL. However, there isn't a WebAssembly version of MySQL you could run in the browser. WordPress Playground therefore ships PHP with the native SQLite driver and leans on SQLite.

But how can WordPress run on a different database?

Behind the scenes, the official SQLite Database Integration plugin intercepts all MySQL queries and rewrites them in SQLite dialect. The 2.0 release ships a new WordPress Playground-informed translation layer that allows WordPress on SQLite to pass 99% of the WordPress unit test suite.

The web server lives inside the browser #

In a regular WordPress, clicking on a link, say Blog, would initiate an HTTP request to the remote backend to fetch the blog page. However, WordPress Playground has no remote backend. It has a Service Worker that intercepts all the outgoing requests and passes them to an in-browser PHP instance running in a separate Web Worker.

Networking is supported through WebSockets #

When it comes to networking, WebAssembly programs are limited to calling JavaScript APIs. It is a safety feature, but also presents a challenge. How do you support low-level, synchronous networking code used by PHP with the high-level asynchronous APIs available in JavaScript?

For WordPress Playground, the answer involves a WebSocket to TCP socket proxy, Asyncify, and patching deep PHP internals like php_select. It's complex, but there's a reward. The Node.js-targeted PHP build can request web APIs, install composer packages, and even connect to a MySQL server.

WordPress can be used in even more places than the browser #

Since WordPress can now run on WebAssembly, you could also run it in a Node.js server—it's the same V8 engine! Of course with StackBlitz you can also run Node.js directly in the browser, meaning that you could run WordPress and PHP compiled to WebAssembly, executing in Node.js, which is also compiled to WebAssembly running in the browser. WebAssembly is also exploding in popularity in the serverless space, and in the future this could run on that infrastructure as well.

The future may bring zero-setup, interactive, and collaborative WordPress apps #

Imagine jumping straight into a code editor where you're free to just get building right away, with all of the setup completed. You could even share a simple link and start a multiplayer editing session, such as in Google Docs. And when you're done, it would only take a single click to seamlessly deploy your creations to a variety of hosting services–all without ever installing anything locally!

And that's just a glimpse! We may see interactive tutorials, live plugin demos, staging sites, decentralized WordPress on edge servers, and even building plugins on your phone.

The future is exciting and you can be a part of it! Your ideas and contributions are the oxygen of WordPress Playground. Visit the GitHub repository, say hi in the #meta-playground WordPress.org Slack channel, and feel free to contact Adam at adam@adamziel.com.

New functionality for developers—brought to you by WebAssembly

2023-04-03T00:00:00Z

WebAssembly enables developers to bring new performant functionality to the web from other languages. Over the past few years developers have really taken advantage of the possibilities. This post showcases just a few of the shiny new tools that you can benefit from, thanks in part to WebAssembly.

Tools and libraries you can use now #

Without further ado, let's jump into the good stuff :D

SQLite #

This complete port of SQLite brings a lightweight, embedded, relational database management system into your hands. To learn more read this blog post that showcases this incredible port and how to use it.

FFmpeg.wasm #

FFmpeg is a free and open-source software project consisting of a suite of libraries and programs for handling video, audio, and other multimedia files and streams. You can find a wasm compiled version here (github repo) that lets you do all of this functionality directly in the browser.

Universal Scene Description (USD) #

Universal Scene Description (USD) is a framework for 3D computer graphics data that focuses on collaboration, non-destructive editing, and enabling multiple views and opinions about graphics data. It's an industry standard supported by the likes of Pixar, Autodesk, Nvidia, and many more. It's still early days for their web support but Autodesk already open sourced a web based USD viewer which you can see here.

CanvasKit #

CanvasKit is Skia, the rendering engine of Chrome and Android, compiled directly to WebAssembly. With it, you get simple JavaScript API access to practically all the power of the Skia rendering engine. The functionality includes complex rendering, text shaping, animation, inking, and more. Check out the npm package and quickstart guide.

TensorFlow.js #

TensorFlow.js brings the power of TensorFlow directly into the browser with a simple JavaScript API. Under the hood, it optimizes models both across the GPU and CPU (including SIMD optimizations) to maximize performance. You can see the getting started guide or look at some of their demos directly.

OpenCV #

OpenCV is an industry standard of programming functions mainly for real-time computer vision. There is an easy-to-use npm package here, and for Emscripten users there are also detailed instructions for doing a full build. For a look at how SIMD and threads are improving performance of these workloads, you can watch this section of the Modern WebAssembly Chrome Dev Summit talk.

Cocos #

Cocos is a powerful and popular game engine that enables developers to build games with cross platform support and this now includes the web. It joins the long list of game engines that enable web export through wasm. To get started, jump into the Cocos editor and follow these instructions.

Conclusion #

In addition to these specific examples, there is much to be excited about in terms of WebAssembly's potential to change the pace of new web functionality. Chrome has even set up the Advanced Web Apps Fund that can help developers fund their work to advance the web functionality available to all developers!

Hero image from Pexels, by Ann Marie Kennon.

Photoshop's journey to the web

2021-10-26T00:00:00Z

Over the last three years, Chrome has been working to empower web applications that want to push the boundaries of what's possible in the browser. One such web application has been Photoshop. The idea of running software as complex as Photoshop directly in the browser would have been hard to imagine just a few years ago. However, by using various new web technologies, Adobe has now brought a public beta of Photoshop to the web.

(If you prefer watching over reading, this article is also available as a video.)

In this post, we'd like to share for the first time the details of how our collaboration is extending Photoshop to the web. You can use all the APIs Adobe used and more in your own apps as well. Be sure to check out our web capabilities related blog posts for inspiration and watch our API tracker for the latest and greatest we're working on.

Why Photoshop came to the web #

As the web has evolved, one thing that hasn't changed are the core advantages that websites and web apps offer over platform-specific applications. These advantages include many unique capabilities such as being linkable, ephemeral, and universal, but they boil down to enabling simple access, easy sharing, and great collaboration.

The simple power of a URL is that anyone can click it and instantly access it. All you need is a browser. There is no need to install an application or worry about what operating system you are running on. For web applications, that means users can have access to the application and their documents and comments. This makes the web the ideal collaboration platform, something that is becoming more and more essential to creative and marketing teams.

Google Docs was a pioneer of this simplified access. Most of us know how easy it is to start a document, send the link to someone, and immediately jump into not only the application, but the specific document or comment as well. Since then, a plethora of amazing applications, such as those we've shown off in the past, have adopted this model and now Photoshop, too, will benefit.

How Photoshop came to the web #

The web started out as a platform only suited for documents, but has grown dramatically throughout its history. Early apps like Gmail showed that more complex interactivity and applications were at least possible. Since then, we've seen impressive co-development where web apps push the boundaries of what's possible, and browser vendors respond by further expanding web capabilities. The latest iteration of this virtuous loop is what has enabled Photoshop on the web.

Adobe previously brought Spark and Lightroom to the web and had been interested in bringing Photoshop to the web for many years. However, they were blocked by the performance limitations of JavaScript, the absence of a good compile target for their code, and the lack of web capabilities. Read on to learn what Chrome built in the browser to solve these problems.

WebAssembly porting with Emscripten #

WebAssembly and its C++ toolchain Emscripten have been the key to unlocking Photoshop's ability to come to the web, as it meant that Adobe would not have to start from scratch, but could leverage their existing Photoshop codebase. WebAssembly is a portable binary instruction set shipping in all browsers that was designed as a compilation target for programming languages. This means that applications such as Photoshop that are written in C++ can be ported directly to the web without requiring a rewrite in JavaScript. To get started porting yourself, check out the full Emscripten documentation, or follow this guided example of how to port a library.

Emscripten is a fully-featured toolchain that not only helps you compile your C++ to Wasm, but provides a translation layer that turns POSIX API calls into web API calls and even converts OpenGL into WebGL. For example, you can port applications that reference the local filesystem and Emscripten will provide an emulated file system to maintain functionality.

Emscripten has been capable of bringing most parts of Photoshop to the web for a while, but it wasn't necessarily fast enough. We have continually worked with Adobe to figure out where bottlenecks are and improve Emscripten. Photoshop depends upon multithreading. Bringing dynamic multithreading to WebAssembly was a critical requirement.

Also, exception-based error handling is very common in C++, but wasn't well supported in Emscripten and WebAssembly. We have worked with the WebAssembly Community Group in the W3C to improve the WebAssembly standard and the tooling around it to bring C++ exceptions to WebAssembly.

Emscripten doesn't just work on large applications, but also lets you port libraries or smaller projects! For example, you can see how you can compile the popular OpenCV library to the web through Emscripten.

Lastly, WebAssembly offers advanced performance primitives such as SIMD instructions which dramatically improve your web app performance. For example, Halide is essential to Adobe's performance, and here SIMD provides a 3–4× speedup on average and in some cases a 80–160× speedup.

WebAssembly debugging #

No large project can be successfully completed without the appropriate tools for the job, and it's for this reason that the Chrome team developed full featured WebAssembly debugging support. It provides support for stepping through the source code, setting breakpoints and pausing on exceptions, variable inspection with rich type support, and even basic support for evaluation in the DevTools console!

Be sure to check out the authoritative guide on how to utilize WebAssembly Debugging.

High performance storage #

Given how large Photoshop documents can be, a critical need for Photoshop is the ability to dynamically move data from on-disk to in-memory as the user pans around. On other platforms, this is accomplished usually through memory mapping via mmap, but this hasn't been performantly possible on the web—that is until origin private file system access handles were developed and implemented as an origin trial! You can read how to leverage this new API in the documentation.

P3 color space for canvas #

Historically, colors on the web have been specified in the sRGB color space, which is a standard from the mid-nineties, based on the capabilities of cathode-ray tube monitors. Cameras and monitors have come a long way in the intervening quarter-century, and many larger and more capable color spaces have been standardized. One of the most popular modern color spaces is Display P3. Photoshop uses a Display P3 Canvas to display images more accurately in the browser. In particular, images with bright whites, bright colors, and details in shadows will display as best as possible on modern displays that support Display P3 data. The Display P3 Canvas API is being further built upon to enable high dynamic range displays.

Web Components and Lit #

Photoshop is a famously large and feature-rich application, with hundreds of UI elements supporting dozens of workflows. The app is built by multiple teams using a variety of tools and development practices, but its disparate parts need to come together into a cohesive, high-performing whole.

To meet this challenge, Adobe turned to Web Components and the Lit library. Photoshop's UI elements come from Adobe's Spectrum Web Components library, a lightweight, performant implementation of the Adobe design system that works with any framework, or no framework at all.

What's more, the entire Photoshop app is built using Lit-based Web Components. Leaning on the browser's built-in component model and Shadow DOM encapsulation, the team found it easy to cleanly integrate a few "islands" of React code provided by other Adobe teams.

Service worker caching with Workbox #

Service workers act as a programmable local proxy, intercepting network requests and responding with data from the network, long-lived caches, or a mixture of both.

As part of the V8 team's efforts to improve performance, the first time a service worker responds with a cached WebAssembly response, Chrome generates and stores an optimized version of the code—even for multi-megabyte WebAssembly scripts, which are common in the Photoshop codebase. A similar precompilation takes place when JavaScript is cached by a service worker during its install step. In both cases, Chrome is able to load and execute the optimized versions of cached scripts with minimal runtime overhead.

Photoshop on the web takes advantage of this by deploying a service worker that precaches many of its JavaScript and WebAssembly scripts. Because the URLs for these scripts are generated at build time, and because the logic of keeping caches up to date can be complex, they turned to a set of libraries maintained by Google called Workbox to generate their service worker as part of their build process.

A Workbox-based service worker along with the V8 engine's script caching led to measurable performance improvements. The specific numbers vary based on the device executing the code, but the team estimates these optimizations decreased the time spent on code initialization by 75%.

What's next for Adobe on the web #

The launch of the Photoshop beta is just the beginning, and we've got several performance and feature improvements already underway as Photoshop tracks towards their full launch after this beta. Adobe isn't stopping with Photoshop and plans to aggressively expand Creative Cloud to the web, making it a primary platform for both creative content creation and collaboration. This will enable millions of first-time creators to tell their story and benefit from innovative workflows on the web.

As Adobe continues to push the boundaries of what's possible, the Chrome team will continue our collaboration to drive the web forward for Adobe and the vibrant web developer ecosystem in general. As other browsers also catch up on these modern browser capabilities, we're excited to see Adobe make their products available there as well. Stay tuned for future updates as we continue to push the web forward!

You can learn more about accessing Photoshop on the web (beta) in the Adobe Help Center.