Orca

During the 2022 Handmade Network Wheel Reinvention Jam, I toyed with the idea of an execution environment to safely distribute and run WebAssembly applications downloaded from the web. The prototype, which I called Orca, activated when custom URLs where used in a browser’s address bar, and would then download a WebAssembly app and execute it, feeding it keyboard and mouse inputs and providing it a GLES context to draw into. You can see a recap of my jam project here.

With the Handmade Network’s admin team, we’re now booting up the Orca initiative, which aims to further explore that idea and produce a unified platform and set of APIs to develop, distribute and run sandboxed graphical applications on a variety of operating systems.

I give below a justification for the why of the initiative, and then present a tentative roadmap.

Promises and shortcomings of web apps

A thought experiment

Let’s say you want to develop an application and distribute it to an audience split between several operating systems. You have many options regarding the development part, but in short:

• You could write your own platform layer, and implement it for your audience’s various operating systems.
• You could use a ready-made framework or engine to produce a native app for each OS.
• You could write a web application that will run in a browser (or in a browser disguised as a native application).

Now, let’s switch to the other side and imagine being a user that wants to get an application to do some work (or have some fun). Let’s also say you’re a non-expert, and/or value your time, so you won’t build it from source or wait until a package manager has finished updating your whole system. You could:

• Go to a developer’s website, choose the right version of the software (perhaps with some help from the website, but that’s not a given), download the program, potentially run an installer, click a bunch of options, wait a while, then run the program. You also have to trust the developer not to be malicious, the app not to have vulnerabilities, and the distribution channel not to be compromised.
• Get your apps from a store, which might streamline the installation process. It may allow you to be less concerned about the developer, but only if you trust the store to do a good job curating the apps they sell.
• Visit a website using your (pre-installed) browser, and start using the app immediately. No (apparent) downloads, no installation, no file management. You also have some confidence that the app won’t harm your device, thanks to sandboxing.

By now the point should be pretty obvious: the web promises huge benefits to both developers and users. These benefits were also obvious very early, all the more so as operating systems failed to provide them. It’s no wonder that web technologies have been widely adopted to build and distribute applications.

A reality check

A particularly crooked politician once said “Promises only bind those who believe in them.” It’s always a good idea to check if promises are held.

In the case of web technologies, we must acknowledge that in a way they are. You can write apps targeting a single platform and distribute them through a web page. You can use the same web app from different operating systems, most of the time. You can trust the browser to protect you from malicious or faulty apps, to a certain extent.

But on the other hand, the day-to-day user experience with web apps is poor. They often have janky UIs, are slower than they should be, or only work in a specific browser (or even a specific version of that browser). And there are other drawbacks: web apps are unavailable when offline, and are subject to change under your feet or disappear at the developer’s whim.

As for the developers, they have to deal with byzantine frameworks and APIs, browser-specific quirks, and a particularly inadequate document model that’s built into the core of the web technology.

The current web ecosystem is layered the wrong way.

The web was never meant to distribute and run applications in the first place. Web apps are an afterthought to its design.

The web originally started as a global hyperlinked knowledge base of documents. It then rapidly grew more dynamic features from there, adding flexible layouts, animations, push protocols, scripting features, etc. In the process it morphed towards an application distribution and execution platform, but the base layers were never reassessed in light of new goals.

The layers of the web stack are largely historical, like sediment rather than the foundation of a building. This comes at the cost of accidental complexity, fragility, and slowness. We’re building applications on top of a tech stack on top of a document-oriented platform that was never meant to do what we’re making it do.

Flipping the stack

What if instead we flipped things upside down? What if we had operating systems that could seamlessly download applications using a cross-platform format, and run them in a truly sandboxed way?

What if they had a simple, understandable capability model that let users choose what apps do to their machines, which files they can access, which servers they can connect to, and which input feeds they can capture?

What if this system could allow applications to embed other applications, interlinking their contents, indexing and sharing data across applications?

I personally think this would massively simplify web technology, enabling developers to write better apps, and giving users more freedom and agency over their experience with computing.

Note that on top of such a system, the legitimately great idea of a world-wide web of documents can still exist! It would just consist of specific document formats displayed by different viewer apps that plug into the system like any other app. I would even argue this part of the web would be better, because it would be much simpler to write custom viewer apps. Each viewer wouldn’t have to carry the weight and baggage of modern browsers, and could use the system’s embedding and cross-linking capabilities to leverage the capabilities of other simple viewers. For instance, a simple document viewer, upon encountering tabular data, could leverage the features of an external spreadsheet editor on demand to sort, filter, and graph that data inline.

Introducing Orca

Enough for the grand vision (for now)! While it’s great to have one, the devil is in the details, and the details are only uncovered through working at the problem. We have to start taking pragmatic steps to probe this desirable but uncertain future.

Here is a tentative roadmap in three stages. The further we go, the more hand-wavy it gets, but it should give us a direction.

Stage 1: The Runtime

If we hope to get anyone on board, Orca has to provide value from the very first step, and ramp up that value as it grows. This has two important implications:

• Operating systems are not the solution. As much as I’d like cross-platform distribution, sandboxing, and interlinking to be provided natively by an OS, it’s not the right place to attack the problem today. People won’t leave their OS and all their tools to jump on board right away, and we can’t wait until we have a full-featured OS with rich tooling and software before people start adopting it.
• Existing languages and compilers must be able to target Orca, so that people can leverage their existing tools and existing code. The specific executable format matters less in comparison.

These two points naturally define the “starting shape” of Orca: a user-level runtime environment on top of existing operating systems, running WebAssembly-based applications.

As a first approximation, you can think of the Orca runtime as a “Handmade Electron”. That’s where we expect to deliver practical value in the short term. It allows developers to write code once, targeting a unique platform API, producing a self-contained app for multiple operating systems.

Along with the runtime, we’ll develop tools to enhance the development workflow of Orca apps. In particular, I’d like to have debugging, analysis, and visualization of WebAssembly code built into the runtime.

Stage 2: The Launcher

There are a few problems with the standalone app model:

• Since each application carries its own runtime, you end up with multiple copies of the runtime on your system. (Try counting the number of copies of Chromium you currently have on your computer!)
• If a version of the runtime must be patched, you have to upgrade each copy using app-specific upgrade paths.
• Although the application-specific code is sandboxed, you have to trust that the runtime itself is not malicious (and you have to renew that trust each time you download an app).

Given these problems, a natural second stage of the initiative is an Orca launcher, which allows multiple Orca applications to share the same runtime. This alleviates the wasteful duplication problem, and gives you greater confidence that Orca apps are actually sandboxed, provided that you trust the launcher provider to keep the runtime secure.

The launcher could also streamline the way you manage your applications:

• Visiting a custom Orca URL would automatically download and open a transient Orca application that is cleaned up when closed.
• You could have application bookmarks for small apps that you frequently visit.
• You could choose to cache an application in your local application library, making it accessible offline.

These features were actually part of my 2022 jam prototype, and I still think they’re an important part of the value proposition of Orca. However, I think it’s important to first focus on developing good platform APIs and improving the app development workflow, i.e. stage 1.

Stage 3: The Platform

That part is very much speculative, but it is, for me, where the interesting problems and big gains come up.

Once we have apps sharing a common format, using common APIs, running on a common runtime, and managed through a common launcher, it’s quite natural to think about “platform-wide” services. Think about common OS-like features that apps can use to interact and compose with each other. A trivial example in a standard OS is the clipboard, but controlling the runtime means we can do much more, on all operating systems the runtime supports.

For instance, I’d want the standard UI API of the platform to generate a description of an app’s UI as a side product of running the UI. This is where we can reintroduce features such as indexing, interlinking, and accessibility - but this time at the right layer, on top of an execution model. Additionally, this would allow indexing not only contents, but also UI elements.

Another important feature would be the ability to embed part of an app into another app, allowing you to compose simple “viewer” components to display and manipulate interlinked, mixed-media contents.

UI indexing and embedding enables many other interesting scenarios:

• The platform could allow searching and slicing through the UIs of multiple apps. For instance, users could search a given command across all open applications, or group often-used UI widgets into custom command palettes.
• A platform-wide documentation system could easily link to an application’s relevant panels, or display that application’s menus and settings inline.
• A scripting/automation system could control applications through their normal GUI, without requiring them to expose separate scripting endpoints.
• The platform could allow users to compose simple pipelines out of pre-existing components, to automate frequent workflows.
• As mentioned above, interactive multimedia documents could be displayed and manipulated through the composition of multiple on-demand “media viewers”, allowing greater flexibility in the authoring and distribution of knowledge and ideas.

A word on community, and a call to discussion

I conveniently didn’t give a timeline for the above roadmap. That’s partly because it depends a lot on problems and realizations that can only come along the way. But ultimately it will also depend on whether people get on board, and how the project grows.

At the moment, I’m working solo, and I’m progressively being joined by the Handmade Network’s admin team for design discussions and implementation help. We hope to make the codebase public soon and start putting the runtime in front of early testers. Ideally we would like to give the participants of forthcoming community jams the option to use Orca as their target platform.

Moving forward, we have a subtle balance to find: on one hand, we want to involve the incredibly diverse pool of talents and skills we have in the community. On the other hand, we know the perils of having too many cooks in the kitchen.

Better platforms for application development and distribution will emerge from multiple initiatives like Orca, each with a clear vision. We know that Orca might not be for everyone, but we think it wouldn’t help to put our efforts towards an amorphous compromise, or to be swamped by bikeshedding.

So we’ll probably keep the core design and development team small and focused, and as the project grows, we’ll pull in contributors with specific expertise and a strong interest. As for what to expect if you want to get involved in the project, the way the Zig community functions seems to work pretty well, and I think we’ll end up not too far from that model.

That being said, we want to extend an invitation to anyone in the community who feels interested in the initiative to come and discuss it with us on the Handmade Network Discord. You can also subscribe to our newsletter to get updates on the project. I can’t wait to share more about Orca!