The reason the Web needs rescuing is because it's not a particularly well-designed system that has been patched over and over again for the last quarter century. And now it has been degraded to a delivery layer for JavaScript apps, a poor RPC protocol and an overly complex UI rendering toolkit.
It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing. If you look closely, cloud services created tools to easily do all those things and that's how they got in control.
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs."
-- Alan Kay.
A lot of web devs were enraged by his comment without listening to the context. He was talking about the lack of protocol-level solutions for resilience of the Web.
> protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing
It does [1][2][3]. It's not the most elegant, it's not without flaws, but it's there, and enough to build against. Proprietary services weren't bound by having to code against a standard, so they cranked out something quick (and mutually incompatible), skinned an attractive interface, offered it for free (!) and attracted lots of users, who in turn attracted more users with the network effect. This is why Facebook, Wikipedia, Google Docs, Github won, and protocols like WebDAV lost.
This future was crafted by the makers of web browsers themselves: first by shifting the focus onto rendering arbitrary mediatypes delivered by HTTP from focusing on the intrinsic builtins of HTTP as a protocol, and later by trying to "standardize" the rich interactivity offered by the likes of Shockwave, Flash, and Silverlight, creating more and more APIs inside the browser that allowed client-side Javascript to communicate with the underlying system. Web developers aren't blameless, but today's web is exactly how Google, Mozilla, and Microsoft, in reverse order, steered it since the late 1990s.
Saying that WebDAV lost to Facebook is a bit like saying HTTP POST and DELETE actions lost to Facebook.
I was thinking of publishing and versioning of a different kind. For example, right now the only way to see how some website looked 10 years ago is to go to webarchive.org. 5% of all links on the web get broken every year. Isn't that something worth solving more systematically? In this respect content-addressable Web is a very interesting idea.
It's interesting, but the average web publisher doesn't care, and might actually see being able to retrieve past versions of a page as a bug rather than a feature. So it's not clear why they would implement it, or store old versions of page data on their server, or make that data available to users even if it was stored.
The web exists because it's a bunch of 90% solutions glued together. It's New Jersey style. And that's what works and survives. And we should be incredibly suspicious of attempts to do ground-up rewrites, because such things almost never end well, and typically fail spectacularly.
There were lots of other proposed protocols besides HTTP that had more functionality and features, but were more complex to implement, such that they never caught on. E.g. all those OSI-stack protocols, the majority of which were basically DOA because they tried to do too much. (CMIS could in theory do some sort of versioned document storage and retrieval, although I'm sure OSI probably had its own protocol for that, which I've just never had to work with.)
WebDAV is the right approach, in that it builds on an established, working, well-tested and thoroughly implemented protocol and doesn't attempt some sort of crazy forklift upgrade. It's evolutionary, it's backwards-compatible, and it's probably extensible enough to do document versioning if someone really wanted that.
The problem is that there's a three-part chicken-and-egg-type problem between protocols and client software and content. The protocols need to exist before client software can implement them, client software has to implement them before content can be created that uses them, but client-software developers are often reluctant to implement protocols unless there's user demand, which only comes if there's content available. So we tend to only get protocol improvements when a whole bunch of people agree that "hey this would be really beneficial" and everyone leans in to get it done. AFAIK, there's not that consensus on something like versioned web to make it work yet.
> It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing. [...] He was talking about the lack of protocol-level solutions for resilience of the Web.
That's completely at odds with what Kay actually advocates for. His position is strongly aligned with the "mechanism, not policy" philosophy. That is, what he advocates for is less of what you want, not more. This is apparent from that Dr Dobbs interview, his work with VPRI, back to his OOPSLA speech in 1997. To wit:
> HTML on the Internet has gone back to the dark ages, because it presupposes that there should be a browser that should understand its formats. [...] You don't need a browser if you followed what this staff sergeant in the Air Force knew how to do in 1961. Just read it in, it should travel with all the things that it needs, and you don't need anything more complex than something like X Windows.
Kay has always sat on the diametrically opposite site of the table as those favoring the Principle of Least Power—one of the most underappreciated tenets of computing. Tim Berners-Lee called it out in Axioms of Web Architecture:
> At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. The only way to find out what a Java applet means is to set it running in front of a person.
You can get a better view of what a world that more closely adhered to Kay's vision would look like in Stanislav's (an adherent's) post, "No Formats, No Wars": http://www.loper-os.org/?p=309
Having watched nearly every talk/interview of Kay I could find on YouTube (which includes the OOPSLA keynote) and having read some of his writings I think I have a reasonably good understanding of what he is advocating for.
Here is Kay talking about Internet's resilience in a bit more detail:
>and having read some of his writings I think I have a reasonably good understanding of what he is advocating for.
In the Dr Dobbs interview[1] that you pulled the quote from, Alan Kay is not talking about protocols for web resilience. Actually, there is no mention of "protocols" in that article at all.
Even outside of that particular article, AK doesn't talk much about "protocols" other than the protocol of "message passing" in Smalltalk which is a different meaning from "internet protocols".
Tim Berners-Lee is a figure that speaks of new protocols for decentralization, etc. That's not Alan Kay's angle. If you think AK is imploring the tech community for new internet protocols, you need to cite another AK source other than that Dr Dobbs interview.
>[Alan Kay] was talking about the lack of protocol-level solutions for resilience of the Web.
That's not what he's talking about. He's complaining that the "web" did not make it easy for people to do computing. One example in that interview was Wikipedia page on Logo programming language not being able to execute Logo programs.
Kay's criticism of the "web done by amateurs" looks to be the same train of thought about his ideal Dynabook enabling people to participate in computing rather than something like the Apple iPad where people just read news or watch videos.
This I think is the most important question in search of a better web architecture. You could say it's the HTML vs LaTeX question. I don't mean the "hard to develop with macros and mountains of documentation and ungraspable errors and imcompatible packages" aspect to LaTeX. But rather the question of introspection. (Think also of bibtex and how to compile a document relying on it)
IMHO both approaches are crap and barely work. I don't actually think HTML supports web searches or semantics very well, and obviously it is painful to develop interactive applications in, as well. Same goes for LaTeX, even though it's coming from the other side.
I think we should have containers instead, with in-band data (somewhere linked in a for-the-web assembly language) and out-of-band metadata (in various formats, to support search engines or other enterprises).. Granted, site providers could play tricks by serving disagreeing data over these channels, but in a way that's possible even now with HTML.
Yeah, the Internet had coalesced around one standard, TCP-IP, after fighting with national standards and networks like Minitel.
Now with the Web, the approach has always been to define the front end standards for "user agents" and leave the back end standards to "someone else".
Here is what would make the Web wayyy better:
Support for content-addressable protocols via IPFS ans SAFE. You can already leverage SRI to get some of the "content addressable hashes" but you need a DHT to locate and host the stuff. That way the Web becomes resilient (no single points of failure and you can trust the content) while retaining all its front end goodness.
No more concepts of DOMAINS at all, but rather, each resource of information can be an evolving community in itself. Like people collaborating on a document.
> The reason the Web needs rescuing is because it's not a particularly well-designed system...
The problem is that you cannot predict the future. Standards have to bend and twist to move with the times. The Internet standards were decent for the time they were created. And UI fads will dictate things whether that's logical or not. Humans love fads.
The web needs rescuing not because of technical issues, but because businesspeople and nontechnicals have twisted it far from its original intent and then captured everything that could as 'added value'. "Digital colonialism" is an incredibly apt term for this, and now with NN no longer governing traffic flow, the web needs a reboot away from those that would stick their grubby mitts in the stream.
The web is heavily abused because many developers are not aware of its misguided history or even what the web is for.
To be extremely clear the web is a document (markup) delivery/rendering application. The design goal of the web is to deliver documents that contain hyperlinks, where those hyperlinks address content extension. The web had no intention to be anything else.
That said the web was hijacked, for lack of a better term, by early web browsers that intended to do things that the web was never intended to do. This is how we got JavaScript. Fortunately, it also resulted in a universally standard architecture (the DOM), and additional technologies, that extended the web's original vision.
The problem today is that most developers have no idea what the web is or really how it works. Now, if you ask a developer about this they will claim otherwise and will work really hard to down play their ignorance. If you are not deeply aware of coding for the DOM, lexical scope, accessibility, asynchronicity, presentation separation, and so forth you are ignorant of how these things work. These are not expert qualities, these are the basics. This largely explains why so many people think HTML is the easiest thing to learn and then written really shitty HTML.
> That said the web was hijacked, for lack of a better term, by early web browsers that intended to do things that the web was never intended to do. This is how we got JavaScript.
I'm not sure that this is accurate. Tim Berners-Lee in his 1989 proposal for the World Wide Web [1] contemplates usage that is compatible (or at least not incompatible) with the JavaScript we have today. Excerpts from his proposal:
> "Hypertext" is a term coined in the 1950s by Ted Nelson [...], which has become popular for these systems, although it is used to embrace two different ideas. One idea is the concept: "Hypertext": Human-readable information linked together in an unconstrained way.
> The other idea, which is independent and largely a question of technology and time, is of multimedia documents which include graphics, speech and video. I will not discuss this latter aspect further here, although I will use the word "Hypermedia" to indicate that one is not bound to text. [...]
> The data to which a link (or a hot spot) refers may be very static, or it may be temporary. In many cases at CERN information about the state of systems is changing all the time. Hypertext allows documents to be linked into "live" data so that every time the link is followed, the information is retrieved. If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide. [...]
> Many systems have been put together with little or no regard for portability, unfortunately[]. However, there are several interesting projects and more are appearing all the time. Digital's "Compound Document Architecture" (CDA) , for example, is a data model which may be extendible into a hypermedia model, and there are rumours that this is a way Digital would like to go. ['Compound document' refers to a document that combines text with non-text such as spreadsheets, pictures, video and audio, etc.]
Burners-Lee goes on to sketch out what such a system might look like, and characterizes the current browser/server architecture, emphasizing the separation between display logic and server logic, and anticipating the evolution of those display programs:
> Let us see what components a hypertext system at CERN must have. The only way in which sufficient flexibility can be incorporated is to separate the information storage software from the information display software, with a well defined interface between them. Given the requirement for network access, it is natural to let this clean interface coincide with the physical division between the user and the remote database machine.
> Therefore, an important phase in the design of the system is to define this interface. After that, the development of various forms of display program and of database server can proceed in parallel. This will have been done well if many different information sources, past, present and future, can be mapped onto the definition, and if many different human interface programs can be written over the years to take advantage of new technology and standards.
I read Burners-Lee's writing as very much anticipating the modern browser, JavaScript included.
It's also worth mentioning that Roy Fielding, one of the principal authors of the HTTP specification (along with Burners-Lee), characterized Code-on-Demand (that is, scripting/VMs, e.g. Java and JavaScript) as a core constraint of Representational State Transfer (REST) [2]. The REST architectural style, as described in Fielding's thesis published in 2000, is intended to characterize the architecture of the Web.
> A distributed hypermedia architect has only three fundamental options: 1) render the data where it is located and send a fixed-format image to the recipient; 2) encapsulate the data with a rendering engine and send both to the recipient; or, 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine. [...]
> REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface. REST components communicate by transferring a representation of a resource in a format matching one of an evolving set of standard data types, selected dynamically based on the capabilities or desires of the recipient and the nature of the resource. Whether the representation is in the same format as the raw source, or is derived from the source, remains hidden behind the interface. The benefits of the mobile object style are approximated by sending a representation that consists of instructions in the standard data format of an encapsulated rendering engine (e.g., Java [45]). REST therefore gains the separation of concerns of the client-server style without the server scalability problem, allows information hiding through a generic interface to enable encapsulation and evolution of services, and provides for a diverse set of functionality through downloadable feature-engines. [...]
> The final addition to our constraint set for REST comes from the code-on-demand style of Section 3.5.3. REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.
So my take on history is that key designers of the modern Web always envisioned it as being capable of delivering and displaying dynamic content with an evolving set of capabilities.
Lastly, an excerpt from an interview with a Wired interview of Burners-Lee from 2014, characterizing JavaScript as part of the web's "fabric" and emphasizing its ability to evolve [3]:
> The good news is that the web has openness and flexibility woven into its fabric. The protocols and programming languages under the hood – including URLs, HTTP, HTML, JavaScript and many others – have nearly all been designed for evolution, so we can upgrade them as new needs, new devices and new business models expose current limitations.
> It's also worth mentioning that Roy Fielding, one of the principal authors of the HTTP specification (along with Burners-Lee), characterized Code-on-Demand (that is, scripting/VMs, e.g. Java and JavaScript) as a core constraint of Representational State Transfer (REST) [2]. The REST architectural style, as described in Fielding's thesis published in 2000, is intended to characterize the architecture of the Web.
Not exactly. REST is only semantic addressing. It becomes an architectural principle when that is the primary basis for the organization of content. That said it is additive to the organizational concept of hyperlinks, but it does not replace or disqualify the original intention of content distribution.
> Burners-Lee goes on to sketch out what such a system might look like, and characterizes the current browser/server architecture, emphasizing the separation between display logic and server logic, and anticipating the evolution of those display programs:
That is how we came to something like CSS. I remember developing for the web in the 90s and browsers completely abandoned this concept. This concept of separation didn't become a practical reality (cross-browser) until about 2006 and then was still challenging in those (IE6) days.
> Lastly, an excerpt from an interview with a Wired interview of Burners-Lee from 2014, characterizing JavaScript as part of the web's "fabric" and emphasizing its ability to evolve [3]:
Yes, the current web cannot function without something like JavaScript. That is the web adapting to the technology opposed to the technology adapting to the web.
It should have had protocol-level technologies for preserving historic data, for search, for offline use, for authoring and publishing. If you look closely, cloud services created tools to easily do all those things and that's how they got in control.
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs." -- Alan Kay.
A lot of web devs were enraged by his comment without listening to the context. He was talking about the lack of protocol-level solutions for resilience of the Web.