Persistence and Visibility for the JavaScript Prototype Realm

In normal practice, the prototype structure of JavaScript objects is missing from their stored (e.g. JSON) versions. Given the central role of prototypes in JavaScript, this means that one can’t save working components of an application as they are. Instead, application-specific encoding of the components is needed for storage, with associated reconstruction of prototype structure from the encoded components upon retrieval. Minor proviso: in the vanishingly rare case of applications where prototype machinery is not used at all, JSON will suffice. (For those unfamiliar with prototypes, here is an explanation.)

But suppose that there were a general way of retaining prototype structure in saved objects? Then things could be saved and restored without restraint.

This note briefly outlines a project, ongoing now for several years, which has realized the goal of storing JavaScript prototype structure. The technology has been applied in the visual domain of diagrams and the like, backed by SVG as the underlying display method. Drawings or diagrams, and all their elements (arrows and such) go to and fro from persistent storage with prototype structure intact. The repository of visual elements is open for contribution by any JavaScript programmer (the system includes a JSFiddle-like environment for coders as well as a user interface).

In addition, the user interface exposes prototype structure, bringing visibility as well as persistence to the prototype realm.

The project goes by the name “PrototypeJungle”, since at its core lies an extensible repository of prototype structures. See prototypejungle.org. A description of the underlying technology (which is open source) can be found here.

Here are examples of what life with the prototypes is like. Consider the following simple diagram:

Each of the seven rectangular nodes is derived from a common prototype. The same is true of the three multi-arrows. The user can edit either the instances or prototypes. Editing a prototype affects all instances according to the rules of inheritance (in which instances might override prototype properties).

Prototypes can swapped for others in the repository under the condition that they play the same role (two common roles are “vertex” and “edge”). For example, a single swap operation yields the diagram below on the left. Parts of elements can be swapped too. The diagram on the right is the result of swapping out the solid arrowhead prototype for a curved variant:

The prototypes associated with a diagram are carried with it (this is what allows users to edit those prototypes). Those diagram-internal prototypes in turn inherit from standard prototypes in the repository. This situation is pictured below for the very simple case where the “diagram” consists of two circles with a common prototype.

The repository contains “kits” as well as diagram elements like nodes and arrows. A kit provides operations for building particular sorts of diagrams — operations which are invoked by specialized menu items installed in the user interface by the kit (the operations are also accessible via code). For example, the tree-like example above was constructed with the tree kit via four presses of the “add child” button followed by adding text (the starting tree already includes the top three nodes). Kits support building diagrams from data as well.

As with elements, any JavaScript programmer can code their own kits and add them to the repository.