referenceArchiveUUID: "3f7f4490-f797-4d72-952f-da74ab8bc6a2"
fullTitle: "Codestrates: Literate Computing with Webstrates"
authors: ["Roman Rädle","Midas Nouwens","Kristian Antonsen","James R. Eagan","Clemens N. Klokmose"]
“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 ☉