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.
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:
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:
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 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 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.
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.
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.
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:
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.
There are a few problems with the standalone app model:
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:
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.
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:
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!
Sign up to get updates on the Orca project.
You have successfully joined our subscriber list.
Our system has encountered an error. Please try again later or contact us.