Jason Frame: Livecoding in JS
Jason Frame (@jaz303) was talking about Livecoding in JavaScript at Scotland.js, these are my notes from his talk.
What do we mean by livecoding? Injecting code into a program whilst it's still running and we should see no change in the program (other than what we intended). For example a music generation system.
Why livecode?
Rather than planning out a big system we can start with what feels right and then manipulate them until we get to where we need to be. Start with primitives and get on with using them. And it's fun turning a car into a tortoise.
Why JS
- Flexible - prototypal not class based.
- Ecosystem - browser + node.js = node-webkit
- Single threaded - don't have to worry about what something else is doing.
- Event loop - natural synchronisation point.
Domain-specific Livecoding
- Generalised tools can be complex - optimised for nobody
- May make performance trade offs - browsers can't always keep up
- Evolve tools with application - what can we keep and what can we lose?
Implementation strategies
eval() is awesome. Eval is the core tool for livecoding.
- private state - don't pollute the global name space.
- variable injection - provide objects to user code. Generate method signature from defined objects.
- "globals" preservation - preserve state variables between code reloads, don't want to reset the global state when we hot reload code.
- internal
eval()- provide external access to the closure with aneval()that runs in the closure scope but is accessible from outside. - blueprints
- snapshots - save and restore entire application state. user code is responsible for it's state here.
- Clocksources - provide a wrapper round the time function so we can control this for snapshots.
Escaping the walled garden
Plan 9 operating system - everything is a file, really. Fuse file system is the equivalent, it allows us to mount the program state as a file system and intercept the file system calls. We can now use standard Unix tools to manipulate the game state.