On the geometric level, we see certain physical elements repeated endlessly, combined in an almost endless variety of combinations... It is puzzling to realize that the elements, which seem like elementary building blocks, keep varying, and are different every time that they occur .... If the elements are different every time that they occur, evidently then, it cannot be the elements themselves which are repeating in a building or town; these so-called elements cannot be the ultimate "atomic" constituents of space.

― Christopher Alexander is the current active culmination of many components. It's heritage goes all the way back to a single self-editing Gist on GitHub. The layout of the present incarnation is as follows:

Core Libraries

These libraries are un-opinionated single purpose tools. Some are currently so deeply embedded that they are somewhat difficult to modify or swap out. Others are less central but deeply depended upon at the framework or system architecture level. In either case they are generally single file implementations so they can be reused in other projects or in future incarnations of this. They are single file, zero dependency, and self propagating where appropriate.

These aim for a very high power to weight ratio. Each ideally is ~5kb and can provied a core function of a variety of more opinionated systems.


This is our module system. It is self-replicating and forms the foundation of how modules are packaged, loaded, required, and published. Each package can include a pixie.cson file listing dependencies at URLs. Because it wraps the loading process it is somewhat invisible to the editing process. (NB: more can be done to expose it for easier modification, like exposing require.pkg to give you the json for the require package itself)

  "!system": ""
  "hera": ""

These dependencies are resolved at build time in the editor and used to create the dependencies of the published package by inserting the same name with the received JSON.

Load from distri/require (though it is also present in every running app)



Our PEG parser language. Jadelet2 is constructed using Hera. Longer term it will also power a cson parser, a stylus replacement, and possibly a CoffeeScript replacement. Perhaps even other DSLs and special purposes languages.

Editable in Prometheus at My Briefcase/public/


Handles cross frame communication with a promise based API. Currently editable from because the nested and sandboxed iframes in Prometheus runnig inside ZineOS crash during the tests ;_;

Load from distri/postmaster


The framework collects tools in an opinionated way to accomplish the specific goal of creating ZineOS and ZineOS applications.

System Client

System client is the ZineOS runtime. The goal is to provide a consistent platform for creating web based applications that can run inside ZineOS or standalone and can communicate with each other. It comes with a UI library, extensions / polyfills to the native browser APIs, and aggregates and exposes our Core libraries in an ergonomic and purpose directed way.

The primary reason these are all together under the same project is that they all share common dependencies: Observable, Jadelet, convenience and utility functions. Node.js taught me that deeply transitive dependencies are an unending nightmare of pain and regret. A framework that provides taste and decency is a breath of fresh air. Having them all in the same project allows for evolving them and testing them together as a unified framework and direction.

AWS integration and cloud services are also provided. Currently My Briefcase is the only fleshed out service, but I have visions for a complete system including webhooks, timers, events, lambdas, apis, websockets, dbs... oh god do I have visions...

system-client is editable in Prometheus from


Applications are published as .json files to URLs like They are crated from the Prometheus editor, though any conforming json can be run as an application. The structure is:

    content: <source>
    content: <js source>
  <name>: <recursive structure>

Source files live in source. They are compiled during editing into distribution, stripping suffixes. A common js require is provided. Files should export using module.exports

The reason for this package syntax is so that applications can be easily edited (need access to source to edit), and run with reflection (need a structure in the runtime language to introspect). This is a simple enough way to sovle both those requirements.


ZineOS is a ZineOS app. It provides the desktop experience and a curated collection of other tools and applications. It builds on top of the system-client framework as do most of its applications. It can also run general applications as iframes, and if they communicate using the same protocols they can integrate just as nicely. This allows for experimentation in app combinations and the protocols themselves.

ZineOS is editable Prometheus from

The Editor: Prometheus

The editor that makes the apps! It can edit all the components, from Core Libraries on up. It can even edit itself, duh! Maybe you're starting to see a common theme...

Prometheus is the 3rd generation of the editor. Its progenitor is, its granprogenitor is the self hosting gist editor.


Markdown to HTML implemented as a handful of scripts usable from ZineOS. Holds essays and documentation about my descent into madness, descriptions about the software, clues for myself in the future, helpful tips, and design documentation.

Editable from the ZineOS desktop at My Briefcase/public/ Put pages in /pages then run


My most popular tool. Create and share tunes in the style of Mario Paint!

Pixel Editor

The pixel editor has the longest history, this is probably the 7th rewrite. One day I should make a history documenting it.


Code editor in

Chlorian Midi Player

FXZ Editor

3rd Party Components

3rd party components are hosted on the CDN at One day they may all be replaced by first party components, but until then here they are.