SPINE

Spine is a prototype of a software architecture that enables direct manipulation while remaining live and editable. It’s a declarative push-based reactive system, enabling incremental computation.

It’s incomplete, buggy and poorly written.

(Presentation for LIVE 2025 with additional examples)

Examples

Spine supports multi-touch.

Note: Not not all examples are well-behaved, and might start breaking when you edit. You might be able to refresh the browser to continue.

Examples

• Broccoli (embedded above, but with assymetry option)
• Dot Spiral (embedded above)
• Binary Tree with state (Recursion)
• Worm Game (Play using arrow keys)
• Sine Dots
• Summed Bars
• Source Code Plasma
• Average Position

Examples from LIVE 2025 presentation

• Clamp
• Round
• Rewire on control key
• Mix and smooth on control key
• Line using mix
• Mix Reversal Plot (Graph plot in Mad Tea Lab)
• Rectangle Gizmo
• Integrate - Move point with arrow keys
• Minimal Game
• Slider
• Color picker

Other examples:

• three.js wrapper (uses three js version from 2015)
• Binary Tree, position offsets in array (Recursion)
• Movement Interaction - using multi-touch, a feedback loop can be created
• Pin to re-balance movement
• For is just a component
• Line using mix inluding outside 0 - 1
• Bidirectional smooth / filter
• Chained smoothing

What and Why

(Simplified glossary of the fancy terms)

• Declarative - so we don’t have to manage objects
• Reactive - so we don’t have to manage updates
• Bidirectional - so we can define interactive behaviour in a minimal way
• Direct Manipulation - so interaction can automatically change the program
• Incremental Computation - so that previously computed values are automatically cached and re-used
• Incremental Code Update - so that programs can remain live editable as they grow (in Spine, each line is a compilation unit)

Parser

The parser is inspired by JSON and designed to have a generic and loose syntax. It leaves validation / interpretation up to the next abstraction level. Like in CoffeeScript, argument parenthesis can be omitted. Like Lua, there is a single a container structure, supporting order and optional keys. Brackets () [] {}, all have the same behaviour, except () for items <= 1, which are special to support infix notation etc.

Syntax Experiments

Spine syntax is mainly inspired by lua and js, but there are some more experimental stuff as well. For instance, a map function which is implemented in way that it takes its arguments as code, this way you don’t have to wrap the expression in a function:

map x = [1,2,3], x * x  // square a list

map is also available as an operator (then always using x)

[1,2,3] -> x * x

If the right side is a single token, x is automatically injected as an argument, so

[1,2,3] -> sin -> x * 10 -> floor

means:

[1,2,3] -> sin(x) -> x * 10 -> floor(x)

It also works on single values:

0.7 -> sin -> x * 10 -> floor  

Note that most operators work recursively on arrays

• [2, 10] + 10 = [12, 20]
• [2, 10] * [7, 8] = [14, 80]
• { a:2, b:10 } * { a:[2, 3], b:10 } = { a:[4, 6], b:100 }

Comparison: Lua / js vs Spine

* js don't have a combined object/array

Source Code

Source needs serious overhaul or a complete rewrite.

These links are to old revisions:

• Operators
• Components - inside createSpineApp()
• if component
• point component
• Reactive Value - create, get, set
• Reactive Array - raCreate, raInsert etc
• instantiateRec - traverse AST to instantiate
• parseToAST - precedence table
• unparseExpression - reverse parsing
• Demo “main”

Spine was written in a weird transpiler language, however it outputs somewhat readable js. So, if you prefer, you could read the transpiled code, search for '*' or spineComp_if or similar. You can run the transpiler environment live (development mode)

I’ve started rewriting parts of the code in C# for my demoscene projects, however I did not really do much bidirectional stuff yet.

Options

• You can use debug=1 in the url query string to see some internals (Block tree and ASTs)
• When running in development mode, use log=spine to turn on verbose logging
• incremental=0 turns off incremental code updates (all objects will be recreated when you change the code)
• Using embed=1 makes it so that clicking the icon opens a new window to edit to code.
• With hidecode=1, code will not be accessible
• fontsize=8 set fontsize of the code

Missing / Unsolved

• No else / else if support
• No key-value pair iteration
• Empty lines break namespace find (each line needs actual expression)
• Lines with uneven indentation are silently ignored
• Long lines cannot be re-formatted using linefeeds (by design!), solution: a component sublinesToArray(), that syncs code sublines to a reactive array (converting any assignment operators to keys). Ideally with some syntax sugar like this
  
• State-component only support numbers, and there is no implementation for “managed app-state”.
• Random drawing order of graphics
• Drawing order don’t match input hit/picking priority
• Only circle and rect support interaction (point/box are aliases)
• Components cannot detect “missing arguments”, as they are the same as async delays (which are expected)
• Abstraction using def() does not support default values
• Many functions (mix, clamp etc) do not work with reactive arrays
• Making some functions bidirectional by default (round, clamp etc) can lead to bugs/confusion
• Recursion vs return vs local variables issue
• Parser: additional end-bracket should not parse
• Parser: multiple statements using comma should not parse (multiple statements are supported using semicolon)
• Parser: ’ quotes normalize to " when reverse parsing, maybe not that important?
• Smooth and integrate always process every frame, they should ideally stop per-frame-processing when in stable state (for integrate, when input is 0, for smooth, when input is the same as output)
• Probably many severe namespace bugs (especially in combination with incremental build)
• Code contains many unfinished features and random notes