A new architecture for publishing web content to desktop

For several years, if you wanted to publish web content made in HTML/CSS/JS as a desktop app, the answer has been to use Electron or NW.js. For us, we've long supported publishing games made in Construct, our fully browser-based game creation tool, to desktop using NW.js. However we recently began to feel like we'd run in to the limits of this approach. In the end we decided to build something new. This blog outlines the problems with the existing desktop publishing frameworks, why we went with our own solution, and how it works.

Limits of Electron/NW.js

Electron and NW.js both have a similar architecture: it's a full copy of the Chromium browser engine (used in the Chrome, Edge and Opera browsers), but also with node.js integrated. Node.js provides access to lots of additional capabilities, ranging from hosting servers to file system access, allowing desktop applications to do more than they otherwise could in a normal browser.

For us are three major downsides with this approach:

1. As is widely remarked upon in the tech world, shipping a full copy of a browser engine with your app is pretty inefficient. To illustrate this, an empty Construct project exported to HTML5 is just 240 KB compressed, but an empty NW.js export for Windows 64-bit is about 116 MB compressed. I don't think this matters as much as people think in an age of terabyte storage drives and 100 GB game downloads, but it is inefficient if you have loads of different copies of browser engines installed with all your apps, and it also loses the benefits of auto-updating browsers.
2. Over time, for us, the node.js component has largely become redundant. Years ago we used node.js for things like file system access, clipboard access, and so on. Virtually all of that is now possible in browsers themselves. We moved over to using browser APIs, and now we use node.js for virtually nothing. It doesn't seem great to have a highly complex component integrated unnecessarily. All we really need is the browser engine by itself.
3. Integrating C/C++ SDKs is tricky. Accessing a C++ component from node.js opens up a whole can of worms involving Application Binary Interfaces (ABIs) - the precise binary data and function calls used to interact with a native addon. This has become important for us as users want to be able to integrate their games with services like Steam and Epic Games. Modern node.js has something like four ways of writing native addons, and the most modern approach looks OK (if you can find the right samples and documentation for it), but is still quite complicated to use. Things get still more complicated when integrating with NW.js, which so far I've been entirely unable to get to work at all. Further, ABI changes between versions mean you have to keep recompiling native addons with every update, which is a maintenance pain. To illustrate the problems with this, we previously used Greenworks to integrate NW.js and Steam; it required regular rebuilding, and is now unmaintained (a risk you take relying on small open-source projects). I don't believe any such equivalent exists for Epic Games either. What we really want is a simple and direct as possible way to integrate a C/C++ SDK with JavaScript.

So in short we want to avoid bundling a browser engine, skip the node.js integration, and have a better way to integrate C/C++ SDKs.

Other frameworks

There don't seem to be any existing frameworks that fulfill all of this. There don't seem to be many desktop web frameworks to begin with, probably because Electron/NW.js are the de-facto standard options.

One option could be Tauri. This looks like it may well be a very good framework for many uses, but two things put me off it. First of all it appears to be based on Rust - a modern alternative to C/C++. Not a bad choice on their part, but in our case we want to integrate with C/C++ as directly as possible. Rust can integrate with C/C++ SDKs, but it adds another layer which can end up getting in the way, similar to the role node.js plays in Electron/NW.js. The second reason is basically that it means relying on another highly complex third-party component. When and whether to rely on third parties is often a difficult judgement and has various tradeoffs in both directions. However in this case I felt most existing frameworks don't give much thought to games, and anyway we already had something pretty close to what we wanted. So I felt it was time we brought things in-house.

Microsoft WebView2

I've been very impressed with Microsoft WebView2. It's a modern web view control for applications to embed web content. It launched in 2020 with the new Chromium-based Edge browser, and uses the same browser engine. This also makes it a relative newcomer compared to Electron and NW.js (which both appear to have got going around 2013-2014). Its features include:

• It uses a shared browser engine which is installed by default on Windows 10/11
• It's also based on the Chromium browser engine so has excellent compatibility with existing web content run in Electron/NW.js
• Automatic updates, just like browsers
• A comprehensive C++ SDK providing good integration with web content
• Maintained by Microsoft, regularly updated, well-supported, and used by Microsoft themselves in some of their own apps, so it looks dependable in the long-term.

This does a lot of what we want, and it seemed so promising that we actually already built a Windows WebView2 export option in addition to our Windows NW.js export option. An empty Construct project exported to Windows WebView2 is just 530 KB compressed, as it doesn't have to bundle a whole browser engine or node.js - in fact it's just an overhead of 290 KB over a web export (when compressed).

The main downside is: WebView2 is not a framework. It's more just the browser engine component of a framework (and in fact Tauri uses WebView2 as well for that purpose). In our case, we built a small C++ wrapper application that embeds WebView2 and loads the Construct project. It works great, it's very lightweight, only needs a relatively small amount of in-house code, and gives us full control.

The only thing it's missing? A way to integrate C/C++ SDKs. So we decided: let's build our own extension system for WebView2.

An extension SDK

Building extension systems takes a fair amount of work. We kept things simple. There's an SDK to build a small DLL file for added features, which we call a "wrapper extension". There's a minimal message-passing system for communication, based on exchanging small bits of JSON data. It does everything we need and avoids having to set up complicated bindings for direct calls. The technical details of getting data from a Web Worker (where the engine runs by default), through to a C++ app, and then across a DLL boundary, are all pretty complicated. Here are few of the stages a message sent from JavaScript to C++ goes through:

1. First post the message from the Web Worker to the main document
2. The main document can then stringify the JSON data and call chrome.webview.postMessage() to send it to the WebView2 control
3. The wrapper app listens for the WebView2 WebMessageReceived event, and parses the JSON string
4. Based on the received JSON data, the wrapper app decides which extension the message should be sent to
5. The JSON data is packed in to "plain-old-data" for a stable ABI for crossing the DLL boundary, and calls a method in the DLL to send it the data
6. The method in the DLL unpacks the data back in to more useful STL types like std::string, and then finally calls the message handler

Sending a message from C++ back to JavaScript essentially does that whole process in reverse. Despite all that, we came up with a system that to the furthest extent possible hides all of those details to make it as easy to use as possible for integration, including the ability to make async calls from JavaScript which later resolve with data returned from the extension.

As an example of how we made this easy, here's the code to send a message from JavaScript to a C++ extension from our addon SDK:

this.SendWrapperExtensionMessage("show-messagebox", [message, title]);

// C++
void WrapperExtension::HandleWebMessage(const std::string& messageId, const std::vector<ExtensionParameter>& params, double asyncId)
{
	if (messageId == "show-messagebox")
	{
		// Parameters have to be converted to wide strings for Windows APIs
		const std::wstring& message = Utf8ToWide(params[0].GetString());
		const std::wstring& title = Utf8ToWide(params[1].GetString());

		// Call a Windows API directly
		MessageBox(hWndMain, message.c_str(), title.c_str(), MB_OK);
	}
}