Wasm Builders

Steve Lu
Steve Lu

Posted on • Updated on

A General-Purpose Object-Distribution Framework for WebAssembly and Other Web Components

Over the past six decades of evolution of modern computing platforms, we have witnessed the development of several high-level languages and distributed component models (e.g., COM, XPCOM, Java Beans, etc.). In late 90s, the web happened. And it comes with its own language, Javascript, and a transportation protocol, HTTP. In the new millennium, Javascript gained its own mechanisms for object-oriented design, but it still lacks of a object distribution model, partly because the minimal units for web distribution are text-based files such as file.js, file.css, and file.html. It is very difficult to disseminate independent, fine-grained objects out of these files, let alone being reusable.

Modelling is the Key

Software objects are conventionally defined at languages level (e.g., C++ classes, Javascript prototypes). This immediately poses a problem for modelling web objects. Since a web object could potentially comprise of HTML fragments, CSS rules, Javascript functions, XML declarations, audio, video, canvas drawings, WebGL meshes, WebXR device controls, and WebAssembly modules, etc. Language alone could not possibly capture all these diverse data types while still maintain their portability as one logical unit.

What we need is an universal container at application level, and a suitable candidate can be found in a specification from the 90s called Unified Modelling Language (UML). UML was originally developed for compiled languages. It is a set of visual and data-agnostic guidelines for modelling objects, including their states, behaviors, and relationships over the lifetime of a distributed application.

Typically, developers use UML to model objects in a visual editor. Some tools can even generate codes from models, which are then compiled and deployed.

By following UML recommendation, over an architecture of plug-and-play micro-service providers, our platform redefines what a web object is, so that it gains flexibility in design and portability over web.

Furthermore, since Javascript is an interpreted language, object models are no longer cemented into executables after compilation. Choosing object composition over inheritance, our platform empowers applications to download and build new hybrid objects on the fly. In the old days, this would require recompilation and redeployment.

Top-Down Object-Oriented Design

Have you ever wonder why application development is so hard. All you want to do is this and that, why do you have to learn all these concepts and jargons from middleware developers before you can even put together a prototype?

Traditionally, softwares are built from bottom-up to fulfill requirements from top-level problem description. Middleware developers design hierarchical, language-level objects and export a set of high-level APIs as end product. These APIs expose a very small part of underlyig Object-Oriented (OO) design. To use them correctly, end users must first learn the concept of these objects and relationships among them which may or may not pertain to the original problem. Also, most likely, end users would not unanimously agree on the overall design. No two minds think alike. Don't expect a band of like-minded developers can solve all the problems with one fixed Object-Oriented design, and in a way preferable by everybody. The most important thing in understanding their API while reading their documents is to discover its limitations by design, either explicit or implicit.

A preferred methodology is to put the power of design in the hand of application developers at the very top of programming totem pole, while still allow them to extend the framework by adding plug-and-play micro-service providers from below (see Figure-1). The line that separates droplets from service providers hides all unnecessary complexity from application development.

Figure-1: Top-Down Object-Oriented Design

The arrows in the figure indicate roughly where major "concepts" are defined and their direction of flow. Notice also that object semantics are now imposed from the top-down by the application developers.

Droplets for all Occasions

Our platform includes an UML-like web client called Condenser. In it, developers build a software object by drag-and-dropping different micro-service providers called molecules into an universal container called droplet. Several droplets make up a formation which is, in fact, an HTML web page.


Droplets and Formations can be published to a central repository and each assigned an unique HTTPS URL. Through these URLs, objects in repository can be imported into Condenser to be used as templates for building different set of objects. For example, this page demonstrates how to import a droplet from repository during edit time. Similarly and more importantly, an end application can import these objects at run time to dynamically supplement an object's behavior.

Each molecule comes with a set of properties. A property editor for configuring service provide can be opened during edit time by double-clicking on the molecule's icon. The following video shows a typical editing session. At run time, the same set of properties can be accessed via scripting.

In practice, molecules are developed by subject experts and once published, any novice can include them in his/her own objects to solve his/her own particular high-level tasks.

Molecule Packs

By now you must be wondering where does WebAssembly come in? Using droplet as a container and a transport vessel, WebAssembly can be embedded directly, or indirectly as a molecule. Video tutorials below demonstrate how each is done.

Packaging C/C++ code into a plug-and-play component

Molecule Pack Development

Discussion (0)