“A codestrate is essentially a webpage whose content, presentation, and behavior can be (collaboratively) edited from within the page and whose edits are inherently made persistent.”
Inspired by Literate programming, a codestrate’s code, style, and data are stored in the document itself, which is implemented with Webstrates. System code creates CodeMirror editors for those elements at runtime and mirrors changes to the invisible DOM <style> (etc) elements. Unlike a Computational notebook, the interface of the “parent” environment can be reprogrammed, and it can be used to develop stateful, stand-alone applications.
The model reminds me of a more general framing of Tiddlywiki: you make a new Tiddlywiki by copying an old one; data is stored in the DOM; reprogrammability is possible via self-modification; etc.
The code for the codestrate environment is itself part of the user-visible document visualized in the codestrate editor, though it is hidden by default. This enables fluid reprogrammability.
==How to characterize the difference from Computational notebook?==
Some compelling examples of malleability in action:
The fluid way with which we can move between using and developing a codestrate results in the continuous development of functionality in response to specific tasks at hand. If the same functionality in one codestrate is needed at a later point in time for different tasks, those sections can easily be transferred between codestrates. For example, one user built a presentation tool for a research talk. That tool was then copied by someone else and extended with an in-slide code editor to teach a programming course. A static PDF viewer was extended to a mobile note-taking tool that allowed hand-written annotations from an iPad, then extended again into a review writing tool with a simple text processor next to it. Through using and developing codestrates this way, we have access to an organically growing repository of functionality instead of a limited collection defined during the traditional development phase.
The authors mention that one can use a “signalling API” to synchronize state in a multiplayer game. I don’t get it: why not use the DOM?
Q. How might you make a grocery list app as a codestrate?
A. Express the list’s interface in a body paragraph (styled by a style paragraph); implement the “add grocery” interaction with a code paragraph; full-screen the body.
Q. Four types of “paragraphs”?
A. body, code, style, data
Q. If you modify the codestrate environment itself, how can other codestrates use your changes?
A. You can “pull changes” to individual sections (e.g. the system section).
Q. How to add elements to the DOM without persisting or synchronizing them?
A. A new transient element.
Q. How can the output of a code paragraph easily be displayed in a body paragraph?
A. Using a Variable API.
Q. Contrast with Computational notebook
A. e.g. can modify the environment UI, can use to deploy stateful standalone apps