If we can push on our work and feel it move then we can explore with abandon. When an experiment takes hours or longer then we must plan our work to save time.
Wiki changed the way one writes for the web by editing text in the same place one would read it. This removed the need for syntactic analysis and with it error messages. If it looks right, keep it.
# Programming
Dan Ingals impressed Steve Jobs by tuning Smalltalk code of a running application. Smalltalk could deploy changes in a fraction of a second.
An html script can be revised, saved, upload and tested in a persistent context in five to ten seconds. This is fast enough that one does not loose their chain of thought.
A deno server can be revised, pushed and deployed internationally in five to ten seconds also. Neither approach requires any build change to transform what has been written.
# Client
We run html pages with script tags in the browser. A script might import exotic features but we expect scripts to follow an easily imitated structure.
Buttons — We write scripts that do one or a few things based on user initiative. We favor the default rendering of buttons because it is easy to write and easy to make consistent.
<p> <button onclick=work(event)>do work</button> <button onclick=save(event)>save work</button> </b>
Results — We show partial results quickly so that it is clear what been started and when it completes. We update results with direct access to the DOM.
<div id=results></div>
Script — We may complete some initialization and report results immediately when that can be completed in a fraction of a second and confirm that information need to perform actions has been located.
let sitemap = await fetch(`/system/sitemap.json`)... window.result.innerHTML = `${sitemap.length) pages`
Further operations will be written as button click handlers. These should complete in a few seconds or provide some progress indication by adding dots to the result.
window.work = function(event) { let html = await sitemap.map(info => ...) window.result.innerHTML = html.join("\n") }
# Deploy
We write html scripts as local files which we will eventually deploy as assets in a model site that can be employed easily as remote pages in a large number of sites.
Assets — We upload html scripts to well known asset folders. For example, a sample workflow site might have a page called Scripts with an Assets folder similarly named.
pages/scripts
Frame — We invoke html scripts within the Frame plugin that provides a safe sandbox and access to some lineup resources. The Assets plugin shows links to the files it holds. We copy that link to the Frame markup.
html://wiki.site.org/assets/pages/scripts/doit.html
Localhost — We can sometimes usefully debug a script as a local file or a local file served as localhost in advance of deploying a new or updated script.
# Server
An html script can perform many useful functions using only service calls available in wiki servers. Deno provides similarly simple mechanisms for handling client requests.
addEventListener("fetch", async (event) => { let {pathname} = new URL(event.request.url) ... }
A server has the obligation to respond with a well formed response with specific headers and content type.
const head = mime => ({ "content-type": `${mime}; charset=UTF-8`, "access-control-allow-origin": "*"}) const resp = (status, headers, body) => event.respondWith( new Response(body, {status, headers}))
We can start an interaction by providing a client script in the form we have already described.
if (pathname == `/`) { resp(200, head('text/html'), await Deno.readFile("./client.html")) }
# Deploy
We favor deploying server javascript using the Deno edge hosting service Deploy now in beta. Host client.html and server.js in a GitHub repo and bind that to a Deploy project. Redeploying on merge takes a second.
The Deploy infrastructure can be simulated on localhost where debugging faster and even more automatic.
deployctl run --watch server.js
In either case Deploy will provide a URL to be used in a Frame plugin as above.