In March 1989, Tim-Berners Lee (aka TimBL), a scientist at CERN in Geneva, Switzerland, proposed a Hypertext-based system to organize the incredible amounts of information generated annually by the organization. He followed this proposal with prototypes, leading to the creation of the first web server and browser and the development of the first versions of the HTTP protocol and the HTML markup language.
CERN needed a way to cope with a massive turnover of scientists generating tons of written content, primarily papers, journal articles, and the occasional book draft. Words on those documents should easily be “linked” to other documents on the same network to enable references, discussion, and sharing.
Unbeknownst to most younger developers, “Hypertext” was one of the hottest ideas at the end of the eighties; it was right up there with Object-Oriented Programming, the Lambada (no, not “Lambda,”) and the first Batman movie. It is no coincidence that TimBL used the H word in his proposal. Case in point: the October 1988 issue of Byte Magazine (available on newsstands merely five months before the proposal) is titled “Hypertext.” It contains several pages of explanations and historical references to various Hypertext ideas, prototypes, and concepts, including Vannevar Bush‘s Memex, Ted Nelson‘s Project Xanadu (nothing to do with Olivia Newton-John, pretty promise), and Apple’s HyperCard software product.
We will never know, but let us pretend that TimBL had a copy of this magazine on his desk while drafting the proposal. It is said that the very moniker of “Home Page” comes from Apple’s HyperCard and its “Home Card,” where all interaction would begin. We also know that he attended the HyperText conference in San Antonio, Texas, in December 1991.
It means that the Web (with an uppercase W) we have been using for the past 25 years was born as a Hypertext (with an uppercase H) document management system. Its most important feature, by all means, was the <A HREF="…"> tag, enabling words to appear underlined in blue and making the “Hypertext” concept a reality. Couple that with a “Back” button driving a FIFO data structure in memory; boom, you have got yourself a browser.
Various other standards have joined HTML ever since, most notably JavaScript in 1995 and CSS in 1996, forming the saint trinity of web development technologies: HTML, CSS, and JavaScript, each providing structure, style, and behavior to everything we see online. Each of these languages became standardized, and many others came after, all managed by a single group of people collectively called the W3C, short for “World Wide Web Consortium.”
Despite such conceptual origin, however, the Web became a construction of historical proportions; the computer industry equivalent of Gutenberg’s press, if you are into corny comparisons. Leaving aside the ripples generated in the social and economic tissue of our modern world (which are many, including a global stock market crash in 2000,) software developers have embraced the Web and transformed the aforementioned trinity of technologies (HTML, CSS, and JavaScript) into a fully-fledged “platform” (whatever that is) upon which to deploy applications of all kind.
The problem is that the Web was never meant to be a programming platform. Remember? It was a document-sharing-and-linking system. It was coerced into a programming platform.
Starting with Paul Graham and his Viaweb project in 1995, followed by NeXT’s WebObjects the same year, companies and individuals have created again and again a myriad of systems used to generate HTML, CSS, and JavaScript in one way or another. A lot of “innovation” and billions of dollars have been poured into projects that are just essentially glorified text generators. Thus, “web applications” were born.
One of web applications’ most significant selling points was the “single deployment” idea: copy your app to a server, give customers a URL, and profit. Time for an upgrade? No need for CD-ROMs or downloading binaries; update the app, and let your users enjoy new features and bug fixes immediately. Coupled with the emergence of the Agile movement, a whole new category of software developers emerged in 1997, crashed in 2000, and re-emerged in 2004 thanks to the “années folles” also called the Web 2.0 frenzy.
Since neither HTML, CSS, nor JavaScript was “developer-friendly” enough, we have created other languages to generate them: Haml, Mustache, Emmet, Sass, LESS, CoffeeScript, TypeScript, and so many others are leaky abstractions built on top of the trinity so that developers could finally make the apps they needed within time and budget.
It is pointless to enumerate the gazillion forms these abstractions have taken shape. Still, it is worth mentioning one: a file format (usually referred to as JSX or TSX, depending on whom you ask) merging the three elements of the trinity into a single file (something that Microsoft had tried 15 years before with those HTAs for Internet Explorer 5.) Those JSX files are at the core of one of the hottest new trends of the 2010s: Single-Page Applications, or SPAs, built by a new generation of “front-end engineers” dealing every day with npm and its various quirks (and security issues.)
SPAs effectively moved the generation of HTML from the server to the client; usability was dammed. For a long time, servers processed requests and returned HTML, but after Douglas Crockford invented JSON, it became apparent that we could also return pure data instead. Given the new “AJAX” capabilities of modern browsers (that is, browsers that were not Internet Explorer 6) and the fact that we finally understood JavaScript (thanks, Douglas!), developers gradually moved the generation of HTML from the server to the client. REST begat GraphQL, and the rest is history.
The thing is, SPAs are a terrible idea.
Moving text processing from the server to the client meant downloading tons of megabytes of (hopefully minified) JavaScript to customers and letting them deal with broken “Back” buttons. Of course, this also meant cheaper hosting for companies, which makes stockholders happy. Some SPAs require server-side processing, particularly for user authentication and authorization, and some other intensive operations, such as generating PDFs or processing video; otherwise, they defer all logic processing to the client.
The result is a terrible degradation in user experience, particularly for resource-constrained devices such as mobile apps and smart TVs, and for users in locations with poor connectivity, which is a lot of places. Still, developers in first-world countries with lots of bandwidth could not care less. Most of these apps seem to be built around a single assumption: let us just hope the user does not hit the back button, and everything will be fine.
We also got “real time” technologies to enhance our experience. We mentioned AJAX previously: another thing initially invented by Microsoft as an ActiveX component to empower its Microsoft Outlook web application on Internet Explorer, later adopted by Firefox and Safari. Then we got WebSockets, and its less well-known sibling, SSE (Server-Sent Events,) a much simpler yet often overlooked alternative to WebSockets.
In the meantime, such is the importance of HTTP (and HTTPS) as a protocol for our modern world that a whole new platform (Kubernetes) was built to serve content by default on port 80 (or 443, respectively.)
JavaScript became minified JavaScript which became WebAssembly which became WASM, and now we can compile Rust apps into WASM and run them into Kubernetes to render complete user interfaces… as HTML. A full SPA generated from Rust, hell yeah! Hey, Rust can even help you if you missed Flash movies on your website.
Knock knock, who is that?
Hold my beer: Hotwire proposes the revolutionary idea of… sending HTML over the wire.
Crickets.
Meanwhile, Ruby on Rails, PHP, ASP.NET, and Java developers are shaking their heads in dismay while they deliver an umpteenth server-rendered web application to their customers. Who woulda thunk? Servers are cool again. But running monolithic apps in Kubernetes remains challenging; good luck deploying that Mastodon instance on your cluster.
But things are not going well. TimBL has regrets. Jake Archibald is swearing. Brian LeRoux is sad. PPK does not know whether to teach Flexbox or Grid CSS first. MIT is withdrawing from the W3C; Safari (or Chrome?) risks becoming the new Internet Explorer; the Google Gruyere app shows that security was always an afterthought. In the meantime, ChatGPT is creating a new HTML standard element for music, and developers are still unsure which HTTP headers are case-sensitive.
One of the original goals of Ted Nelson’s Xanadu project was to avoid broken links; on the Web, the best we can aspire to is to have our web page crawled by the Internet Archive’s Wayback Machine and to be able to point to it instead in the future. So please ensure your 404 page is user-friendly; it will be shown very often.
Maybe Web browsers as we know them are just a first step in the good direction. Maybe Kubernetes is another step in that direction. Maybe there will be an upcoming technology (open and standardized) that will make real web applications possible, with a single programming language, a unified debugging experience, and a mandatory plugin for Visual Studio Code. With it, developers will finally deliver apps on time and within budget, using a single, modern programming language running in a distributed platform that serves users with structure, style, and behavior.
Or maybe, just maybe, the paragraph above is the reason why so many billion dollars have been invested in innovation around web technologies. As a community effort, the Web (HTML, CSS, JavaScript) is already the best platform it could ever be, and all those leaky abstractions built on top (Haml, Sass, TypeScript) are not only necessary but also unavoidable.
This author is praying for the return of server-side rendering, with good old Mustache templates, short and sweet vanilla JavaScript (seriously, you might not need jQuery anymore these days,) and small and lean HTML pages with just enough CSS to get things done, one page at a time. If you are a front-end developer, consider stopping using JavaScript for something it was never meant to do. Correction: consider using the Web as it was meant to be used: as a set of linked pages. Stop manipulating the Back button with JavaScript; browsers can do that job perfectly well; thank you so much.
The Web was conceived as a document browsing environment; stretching it in other directions, particularly for software applications, was a mistake.
(Just like misusing its good name in this whole “web3” nonsense which has nothing to do with the Web.)
Cover photo by Denny Müller on Unsplash.
