A fascinating 1992 mailing list post from Tim Berners-Lee where he briefly outlines his desires for a programming language for the web — basically, what JavaScript could have been. The principles of hypertext are on full display:

You need something really powerful, but at the same time ubiquitous. Remember a facet of the web is universal readership.

Then there's the PL nerdery:

Ideally, the language should include object-oriented inheritance, a basically functional nature, and a clean syntax. It should be interpretable and compilable. At least one public domain. A pre-compiled standard binary form would be cool too.

My favourite bit, though, is the desire for the client/server to negotiate over the language of the executable document, just like they negotiate other details. There are some wild isomorphism implications here.

In reality, what we would be able to offer you real soon now with document format negotiation is the ability to return a document in some language for execution, with the option of being able to provide it in several languages, the language being a "data format" which can be negotiated between client and server at run-time. For, for example, one could provide it in viola script and/or in /bin/sh which would cover most ofthe unix world.

Could have been? I mean, this is pretty visionary, and I feel like we just got there. With the data-urls we finally have model-view independence for serializable stuff, combine with WebSocket for multi-client applications. (Caveat that I'm not working with distributed object programming, which sounds like it's just for safely mutating the objects.) Or are you pointing in the direction of embedding other languages, e.g. clingo ASP via WASM? The claim of ES6 to myriad useful forms is quite strong. Here I thought we'd magically emerged from the bad old jQuery days. But seeing ES6's full lineage in Calculating Empires was revelatory. Universal readership! Hahaha. The hypertexts were so successful that now we have too much of a good thing.

Reminds me of some of my own "web future" ideas (currently languishing in private notes I should publish some day)... > The most fundamental innovation of the web is the addressable, decentralized distribution of software / pages / data over the network, together with a trusted user agent watching out for the user's security and privacy while it runs untrusted code. > > Over the decades, various giant monolithic browser engines have piled more and more specs and features on top of this core idea. It's not possible to select just the bits you need for your own project. Many of those features became deprecated long ago, but can't be removed for fear of breaking compatibility. > > This project reimagines the web as a tools for all, instead of screen for consumption. This vision empowers authors to build whatever they desire, while also supporting users with a safe, trusted environment, as well as inviting them to participate and customize however they wish through new tools and abilities everyone can understand. Creative documents and interactive experiences should not be trapped inside the monolithic browsers we have today. It should instead be more like an customizable OS service, an integral part of the core computing workflow, but also one which is managed and presented in the way the user finds most optimal for each document or experience. A website would essentially describe a set of modules (perhaps Wasm or something else) that are then used (safely) to display the content, so authors can escape some of the constraints of today's web while retaining the key innovation of safe distribution of untrusted programs.

Without voicing support or dissent, I just want to flag an interesting contrast between what you wrote:

safe distribution of untrusted programs

… and what Tim BL wrote:

a document in some language for execution

Concretely, the framing of "program" versus "document" feels worth reflecting on.

Ah yeah, interesting… I suppose my mental model of the web thinks of all “documents” as programs, even if they are “static pages”… Those are just simpler programs. 🙂

I think an important part of "document" is that it suggests an "editor" for it exists and is readily available. Whereas "program" often implies a compiled artifact.

Ah yeah, I see what you mean with document and editor. Compiled-ness implication is unintentional, so something for me to mull over if I ever finally publish it.

Another relevant distinction comes from the Rule of Least Power (co-authored by Tim Berners-Lee). The term "program" suggests a Turing-complete language. Documents have a lot to gain from a less powerful language (such as HTML). I'd love to see the idea of "scalable language families" (last paragraph) be taken up in PL research.

Basically rethink the www to switch away from readership facet. Otherwise no pl for web as Sir Lee envisioned.