Guide to Mashweb and the Zen Web App Framework

• 1: About This Book
• 2: Preface
• 3: Introduction
• 4: Part 1: The Motivation Behind Zen and Mashweb
• 4.1: The Death of the Cyberflâneur
• 4.2: Old Pie in the Sky
• 4.2.1: Zen Project #1: A Web Site and a New Technology to Help People Scale the Web
• 4.2.2: Zen: First Principles
• 5: Part 2: Goals (and Possible Goals) of Zen
• 6: Part 3: The Key to Zen: A Nano Framework for Sequential Programming
• 7: Part 4: Web Page Structure
• 8: Part 5: User Interactions and the HTML5 APIs
• 9: Part 6: Example Web Apps Built with Zen
• 10: Part 7: Outside Tools To Help Build Zen
• 11: Part 8: Tricks To Augment Zen's Basic Functions
• 12: Part 9: Project Management
• 13: Part 10: Zen Status Report

1 - About This Book

The creation of new social media apps and other web apps should be as simple as writing a post in a blogging app like WordPress or Medium. Why isn’t it? It could soon be. Let a thousand flowers bloom. Let a trillion flowers bloom.

Zen is a web application framework with sequential programming as its core. It is being built with the belief that the creation of web applications would be vastly simplified if the applications were built upon a framework that supports sequential programming. It is being built also with the belief that a few big problems of web page styling can be solved or worked around with just a few simple methods.

The author hopes that someday nontechnical users could build their own web applications, not just web pages and websites, perhaps using “dumbed down” visual program editors. Suggesting that it is necessary to “dumb down” something so that nontechnical users can use it insults all nontechnical people, of course. The author doesn’t really believe programming has to be dumbed down, but just needs to be layered in such a way that people can immediately create useful programs with only a few minutes of learning. Programmers seem to have missed or considered unimportant the reality that there are millions of potential beginner web applications that could be created if the learning curve were not so steep. The web is fertile ground for an amateur programmer to plough.

This Guide is meant to be a complete guide to the Zen web application framework and the Mashweb community concept. The audience for Parts is mainly programmers and web developers, whether wizardly or amateur. Its sections “About,” “Preface,” and “Introduction” should be comprehensible to many non programmers and non web developers who have only a general knowledge of computers and the web.

2 - Preface

This book came into being because over the years I found myself trying to explain the same ideas again and again and I wished I had organized those ideas in a coherent and organized way. Some of my explanations got lost along the way, too. Having a structure to hold them together should help my ideas and writing by providing pigeon holes, reference points, and sign posts by which to mark the development of vague ideas as they become more tangible and useful.

Prior to starting this book, I tried presenting my ideas on tomelam.blogspot.com, tomelam.com, and Mashweb.Club. None of those venues seemed right for a standalone, easily extensible catalogue of my ideas on Zen and Mashweb. I hope and expect that the present Guide will finally coalesce my words about Zen and Mashweb into one manageable, comprehensible unit.

In addition to drawing together the ideas presented on tomelam.blogspot.com, tomelam.com, and Mashweb.Club, this book is meant to connect together all such diverse sources of digital information as exist to help programmers and web developers use, extend, and further develop the framework. Some of it should be comprehensible to many non programmers and non web developers who have only a general knowledge of computers and the web.

The main “diverse sources of digital information” mentioned above that preceded this Guide are:

1. the website Mashweb.Club, built with Ruby on Rails, with an estimated 1,500 registered users, which is meant to be an attractive and gentle introduction to Mashweb and Zen that many people might enjoy,
2. a white paper hosted on Mashweb.Club,
3. a blog site that discusses some of the problems exploiting the web to the fullest,
4. an old, unmaintained personal website,
5. the website web-call.cc, which is basically just a set of statically served demos, to be maintained for the early release of Zen code for testing and public comment,
6. the Mashweb team forum, invisible to all but the Mashweb team members, which documents many of the important development decisions about Zen and web-call.cc, and
7. the web-call.cc wiki, which can be edited by Mashweb team members.

The white paper (#2), the blog site (#3), and the personal website (#4) will be replaced by this Guide and be deprecated. Eventually Alpha Zen and this Guide will be released together and hosted on a completely revamped Mashweb.Club (#1).

Tom Elam, April 2, 2021, updated November 30, 2021

3 - Introduction

1. Part 1 of this Guide explains how and why its author began to experiment with ideas related to the simple, easy creation of web pages and web applications.
2. Part 2 lays out the goals and possible goals for Zen and Mashweb.
3. Part 3 documents the nano framework at the heart of Zen.
4. Part 4 documents the plan, of unproven viability, for the construction of web page structures.
5. Part 5 documents the user interaction code that Zen provides to simplify the programming of web apps. Mainly these are protocols for interacting with the HTML5 APIs such as the HTML Drag and Drop API and the Clipboard API.
6. Part 6 presents some example web apps such as what a semiskilled web developer might create with Alpha Zen.
7. Part 7 presents outside tools to facilitate the design and programming of Zen and Mashweb.Club.
8. Part 8 collects some tricks to turbocharge Zen.
9. Part 9 shows how the development of Zen and Mashweb is organized.
10. Part 10 presents a status report on Zen. This part will change as Zen is developed.

4 - Part 1: The Motivation Behind Zen and Mashweb

Web pages, of course, comprise HTML, CSS, JavaScript, and sometimes other code. The term web application does not have an exact, universally agreed upon definition, but “highly dynamic website” might be a useful way of thinking of a web application as distinct from a static website that has only unreactive web pages. Old-style web applications used just CGI capabilities and had a page-centric progression. When the site visitor submitted input to a web page, the browser jumped to a different web page. Nowadays, however, the loading of a new web page for most interactions is viewed as tedious. Ajax allows a web page to interact with the user and the web without loading a complete new page. A single page web application built using Ajax has the quintessential qualities of what we now view as a web application or web app.

When the author was employed by Wipro Technologies, he had the freedom to explore many technologies and to try to build new, practical programming tools and utilities. Realizing that many types of data can most easily be represented and manipulated by Lisp (or Scheme), and realizing that S-expressions would be the simplest way to represent web page structure, and learning some of the basics of JavaScript events, he hit upon the idea of using a direct manipulation interface to create and edit web pages.

Later the author discovered a version of Scheme called jsScheme that runs in, or on top of, JavaScript. As some programmers familiar with the Scheme programming language’s call/cc form realized, the state of progression through a series of interactions can quickly grow overwhelming, but call/cc makes it possible to simplify the stateless web and allow it to be programmed in a stateful way.

The author had previously used the UCW (UnCommon Web) framework that used Common Lisp to create something like call/cc on the web server. His experience with UCW made him realize that a practical, generally useful web framework would have limited scalability due to the huge amount of memory consumed by the call/cc-like continuations created for concurrent users of a UCW web application. He realized that by spreading the continuation-related memory consumption across all the web browsers using a web app, that is, by storing the continuations in the web app’s pages rather than on the web server, the web app could be scaled much better.

A parallel motivation for building Zen is the author’s frustrations and dissatisfaction with web browsers, websites, and utilities for study in the world’s new library, the web. These frustrations and dissatisfactions are described in the author’s blog site.

See also the Zen Elevator Pitches.

4.1 - The Death of the Cyberflâneur

The article “The Death of the Cyberflâneur” appeared on the New York Times website on Feb. 4, 2012. Here are some selected quotes from it:

“It’s one thing to find an interesting article and choose to share it with friends. It’s quite another to inundate your friends with everything that passes through your browser or your app, hoping that they will pick something interesting along the way.”

[From Robert Scoble] “The new world is you just open up Facebook and everything you care about will be streaming down the screen.”

How to Be a Boulevardier

Another article, “How to be a Boulevardier”, on the topic of cyberflâneur Lawrence Levi’s website, appeared in print in the New York Times on Sept. 9, 2001. Oddly the article does not give the URL of the website, but a little googling suggests the website might be lawrenceleviphoto.com.

4.2 - Old Pie in the Sky

Here are some articles in this section:

• Zen: Project #1: A Web Site and a New Technology to Help People Scale the Web
• Zen: First Principles
• Zen: What Is it Most About?

4.2.1 - Zen Project #1: A Web Site and a New Technology to Help People Scale the Web

In this, the first in a series of articles on Zen, I describe a large and general problem people have as users of the web. Then I describe a set of technologies I am working on, more fully described at Mashweb.Club and my older website, tomelam.com, which I call Zen, that could significantly reduce the problem. On average, each of us consumes three times as much information as we did in 1960 and checks 40 web sites a day, according to a 2010 article on National Public Radio’s web site. New York Times articles tell us that this makes us impatient, forgetful, anxious, shallow, and unfocused. Information is our crack cocaine, and we should have been in rehab long ago. An information fix is even called a hit! (See below.)

Part of the problem is the difficulty in finding what we seek—even when we know it is on the web. When we search for something on the web, we hope that the process will be linear and finite, but we get lost in a strange loop, a tangled hierarchy of searching, scanning, surfing, and subscribing that we try to climb down like a staircase. In our search for digital nirvana, employing bookmarks, tags, annotations, hyperlinks, search, indices, rankings, ratings, and subscriptions, we find ourselves skipping up and down between various levels of metadata and web resources, like the monks trudging endlessly on the paradoxical, looped staircase in Escher’s lithograph “Ascending and Descending,” shown above. On our way we collect scores of bookmarks and piles of paper notes, and get a headache and short temper, too.

Let us try to outline the stages or hierarchies of the most general search:

1. Search for an answer to a question using a general purpose or specialized “search engine,” typically by entering keywords, phrases, and parameters (e.g., date, tags, domain, URL, links-to, similar-to). Items that match the query criteria are called hits. Hits are presented in lists or in hierarchical outlines and are typically ordered by criteria such as relevance or paid placement. Searching is optional if we can replace the list or outline of hits with a list or outline of resources from categories in a web directory. Examples of directories of the whole web were the now-defunct Yahoo! Directory and DMOZ. (See Wikipedia’s entries on Yahoo! Directory and DMOZ and a successor to DMOZ.) Many specialized directories of web resources also exist.
2. Examine brief descriptions, summaries, or snippets of the items in the list or outline, if available.
3. Open the links to the relevant-looking hits—in new windows or tabs if possible. Evaluate these linked-to resources for fitness to our purpose.

This linear procedure can often miss highly specialized information. Sometimes this happens because we weren’t able to choose the best search query at the outset: we didn’t have enough information to choose well. Sometimes we might not even know information is available pertaining to our problem. And sometimes we really need information from the “deep web,” i.e., data available only behind a form-oriented user interface, such as an airline fare search interface or a phone directory search interface. The “deep web” is generally not indexable by web search engines (“spiders” to be more precise). A better alternative to this hit-and-miss search technique is “semantic search”. (When I first wrote this article in 2010, it was sometimes called “idea search,” but the source I referred to then is now gone, not even archived on Archive.org.) The following articles provide a start at learning about semantic search:

1. SearchEngineJournal.com’s article “Semantic Search: What It Is & Why It Matters for SEO Today”.
2. SearchEngineWatch.com’s article “The beginner’s guide to semantic search: Examples and tools”.
3. Wikipedia.org’s article “Semantic search”.
4. OnCrawl.com’s article “What is semantic SEO?".
5. Google’s article Google Knowledge Graph Search API.
6. Stewart, Scott, and Zelevinsky’s article “Idea Navigation: Structured Browsing for Unstructured Text”.
7. Adam Westerski’s book Semantic Technologies in Idea Management Systems: A Model for Interoperability, Linking and Filtering.

We often resort to trial-and-error variations of our search, but this is usually frustrating. A better approach than the trial-and-error, hit-or-miss approach is to refine each level of hierarchy, as described above, by applying the whole search procedure to that level. That is, we seek information resources, meta-resources (e.g., search engines), and methods of search. A method of search can involve subscription to a forum, wiki, mailing list, social bookmarking service (like Delicious, being slowly revived, archived here; and Digg; and Reddit; and Pinboard), or general social media (like Twitter and Facebook) so that we can make new friends and acquaintances (or communicate with old friends) and get help from them. Or it might be to subscribe to pertinent blogs in an attempt to find out which experts are sharing helpful information on our topic. (Try Feedly or read about Google Reader. Also read about Google Blog Search or try Bloglovin, or QuiteRSS, or some of the sites in this moreofit list.) The “helpful information” could be the final solution we are seeking, or it could be a set of new keywords we hadn’t considered or known, or it could be some other forum, wiki, blog, mailing list, chat room, or other resource. The results on topic-specific forums, wikis, blogs, mailing lists, and chat rooms will be pre-filtered by design, avoiding completely irrelevant hits that can swamp the relevant ones in a general-purpose whole-web search engine. There are many other strategies for refining the levels of search hierarchy.

Other problems arise in our research on the web and in remembering what we find: too many web pages and no adequate means of keeping track of them. If we open a window for each web page that looks pertinent to our search, we soon overburden our web browser or our operating system. The browser will crash, or, in the case of Google Chrome, tab panes will crash. Web browsing will slow to a desperate crawl. (These problems with Google Chrome, the most-used web browser, have existed for for a decade or more. Chrome has some of the best support for extensions and developer support, so it is hard to replace.) If we bookmark our web pages, we irretrievably lose time navigating the browser’s bookmark manager and anyway might not be able to find the bookmarks later when we need them.

So what’s the answer, short of a very heavyweight “idea browser” and possibly much better natural language processing—even artificial sentience—that is not within our reach? I propose we make it possible to write the web as easily as desktop text documents can be written, and to implement some of the original ideas about hypertext like transclusion, so one single web page becomes our notebook and scrapbook. The reader might think of Evernote, Google Notebook, or Xanadu, but the kernel of the technology I’m working on focuses on organizing and tuning the user’s view of and interaction with the web and on being universally usable, globally, by anyone with a reasonably up-to-date web browser, without browser plug-ins. On top of the kernel, many web-server-assisted capabilities can be built.

Zen will allow the user to get close to the process of refining his searches, so that he can keep meta-resources, final results, and records of how he got results at his fingertips, under his control, programmed via a simple visual interface. He should be able to program the Internet by dragging and flowing links, text, data in microformats, and media from any web page into a web page he controls and saves to a web server, and via simple programming of his own interface to the web. He should be able to use his links as bookmarks. He should be able to organize the links, text, and media in folders, tab panes, accordion panes, and other web widgets and lazy-load them so that time is not taken when he re-opens his page at a later date. Only the open pages or other widgets that contain the links, text, data, and media should be loaded. (That’s how a lazy-loaded pane works.) Zen will even allow lazy-loaded widgets to be put into other lazy-loaded widgets. Many of the web-server-assisted services mentioned above and below can easily be codified and automated so that they can be included as widgets on a web page.

The user will be able to share these pages over the web with other people very easily, in many ways. The special web server will serve his web page and will use its in-built proxy capabilities to enable the user’s web page to be composed of content from multiple web sites. Such a composition is called a mashup. The JavaScript inside the user’s web page will enable many kinds of mashup to be created even without help from the special web server. These JavaScript-enabled mashups will use certain kinds of mashable content from multiple web sites. Microformats, mentioned above, can assist the mashups to “digest” and pour content from disparate places into the page. For example, much social media, including the present blog, can be accessed via web feeds using an RSS or Atom microformat. This allows the media to be formatted by a news aggregator for human consumption or inserted into a web page.

Various features of Zen will allow development of a web page to proceed smoothly. Someday maybe the web server will enable the user’s web navigation to be recorded automatically. Variations of the user’s web page will be as easily produced as Git branches, because a Git-like “filesystem” on the web server will record the components of the web page analogously to Git commits. The system must be easy to understand without much training.

I am beginning to program Zen to enable this writable web. I plan eventually to create a web site offering registrations for people to create their own portals to the web. These will be real portals: most of the media content in the web pages will be hot-linked, not copied. For web sites that disallow hot-linking, the special web proxy will be used to work around the limitation by imitating web browsers that such web sites expect to deal with. I am hoping that many people will be interested in the technology, and I am seeking collaborations from companies, investors, technology marketing experts, and programmers.

4.2.2 - Zen: First Principles

Zen has ambitious goals. The key to its success will lie in its remaining true to its unique set of first principles:

1. Zen will be global, i.e. it exists on the Web.

2. Zen will be a zero-install program, i.e. it provides its basic features without browser plug-ins or extensions.

3. Zen will provide graphical user interfaces for adding graphical widgets and HTML elements to a Zen web page. Of course, if too many graphical widget frameworks—or the wrong combination of frameworks—are used in a single web page, trouble ensues. Zen will not in general impose any limitations upon the way the widgets and frameworks can be combined, so there should be a very safe and easy-to-use version of Zen for general use by all users.

4. (This principle is the most ambitious, and might never be realized, but please read to the end of its description.) Zen will “engulf the Web”: it will provide a user-programmable widget that will embed a “web browser” in a Zen web page. Again, even non-technical users will be able to “program” this web browser to do such things as make any web page dissectible, editable, rearrangeable, and mash-able. It will be possible to embed multiple copies of the “browser widget” in a web page. The user will be able to use Zen to copy or move widgets and components from the embedded web page into the rest of the Zen web page. This principle of “engulfing the Web” is very difficult to remain true to because it implies that web pages will be analyzed by a special web server with proxy capabilities. The special web server will also allow any page to be hot-linked. [March 15, 2012: As of now, clicking on the “any page to be hot-linked” link only leads to the top of the blog post. Please skip down to the last paragraph of the post. Something about Blogger.com seems to have prevented a link target inside a post to be accessed.] The special web server will also emulate referral links, thereby allowing a web document that can only be accessed through a referral link (not directly via URL) to be accessed from any Zen-enabled web page. Although it would be difficult to create an application true to this principle (the author came close to cloning web pages, but the code was very slow), a web browser extension like iFrame Allow can allow a similar sort of encapsulation. Such extensions should be used very carefully because they can lead to bleeding of user data from one website to another.

5. Zen provides many functions like filter and sort that even non-technical users can apply to data sources just by dragging widgets around in the web page. It will be possible to chain many of the functions together to provide more possibilities for data manipulation.

6. A user will be able to capture a sequence of interactions with their Zen web page such as moving the mouse pointer over a particular kind of widget (the technicalities of what “kind” means here are not very important in this discussion), clicking on a widget or web page component, typing a single character on the keyboard, entering a string of characters in a box, etc. The range of interaction events that can be captured is from the lowest level interaction with a web page (characters and mouse interactions including the clicking upon submit buttons) through any kind of widget interaction. The user can generalize the captured sequence (“parameterize” it) so that it can be applied to a class of situations. He can store it and attach it to a menu or button so that it can be evoked by choosing the menu item or clicking the button. Thereafter when the user of the page containing the parameterized sequence interacts with the page his interactions with the page are circumscribed: his out-of-sequence input is optionally treated as an error and he can be gently guided to follow the sequence. The capabilities of this Zen sequence capture are somewhat elaborated from the basics described here.

7. A user will be able to create persistent copies of his Zen web pages. These copies will be saved on the Zen web server.

8. Zen will facilitate a user creating web pages and web applications that do not include the Zen library. After Zen removes itself from these pages and applications, they will only depend upon HTML, one or more already-well-accepted JavaScript libraries, and a minimum of JavaScript “glue.” In another way of speaking, Zen will export such pages and applications. Some part of the Zen library will be required to enable all features of captured sequences, however.

9. Zen can be augmented with features that break its first principles, but the result will not be Zen.

10. As an exception to First Principle #1, Zen can be injected into any web page, via web browser add-ons or extensions, to allow the page to be redesigned and mashed up with other content and to gain Zen features. However, only content managed by cooperative JavaScript libraries will be fully compatible with Zen. A cooperative library must facilitate the tracking of every widget and every “DOM element” that the library adds to or subtracts from the web page. (DOM elements are the “atoms” or structural components of a web page. Tables, divisions of a page, paragraphs, lists, and list items, among other things, are represented by DOM elements.) Furthermore, a cooperative library must facilitate the tracking of actions that it can perform in response to the user’s interaction with the web page or in response to data received from the web server. (Such prepared actions are called “event handlers.” They respond to interaction such as mouse clicking and key pressing.) The word facilitate is a bit ambiguous: it can mean “make it possible” or “make it easy.” So far as Zen is concerned, a cooperative library should only have to make possible the things just mentioned, but in its first iterations, Zen might only be fully compatible with libraries that make those things easy.

I might add more first principles to this list later.

I am still seeking collaborations from companies, investors, technology marketing experts, and programmers.

5 - Part 2: Goals (and Possible Goals) of Zen

Motivations and goals are not the same thing. When will Zen be complete? Or when will a version of it really exist? The answer is: when its goals have been met.

In reality, though, Zen has a graded set of possible goals, some imminently achievable and some just remotely believable. Part 2 will break this down. See The Plan for Alpha Zen.

6 - Part 3: The Key to Zen: A Nano Framework for Sequential Programming

Update on June 5, 2021: I have decided to focus on creating the Zen nano framework on top of Gambit Scheme in JavaScript and to reexamine whether JavaScript events might be better handled one per execution thread. Therefore, what is written below in this page might become obsolete.

Virtually every part of Zen involves intricately designed user interaction. This can be managed only if the asynchronous, stateless environment of JavaScript in the web page can be tamed and brought under the control of a sequential process. It is painful to say it, but it sometimes appears that most of today’s web developers believe the most natural way to program user interactions is with pure event driven code. Even seasoned programmers appear to lose sight of the fact that an application that doesn’t progress logically through a series of goals is just a random process. Turning complex user interactions into sequential processes by using call/cc is Zen’s key to success.

The page Sequentially Programmed Web App Demo on Mashweb.Club goes into depth on the topics of web continuations and the sequential programming for web apps. The topics there must be understood by a programmer who wants to create web apps using Zen. The page Demo #2: Introduction to Zen sequential web app programming presents the same demo and one more, a calculator web app, whose body is just 18 lines. The brevity of such an app demonstrates the simplicity and straightforwardness of Zen web apps.

The way Zen uses call/cc is reminiscent of how the POSIX system calls select(2) and poll(2) work. Here is a Biwascheme code block using Zen’s with-handlers macro:

(with-handlers ((click-handler "#div1")
                (click-handler "#div2")
                (keydown-handler "#button1")
                (keydown-handler "#button2")
                (timeout-handler test-timeout 10000))
  (display (get-input))
  (display (get-input))
  (display (get-input))
  (display (get-input))
  (display (get-input)))

with-handlers defines a code block wherein JavaScript event handlers are set up. When execution exits the code block, the event handlers are automatically torn down. Each call to get-input retrieves all the data returned by one of the event handlers, in the order in which the events occur. The plan for Zen is to make synthetic JavaScript events interwork with native JavaScript events to simplify control flow in complex user interactions. This way, multiple events of a type such as keydown could be bundled to trigger an event and be handled with the same priority as events such as the pressing of a button. For more details about with-handlers, see its implementation.

Alexander Sukhoverkhov wrote the core of the nano framework (the macro with-handlers and the pieces of code that make it work. He told me he used a paper to implement shift and reset in jsScheme: https://www.deinprogramm.de/sperber/papers/shift-reset-direct.pdf

7 - Part 4: Web Page Structure

8 - Part 5: User Interactions and the HTML5 APIs

9 - Part 6: Example Web Apps Built with Zen

10 - Part 7: Outside Tools To Help Build Zen

11 - Part 8: Tricks To Augment Zen's Basic Functions

The web server that serves Zen web pages

The web server that serves Zen web pages could do such things as spawn a headless web browser with the Selenium web driver embedded in it. This web driver could be controlled by the web server to do such things as copy a web page and rebase URLs in the web page, so that relative paths are not broken.

A web browser extension that allows web page embedding

The <iframe> HTML tag allows a web page to be embedded in another web page, but due to the clickjacking problem, most web servers send X-Frame-Options HTTP response headers with the web pages they serve to prevent the embedding of those web pages in other web pages. Google Chrome (and probably other web browsers) has an extension to ignore these response headers, thus allowing any web page to be embedded. This extension should be used cautiously to avoid clickjacking attacks. This 100-second video shows how to install and use the Chrome extension.

Some JavaScript tricks

Here’s a trick to take a snapshot of part of a web page and here’s a trick to take a snapshot of a full web page. Note that the snapshots cannot include a web page embedded in an <iframe> element.

A feature in Chrome 90 to create links to highlighted text in a web page

A short article on The Verge describes this new, interesting feature of Google Chrome.

12 - Part 9: Project Management

Source Control

1. Front end, including web pages served as static resources: https://github.com/Mashweb/web-call.cc
2. Back end: currently none. The web pages containing the front end code are simply served as static resources by a web server like Apache 2, Nginx, or Hunchentoot. At some point a Hunchentoot or Ruby on Rails backend will be put in place. It will provide authentication and authorisation for access to the back end database.
3. Back end database: a special purpose, Common Lisp based RESTful web service exists to serve HTML DOMs stored as s-expressions: https://github.com/Mashweb/ZenDatabase
4. Associated Ruby on Rails based “non technical” club website: https://github.com/Mashweb/mashweb.club
5. Static web pages served by GitHub Pages and accessed by the subdomain doc.mashweb.club, containing some demos and documentation (mostly the white paper): https://github.com/Mashweb/mashweb.github.io
6. WordPress pages on the subdomain blog.mashweb.club: accessed via a WordPress admin login.

Team Discussions

See https://github.com/orgs/Mashweb/teams/pre-alpha-zen/ .

web-call.cc Wiki

See https://github.com/Mashweb/web-call.cc/wiki .

Agile Development Management\

See https://www.pivotaltracker.com/n/projects/70151

Quick Sharing

Some facilities for quick sharing of demos and prototypes:

1. No-IP.com and alternatives (or go directly to a comparison of the top 5)
2. ngrok.com

13 - Part 10: Zen Status Report

When I started thinking about Zen years ago, the base level motivations for it were:

1. A web page has a conceptually simple construction: boxes within boxes and boxes laid on top of other boxes. (These features are common in computers’ desktop environments.) Thus HTML and CSS scream out “Give me a visual DMI (direct manipulation interface) for moving the boxes and adjusting their attributes like the HTML style attribute." (See http://bit.ly/HTML-attributes and https://mzl.la/3C0cazr.)
2. Why are web pages so static? Why can’t the height and width of any column or box be adjusted by dragging a mouse or finger? The new look of the page could be saved and associated with the user.
3. Why can’t new HTML elements be added to a web page? They could be attached anywhere in the DOM compatible with the HTML5 content models (see https://bit.ly/w3-content-models), which tell which kind of content can be inserted into which kind of content.
4. Noticing the parallel between HTML and Lisp’s s-expressions, I realised Lisp (and Scheme) would be able to manipulate HTML easily if a Scheme interpreter were embedded in the web page. I found 3 such interpreters: https://bluishcoder.co.nz/jsscheme/, https://www.biwascheme.org/, and Gambit Scheme in JavaScript (see https://web-call.cc/gambit-in-javascript.html and http://www.iro.umontreal.ca/~feeley/).
5. Scheme has another wonderful feature: it can adopt any kind of syntax.

Later on I realised Scheme can provide an extremely useful piece for building tiny operating systems in client-side (web browser) programmes. This building block is the true continuation. No other programming language has anything like the Scheme continuation. Using Scheme continuations I created an operating system-like construct modelled after the Unix/POSIX/Linux select(2) and poll(2) system calls. (See https://man7.org/linux/man-pages/man2/select.2.html and https://man7.org/linux/man-pages/man2/poll.2.html.) This solves the twin problems of the stateless nature of the web and the event-driven nature of JavaScript-in-the-browser. It also makes the promise of simplifying web applications practical by moving the memory burden of stored continuations from the web server to the web browser, thus spreading out the burden across thousands or millions of computers. (See https://christian.queinnec.org/PDF/www.pdf.)

My main focus on Zen as of now:

1. Get clarity and depth on what I want the alpha release of Zen to be. There are two aspects of this: (1) the Scheme functions and macros that Zen will provide and (2) the Zen framework’s default empty web page with its builtin HTML elements and interactions to allow the creation of single page web apps (SPAs).
2. Zen currently has no arrangement for a dilettante- or amateur-oriented REPL (command line shell), but HyperCard had a concept for attaching code either to a visible object in the application. Probably this 1987 HyperCard concept (see https://en.wikipedia.org/wiki/HyperCard) evolved from a SmallTalk environment. The concept was extremely successful. Many people like high school teachers used HyperCard to create hypermedia applications before the web existed. Zen could also allow code to be attached to a web page itself, not just an object in the page. IMPORTANT NOTE: For the near future Zen will only allow programmers to create web apps with it using the Scheme programming language. It is hard to create a visual programming language. (See my beginning attempt at https://web-call.cc/visual-programming.html.)
3. Nesting of with-handlers is untested. The ability to buffer and edit character line input will be highly useful to Zen applications because a with-handlers block (see https://doc.mashweb.club/experiments/seq_webapp_biwascheme/ and https://web-call.cc/sequentially-programmed-web-apps.html) should be able to accept either a single mouse click or a complete character string using a kind of canonical mode or cooked mode (see https://en.wikipedia.org/wiki/POSIX_terminal_interface#History and https://en.wikipedia.org/wiki/Terminal_mode) so the user can use backspace or delete and other characters to do simple line editing.
4. I have used only BiwaScheme in my experiments using web continuations to create single page web apps. BiwaScheme seems not to handle Scheme exception and condition restarts. This somewhat spoils a Scheme developer’s experience. So that I don’t box myself into a corner, I have decided to replace BiwaScheme with Gambit Scheme. All the interfaces to JavaScript and the web page that these two Schemes use are different, so I’ll have a lot of adaptation or reworking to do to replace BiwaScheme with Gambit Scheme.
5. My experimental website, where I put my latest code in its alpha, possibly bug-ridden state, is running on the Apache web server and provides no personalisation of the website: no signups/registration, no saving of the user’s work, no persistence of changes made to web pages through Zen’s interfaces. I have deployed a web server, web framework, and test applications based upon the Radiance web framework, which is written in Common Lisp. It is viewable at http://164.90.211.183:8080/. I want to use it to personalise a Zen experimental website and persist user work. Later on I realised Scheme can provide an extremely useful piece for building tiny operating systems in client-side (web browser) programmes. This building block is the true continuation. No other programming language has anything like the Scheme continuation. Using Scheme continuations I created an operating system-like construct modelled after the Unix/POSIX/Linux select(2) and poll(2) system calls. (See https://man7.org/linux/man-pages/man2/select.2.html and https://man7.org/linux/man-pages/man2/poll.2.html.) This solves the twin problems of the stateless nature of the web and the event-driven nature of JavaScript-in-the-browser. It also makes the promise of simplifying web applications practical by moving the memory burden of stored continuations from the web server to the web browser, thus spreading out the burden across thousands or millions of computers. (See https://christian.queinnec.org/PDF/www.pdf.) My main focus on Zen as of now: Get clarity and depth on what I want the alpha release of Zen to be. There are two aspects of this: (1) the Scheme functions and macros that Zen will provide and (2) the Zen framework’s default empty web page with its builtin HTML elements and interactions to allow the creation of single page web apps (SPAs).Zen currently has no arrangement for a dilettante- or amateur-oriented REPL (command line shell), but HyperCard had a concept for attaching code either to a visible object in the application. Probably this 1987 HyperCard concept (see https://en.wikipedia.org/wiki/HyperCard) evolved from a SmallTalk environment. The concept was extremely successful. Many people like high school teachers used HyperCard to create hypermedia applications before the web existed. Zen could also allow code to be attached to a web page itself, not just an object in the page. IMPORTANT NOTE: For the near future Zen will only allow programmers to create web apps with it using the Scheme programming language. It is hard to create a visual programming language. (See my beginning attempt at https://web-call.cc/visual-programming.html.)Nesting of with-handlers is untested. The ability to buffer and edit character line input will be highly useful to Zen applications because a with-handlers block (see https://doc.mashweb.club/experiments/seq_webapp_biwascheme/ and https://web-call.cc/sequentially-programmed-web-apps.html) should be able to accept either a single mouse click or a complete character string using a kind of canonical mode or cooked mode (see https://en.wikipedia.org/wiki/POSIX_terminal_interface#History and https://en.wikipedia.org/wiki/Terminal_mode) so the user can use backspace or delete and other characters to do simple line editing.I have used only BiwaScheme in my experiments using web continuations to create single page web apps. BiwaScheme seems not to handle Scheme exception and condition restarts. This somewhat spoils a Scheme developer’s experience. So that I don’t box myself into a corner, I have decided to replace BiwaScheme with Gambit Scheme. All the interfaces to JavaScript and the web page that these two Schemes use are different, so I’ll have a lot of adaptation or reworking to do to replace BiwaScheme with Gambit Scheme.My experimental website, where I put my latest code in its alpha, possibly bug-ridden state, is running on the Apache web server and provides no personalisation of the website: no signups/registration, no saving of the user’s work, no persistence of changes made to web pages through Zen’s interfaces. I have deployed a web server, web framework, and test applications based upon the Radiance web framework, which is written in Common Lisp. It is viewable at http://164.90.211.183:8080/. I want to use it to personalise a Zen experimental website and persist user work.