DEV Community: Frédéric Bonnet

The Third Age of Web Development

Frédéric Bonnet — Fri, 01 Jan 2021 21:36:57 +0000

Cover image: A sketch of primate origins from Charles Darwin's notebook, dated 21 April 1868

The Third Age of web developments is the period that follows the Second Browser War, after Microsoft Internet Explorer lost its dominance on the web browser market (2012-today).

The Postmodernist Period and the Second Browser War

The transition between the Modernist and Postmodernist periods is marked by the intense pace at which new web frameworks and practices emerge, evolve, and fall from grace. Non-imperative paradigms became mainstream: asynchronous, reactive, functional... The JavaScript-based AngularJS was completely rewritten to become Angular 2, a TypeScript-based framework. Between 2015 and 2020, 9 versions of the Google-backed framework were published, once every 6 months on average! Between 2016 and 2020, Facebook published 3 major versions of its React framework, no less than 20 minor versions, and version 16.8 introduced a major paradigm shift with React Hooks. Vue.js, released in 2014, soon became the third major frontend option between Angular and React. New frameworks and libraries were born every day. Web developers, who used to follow browser releases as they adopted new features, now preceded them with transpiling tools such as Babel that seamlessly transform not-yet-supported language features, Web APIs (sometimes experimental!), and new languages like TypeScript into backward-compatible code.

On the frontend, the Modernist SPA was still king, however the shortcomings of this model became more and more apparent as it rose to domination: SPAs make client-side scripting a strong requirement, they have to download large assets at startup, display the dreaded "White Screen of Death" to slower or older Web clients, don’t allow deep linking, can’t be indexed by search engines, and are often too resource-hungry for low-end terminals such as mobile phones or smart TVs, let alone outdated browsers on non-upgradable systems. Simply put, the basic principles of the SPA model are in direct contradiction with the core philosophy of the web: Graceful Degradation.

The Postmodernist period also saw the rise of the mobile web. When Apple released the first iPhone in 2007 with its WebKit-based mobile Safari browser, mobile Web usage was marginal. In 2015, as mobile Web browsers rose to 30% of the market, Google announced the "Mobilegeddon", a major revision of its ranking algorithm to favor mobile-friendly sites with new metrics based on ergonomics and performances. Performance audits became the daily life of Web developers where Time-To-Interactive (TTI) is a matter of life and death on the race to the top pages of Google Search results.

Faced with this new reality, frontend frameworks started to introduce performance improvements such as Ahead-of-Time compilation (AoT), brought back the good old SSR model of past periods with a reversal of workflow and a bit of rebranding (for example Angular Universal is SSR for Angular components), and reinvented techniques that had been available since the dawn of the Web: lazy loading and code splitting are features that plain Web pages get for free but for which SPAs require explicit design. Web development went full-circle, old is the new new, only more complex.

The mobile revolution also had a major impact on backend architecture. The monolithic backend of previous periods struggled to scale under the massive traffic induced by new mobile applications. Microservice architectures split the monolith into separate processes with fine-grained responsibilities, distributed over large clusters or cloud services and orchestrated with dedicated middleware. And web clients rely more and more on third-party services for social authentication or web-native databases such as Firebase.

The intense competition of the Postmodernist period pushed minor browser vendors out of business or forced them to adopt their competitor’s engines, hurting the diversity of the Web clients. Opera gave up its own Presto engine in 2013 for Google’s WebKit implementation, soon replaced by Blink. Even Firefox suffered from the situation despite having one of the best engines on the market, Gecko. In 2020 the web is still in its Postmodernist period, and essential segments of the Web ecosystem are now at the hands of big tech companies such as Google, Apple, Facebook and Amazon: from frontend frameworks to cloud services, from mobile platforms to Web browsers, each pushing their own agenda. JavaScript has become the most popular language in the world, and web engines have never been faster. But the exponential growth of the JavaScript ecosystem, and the increasing complexity of the Postmodernist Web model, brought many developers to a quasi-burnout state, a phenomenon known as "JavaScript fatigue".

Milestones:

iOS Safari (2007)
OAuth 2.0 (2012)
Babel (2014)
ECMAScript 6-11 (2015-2020)
JSON Web Token (2015)

Emblematic software:

The Postmodernist Web model

Postmodernist Web applications are engineered to scale under massive traffic and from a wide range of clients, building on the Modernist Web model while addressing its shortcomings.

Postmodernist Web clients focus on improving user-centric metrics such as Time-To-Interactive (TTI), especially on low-end devices, by implementing techniques such as Ahead-of-Time compilation (AoT). Application code uses non-imperative paradigms such as functional and reactive programming. Build tools also add metrics and budgets to limit the weight of bundled assets for low-bandwidth mobile clients, and other techniques such as lazy loading and code splitting help further reduce initial page load times. Service workers help download and cache assets in the background for offline use.

On the server side, Postmodernist Web frameworks reintroduce some of the Classical Web techniques for better SEO and discoverability, such as Server-Side Rendering (SSR). Many responsibilities of traditional web servers are delegated to separate services: Content Delivery Networks (CDNs) for static web assets, Single Sign-On servers (SSO) for authentication, etc. These services can be co-located with the backend or provided by third-parties. The backend itself can be split into microservices for asymmetric scalability between application subdomains. Complexity shifts from applicative code to service orchestration and infrastructure.

Core value: scalability

Key features:

Frontend frameworks with SSR support and integrated toolchains
Mobile-friendly SPAs with compile-time optimizations
OAuth-based login
Web services with token-based authentication such as JWT
Modular, distributed backends with orchestration middlewares

The Neoclassical Period

On the opposite side of the web development industry, new solutions began to emerge in the early 2000’s with the promise of a return to the past simplicity of the Web. Like the Classical period, the Neoclassical period is centered around content creation, whereas the Modernist and Postmodernist periods were focused on application development. Blogs became the major support of this revival: from a handful of blogs at the acquisition of the Blogger platform in 2003, the Blogosphere grew exponentially with hundreds of millions of blogs and millions of articles posted everyday. In parallel, Content Management Systems (CMS) such as WordPress and Drupal were increasingly used to power web sites. In 2020, roughly one out of three websites runs WordPress.

In reaction to the JavaScript fatigue of the Modernist and Postmodernist Web, many web developers began to seek alternatives to the dominant SPA model on the client side and to traditional blogging platforms on the server side. The former were too reliant on client-side scripting, a major departure from the Graceful Degradation principle the web was built on, whereas the latter were too resource-intensive on the server side with database storage and SSR templating systems at a time of massive traffic and environmental consciousness.

The Neoclassical period is a return to the original vision of the web, where the web browser served both as a client and an authoring tool. Web content creation should be accessible to anyone and not restricted to professional developers. Additional features should be easy to add. Third-party libraries should be easy to integrate. Tools should be simple to use and easy to understand. Frameworks should not be over-engineered for general-purpose application development, but should concentrate on specific goals and features. The build process and its output should be transparent and controllable. Backends and web services should only be used when required. Websites should gracefully degrade.

Launched in 2008, Jekyll was the first modern Static Site Generator (SSG) that combined the old principles of web asset generation with modern techniques and toolings. With a bunch of Markdown files (a text format much easier to author than HTML), one could generate a complete, modern, nice-looking website with almost no effort from a stock or custom template, and host it on cheap static hosting services such as Netlify. The templates were easy to modify to fit one’s tastes, add new features, or integrate third-party services such as comment systems. Web developers could use their skills to write their own templates and turn their SSG blog into a professional portfolio. Soon other tools followed: basic SSGs such as Hugo and Eleventy use a Jekyll-like model, whereas advanced SSGs such as Gatsby, Next.js or VuePress bridge the gap between SPA frameworks and CMS by generating dynamic sites from static content. Once a developer tool with command-line interfaces and Git workflow, SSGs are now full publishing chains with continuous delivery from the source content repository to the hosting service. Online one-click installs and CMS-like editors push the model even further.

On the server-side, the rise of cloud computing led to the emergence of the Function as a Service model (FaaS), also known as Serverless computing. Opened in 2014, AWS Lambda became the first generally-available FaaS service with pay-as-you-go billing, autoscaling, and support for multiple runtime environments. AWS Lambda defined a backend architecture model, with monolithic or even microservice server processes being split into stateless, short-lived functions that could scale independently. The Serverless model soon became a cheap and easy way to enrich static sites with server-side code.

Milestones:

RSS 2.0 (2002)
Google Blogger service (2003)
Markdown (2004)
Jekyll (2008)
AWS Lambda (2014)

Emblematic software

The Neoclassical Web model

The Neoclassical Web is centered on content creation. It does not reject modern tools and techniques but makes an enlightened and parsimonious use of them. It also acknowledges the new reality of the web ecosystem with the ubiquity of mobile web clients and the exponential growth of web traffic. To do so, it embraces the static web page model where web assets are either authored directly or produced by Static Site Generators (SSG) from templates and raw content files (such as Markdown files for example), before being stored on a static HTTP server or a Content Delivery Network (CDN). When needed, dynamic features can be added as client scripts, and backend logic can be implemented as serverless functions hosted on cloud FaaS services such as AWS Lambda or Google Functions. The resulting sites conform to the newest Web standards and practices, and can even take the form of SPAs, though most static sites are traditional MPAs for better SEO performances.

The combination of Static Site Generation, client-side JavaScript enhancements, static hosting on CDNs, serverless backends, and third-party APIs, constitutes the JAMStack model.

Core value: content as code

Key features:

Source content uses flat file formats such as Markdown, managed with version control software such as Git
SSGs produce web assets from source content
Web assets hosted on static Web servers and CDNs
Publishing is either manual or automated with CI/CD software pipelines
If needed, backend is provided as Serverless functions hosted on cloud services
Client code can access third-party services third-party APIs

The Metamodernist Period

As web applications grew and became more complex, frontend frameworks made this complexity manageable, at the expense of their own complexity. But the most dramatic loss of the Postmodernist period is readability. The Web has always been a transparent platform. When websites were hand-crafted, their source code was available for anyone to read. How many of us web developers learned to code by reading website source codes? The Postmodernist Web is not human-readable anymore, but machine-readable: it is transpiled, tree-shaken, minified, bundled and distributed as an unreadable mess of keywords and special characters. And with readability comes learnability. Web development is no longer about the web standards, it is about mastering the intricacies of the most popular frameworks in the shortest possible time, because these frameworks evolve so fast that you often have to unlearn the old features and practices of previous versions in favor of the new ones. And since multiple frameworks cannot coexist easily in the same application, choosing the right one has become a career choice. The web is no longer a platform but a target for competing technologies, just like during the Dark Ages.

The Metamodernist Web is the most recent iteration in the history of Web development. It rejects the framework monoculture and the unsustainable pace of the Modernist and Postmodernist models in favor of web-native solutions with a simple motto: Use The Platform. Rather than generic, full-featured frameworks, websites and applications should aggregate and integrate feature-specific solutions as needed. But above all, they should be resilient, inclusive and environmentally responsible, with a minimalist footprint, manageable complexity and transparent dependencies.

Metamodernism acknowledges that many desirable features of frontend frameworks were designed at a time where the web platform lacked native support, but new standards have emerged since then, and as the web evolves and becomes more powerful, many common development tools and practices are becoming legacy and even counter-productive. New ECMAScript language features push the Vanilla JS developer experience closer to transpiled languages such as TypeScript. ECMAScript Module support (ESM) in all recent browsers enables buildless and bundleless workflows with productivity on par with older development servers: Snowpack for example supports live reload, Hot Module Replacement (HMR), etc. And services such as Skypack, unpkg and cdnjs allow for direct integration of third-party npm modules as web page script elements without having to install them locally. Dependency- and toolchain-free development is possible again.

On the client-side, monolithic component-based frameworks are no longer required now that Web Components are available. Web Component libraries such as Polymer and Ionic can be used with any frontend framework or even with plain HTML. Micro-frontend models are more and more popular. Script-based practices that duplicate native web functions are discouraged, such as CSS-in-JS and animations.

The Service Worker API enhances the client-side model even further by off-loading technical code from the much-solicited main thread to a dedicated thread: offline mode, caching, prefetching, persistence, push notifications, etc., all these features can now be implemented more efficiently and with Progressive Enhancement in mind. Web App Manifests bring web applications even closer to native desktop and mobile apps with application icons, installability, sandboxed execution, background and offline modes, etc. The combination of these technologies forms the core of the Progressive Web Application model (PWA). And with the support of WebAssemby (Wasm) as a compilation target for system languages such as C, the web finally becomes a truly universal application platform.

Launched in 2016, Svelte is at the crossroads of the Modernist, Postmodernist and Neoclassical Web models. Svelte combines the component-based development model of frontend frameworks and the capabilities of SSGs in the form of a compiler that produces framework-free, static web assets that only depend on standard Web features. In this sense it is the first Metamodern Web framework. In 2020, Basecamp released Hotwire (HTML Over The Wire), a set of techniques used to bring SPA-like enhancements to traditional SSR applications: partial page updates, client-side navigation history, AJAX, server pushes, etc. Hotwire is also Metamodern in the way it applies Progressive Enhancement techniques to existing models.

Milestones:

Web Components (2011)
asm.js (2013)
Polymer (2013)
Service Workers (2014)
HTTP/2 (2015)
WebAssembly (2015)
ESM support in browsers (2015)
PWA (2015)

Emblematic software:

The Metamodernist Web model

Progressive Enhancement is at the heart of the Metamodernist Web model. Web pages should rely on native web features whenever possible, and may provide polyfills on a case-by-case basis. Applicative or third-party code that duplicates native web features are prohibited.

Client-side scripting is optional. Essential features may be implemented as client-side scripts as long as they also remain available by other means (e.g. server-side processing) to clients without adequate capabilities, for example when scripting is disabled or limited. Frontend and backend frameworks are optional. Dependency to third-party software must be kept minimal. The Service Worker is an ideal place to implement non-essential features and performance enhancements without blocking the main client thread.

The ideal workflow is buildless. Complex build processes and toolchains are optional, and when present they must be transparent, reproducible, and resilient. When using code generation tools, the resulting code should ideally be human-readable, although this is only a desirable goal for learnability.

Applications must be inclusive. Not all browsers are Evergreen. Not all applications need massive scaling. SSR is a perfectly fine model for many applications. Core functionalities should be available to all clients regardless of their performances and capabilities. Non-essential functionalities should be provided with Progressive Enhancement in mind.

Core value: sustainability

Key features:

Buildless, bundle-less front-end development if possible
SSG or SSR for noscript clients
No frontend framework
Web Components or micro-frontends for dynamic enhancements
Client code is Vanilla JS or transpiled to ES modules
Dependencies can be self-hosted or loaded directly from CDNs
Service Worker for non-essential enhancements: offline/background mode, caching, prefetching, resilience, etc.
Application manifest for PWA mode

A Final Word

The history of web development is rich and complex, sometimes violent and filled with controversies. Of all the web development models presented here, none can pretend to be more "web-native" than the others, and even if some models are closer to the original vision, the web platform is powerful enough to embrace them all. Every model has its strengths, its weaknesses, its proponents, its zealots and its detractors. There is no one "True Way" to web development, just tools in a toolbox. Choose the right tool for the right job.

PS: Don't forget to read the other articles in this series if you haven't already!

The Second Age of Web Development

Frédéric Bonnet — Fri, 01 Jan 2021 21:36:45 +0000

Cover image: A sketch of primate origins from Charles Darwin's notebook, dated 21 April 1868

The Second Age of web development is the period that spans between the First and Second Browser Wars, at a time when Microsoft Internet Explorer was the dominant web browser (1998-2012).

The First Browser War and the Dark Ages

Lack of standardisation, compatibility issues between browsers, incomplete support for the young CSS standard, and creeping featuritis with vendor-specific HTML tags (BLINK!!! MARKEE!!!) led to the First Browser War between the two major web browser providers, Netscape and Microsoft. The original vision of the Web as a content creation and distribution was lost. Instead, the Web was now seen as a mere distribution channel for desktop-esque enterprise apps and online minigames. And let’s face it, when it came to enterprise- and consumer-oriented software development, the Web standards were simply too immature and unstable to compete with full-featured authoring tools such as Macromedia Flash (which, ironically, used its own dialect of JavaScript called ActionScript) or professional software platforms such as Java Applets or Microsoft ActiveX. Web pages became static shells for Flash ad banners, online minigames, and proprietary software plugins. HTML became an output target for WYSIWYG editors such as Macromedia Dreamweaver. JavaScript got its lasting reputation of a slow, memory-hungry, crash-prone toy language for hobbyists. Only fools and die-hards would still hand-code their pages, or so said Serious People. The web was regressing to the benefits of proprietary software.

Milestones:

HTML 4.0 (1997)
XHTML (2000)

Core value: territorial conquest

Key features:

Web pages as a software distribution medium/application container/output format

Emblematic software:

The Renaissance Period

The post-browser war era was a period of stagnation, dominated by Microsoft Internet Explorer 6 whose market share remained unchallenged for over half a decade. The web standards efforts led by the W3C were so moribund that Microsoft decided to push their own proprietary tools and formats for application development, deeply integrated into their Windows operating system. Fearing the death of the Open Web envisioned by its creators, a group of community members formed the Web Hypertext Application Technology Working Group (WHATWG) in 2004 to work on a new HTML5 standard, improve and enrich existing standards with common practices (including proprietary ones such as Microsoft XMLHttpRequest), and open a new era of community-driven progress. This 15-year effort led to the contemporary web that we all know and cherish. This didn’t go without pain, though, as the dominance of the Microsoft Internet Explorer and its substandard Trident Engine plagued the life of web developers with interoperability issues for many years. The launch of Mozilla Firefox in 2004 was the first serious effort to challenge Internet Explorer's hegemony, but it was the creation of jQuery in 2006 that really opened the era of widespread frontend development with backward-compatible, browser-agnostic APIs for DOM manipulation and web service communication.

The increasing complexity of web applications led to the development of full-stack frameworks with heavy emphasis on the backend and close integration of the frontend, following the layered 3-tier architecture model. J2EE then JSF extended the Java backend servlet model with component models inspired by monolithic desktop applications. On the other side of the spectrum, Ruby on Rails aimed at simplifying the development of standards-based full-stack applications, centered on the convention-over-configuration philosophy and on design patterns such as Model-View-Controller (MVC).

Milestones:

WHATWG (2004)
SVG (2001)
SOAP (2003)
DOM Level 3 (2004)
Ajax (2005)
Acid2 (2005)
jQuery (2006)
HTML5 living standard (2007)
CSS Level 2 (1998) / Level 2.1 (2011)

Emblematic software:

The Renaissance Web model

The Renaissance Web is a universal application model where all layers operate on web standards without any reliance on proprietary technology. Web pages are built using standard HTML5, JavaScript and CSS, with Graceful Degradation in mind. The AJAX model built on the XMLHttpRequest API allows asynchronous communication with web services hosted on applicative or third-party servers. Whenever possible, full page reloads induced by standard web forms and links are replaced with dynamic AJAX calls and partial page updates for a better user experience. Web services can use structured, object-oriented protocols such as SOAP, or simple payload formats such as JSON or XML. Application logic is still mostly implemented on the backend, but the frontend is increasingly more complex and reliant on third-party libraries for interactivity, dynamic DOM generation, and GUI components. Frontend and backend development complexity tend to converge.

Core value: open community

Key features:

Frontend libraries
Asynchronous client-server communication
Web service protocols
Graceful Degradation
Full-stack and component-based frameworks
Monolithic applications

The Modernist Period

With the rise of jQuery, Web developers began to envision a model where the Web client would no longer be limited to a thin presentation layer, but become a full-featured application platform. But complex application development requires structure, and the jQuery model was simply not structured enough for this purpose. The release of the first frontend frameworks such as Knockout and Backbone.js, soon followed by AngularJS, Ember.js and React, opened the era of the Single-Page Application model (SPA) with client-side routing, as an alternative to traditional Multi-Page-Applications (MPA) with server-side routing.

As the web standards gained in maturity and adoption, developers and users started to revolt against the still-dominant Microsoft Internet Explorer. The Acid3 test, implicitly aimed at IE, became the de-facto standard for feature comparison and standards adoption between browsers. When Google launched their own browser Chrome in 2008, IE had 70% of the browser market share. Four years later, this share had dropped to 35% while Chrome finally took the lead in the browser race. Browser vendors stopped distributing their software with strict versioning schemes in favor of auto-updates that kept them in "Evergreen" state with the latest web features and security fixes. Soon browser competition would drive innovation again.

The rise of the rich-client model drove an opposite movement on the server-side. As the frontend responsibilities increased, the backend responsibilities shrank to become more API-centric. The full-stack Renaissance Web model was no longer fashionable, and frontend and backend technology stacks started to diverge. NoSQL databases became viable alternatives to traditional SQL relational databases thanks to their more flexible model and their native support for JSON.

Launched in 2009, the first version of Node.js (re)introduced JavaScript as a general-purpose language for server environments (earlier server software such as Netscape-Enterprise-Server had this capability). Based on the same V8 engine as the Chrome browser, this was the first time since the beginnings of the Web that the same runtime environment was widely and consistently available on both client- and server-sides, with tools like Browserify and webpack bridging the gap and turning JavaScript from a simple client-side scripting language to a full-stack development environment. The Node Package Manager (npm) soon grew as the de facto dependency manager and distribution network for the JavaScript ecosystem. In a strange inversion of History, JavaScript had become a server-side language used to produce client-side and full-stack Web applications.

Milestones:

REST (c. 2000)
JSON (2002)
Chromium V8 (2008)
ECMAScript 5 (2009)
Node.js (2009)
npm (2010)
ECMAScript 5.1 (2011)
Evergreen Browsers (2013)

Emblematic software:

The Modernist Web model

The Modernist Web is a complete reversal of the Classical and Post-Classical Web development models, shifting the complexity from the backend to the frontend. The Modernist Web relies on powerful but complex toolchains and frameworks that provide the technical foundations for the development of applications with strict separation of concerns at every level.

The typical Modernist Web client is a self-contained SPA that communicates with an API server using authenticated JSON-based protocols. Client-side scripting is no longer optional but an essential runtime environment for the frontend, to the point that the main page is often an empty HTML page with framework bootstrap script. UI generation, routing, web service orchestration, state management, etc., are the responsibilities of the frontend. The client code is asynchronous and uses template data-binding. Applications target Evergreen Browsers and the newest Web standards, with polyfills for older clients. Web assets served to the clients are no longer authored directly by frontend developers, but are instead produced from source files by an elaborate build process that involves configuration, transpilation, minification, and bundling.

With the shift from Server-Side Rendering (SSR) to Client-Side Rendering (CSR), the backend becomes an API server whose main responsibilities are data management and business rules, In the simplest cases, backends are thin CRUD layers over a data storage engine, an architectural pattern known as "Thin Server Architecture". Low-traffic applications continue to use traditional server technologies, high-traffic applications (such as mobile consumer applications) often adopt stateless event-driven models for scalability.

Core value: separation of concerns

Key features:

Node.js-based ecosystem and toolchains
Frontend MVC frameworks
Single-Page Applications with client-side routing and rendering
Stateless web service protocols
UX-centric, responsive frontend
API-centric backends
CRUD or NoSQL databases

The First Age of Web Development

Frédéric Bonnet — Fri, 01 Jan 2021 21:36:29 +0000

Cover image: A sketch of primate origins from Charles Darwin's notebook, dated 21 April 1868

The First Age of web development spans from the invention of the web in 1990 to the First Browser War and the domination of Microsoft Internet Explorer in 1998.

The Early Days

In the beginning, the Internet was just a bunch of institutional servers with various single-purpose protocols, FTP and Gopher being among the most popular ones. Then on November 12, 1990, Tim Berners-Lee and Robert Cailliau wrote the proposal that started the Web revolution. Their vision was articulated around a system of hypermedia pages (HTML) linked together by globally unique identifiers (URI) and communicating with a universal protocol (HTTP). The first web browser, aptly named WorldWideWeb, was both a client and a WYSIWYG editor, following its creators’ vision of hypermedia systems as complete authoring tools. The Web was born. And incredibly enough, 30 years after its inception, not only does it still work with the same design principles, but it managed to retain compatibility all along. The greatest testament of its universality is that the very first page ever written is still online and accessible by today’s web clients.

Milestones:

HTTP 0.9 (1991)
HTML "1.0" (c. 1991)
URL (1991-1994)

Emblematic software:

The Early Web model

The Early Web is simple and "pure". Web sites are just a bunch of static hypertext pages written in plain HTML. Web servers are mostly filesystem gateways, serving plain HTML files to web clients. Anyone can write a web page with a text editor. Anyone can access web pages from anywhere using either line-mode or graphical "browsers". The web is simple and accessible for both content producers and consumers. No coding skills are required. Life is easy.

Core value: minimalism

Key features:

Pure hypertext content
Semantic markup
Static pages
Static servers

The Classical Period

The Early Web era was simple but austere. Content was institutional and academic. But soon, people began to create their own content to express their personal interests outside of the workplace. And hence began the era of the Personal Home Pages (an acronym that gave birth to the PHP language) that would soon spread across the web and outnumber the institutional pages with new user-created content. Graphical browsers started to take off and began driving the evolution of the web to fulfil the thirst for richer content. Mosaic then Netscape started introducing new HTML elements to display images and bring color to the black-gray-blue pages of the Early Web. It was the age of the "Best viewed with Netscape" banners. In the meantime, Web servers became more complex and started offering the possibility to execute code on the server-side to produce dynamic content.

Milestones:

HTTP/1.0 (1995)
HTML 2.0 (1995-1997): tables, images, image maps, POST-based form submission with file uploads
HTTP/1.1 (1997-1999)
Proprietary extensions for visual markup
CGI (1997)

Emblematic software:

The Classical Web model

The Classical Web makes rich content creation accessible. Web pages are written with a simple text editor, previewed locally on the user’s browser of choice, and then transferred to a hosting service using FTP. Static content is still easy to produce, but nice-looking pages require some design skills, and dynamic content requires basic coding skills with template engine syntaxes. Web servers can execute CGI shell scripts or template engines that generate dynamic content to the clients. Server-side technologies are the realm of software developers, whose goal is to keep the life of content creators as simple as possible.

Core value: simplicity

Key features:

Rich hypermedia content
Presentational markup
Dynamic page templates
Server-side page generation
Stateless server-side engines

The Post-Classical Period

The Classical Web introduced dynamic server-generated content, however web pages were still static, non-interactive documents. At this time, people started to envision a future for the web as a universal operating system/application platform. Rich hypermedia documents had to become interactive applications. To accomplish this goal, the web platform needed a scripting language on the frontend. In 1995, the release of Netscape Navigator 2.0 introduced Livescript, soon to be renamed JavaScript, and people began to inject life to their home pages, such as collapsable table of contents, event handlers or alert boxes. One year later Microsoft released Internet Explorer 3.0 with its own JScript implementation and limited support for the new CSS1 standard. Those were the days of intense competition and unleashed innovation on the browser market.

In 1995, the same year as Javascript, Sun Microsystem introduced the Java Language. Sun had their own vision of what distributed computing should be: Java everywhere, from mobile terminals to desktop applications and mainframe servers. The "write once, run anywhere" promise was a direct competitor to the emerging universal web platform. On the client-side, the HotJava browser and its Java Applets provided a viable, mature and consistent alternative to dynamic web pages for online distribution of desktop-like applications (to the point that Netscape stole the name for their own LiveScript language). On the server-side, the Java Web Server and its Servlets opened the era of Web application servers.

Milestones:

JavaScript (1995)
CSS Level 1 (1996)
ECMA-262 (1997)
DOM Level 0 (1995-1997)
Java Applets (1996)
Java Servlets (1996)
XML (1998)
Acid1 (1999)

Emblematic software:

Netscape Navigator 2.0-3.0
Microsoft Internet Explorer 3.0
Microsoft Internet Information Server with ASP
Sun HotJava Browser
Sun Java Web Server

The Post-Classical Web model

The Post-Classical Web is a universal application platform. Visually speaking, web pages mimic regular desktop applications. They don’t display content but application state, and only provide basic interactivity whereas the application logic is implemented in full-featured languages on the server-side. Web pages live in the presentation layer of a classic 2- or 3-tier distributed application. The Post-Classical Web is the first model where the frontend/backend dichotomy starts to make sense; the frontend is a web designer’s job whereas the backend is a software developer’s job.

Core value: interactivity

Key features:

Dynamic pages with HTML event handlers
Stateful application servers
Backend frameworks

From Classicism to Metamodernism — A Short History of Web Development

Frédéric Bonnet — Fri, 01 Jan 2021 21:35:55 +0000

Cover image: A sketch of primate origins from Charles Darwin's notebook, dated 21 April 1868

This series of articles is not yet another "Stop using/doing XXX", "Why you should use/do YYY", "ZZZ considered harmful" rant/injunction. It is my personal and imperfect attempt at defining a periodization of web development trends in a way that mimics artistic eras and intellectual movements. It is not a glorification of the "good old days", a lament on the Paradise Lost, or a moral judgement on each school of thought. On the contrary, I see the web ecosystem as a successful example of natural evolution, and its corollary natural selection, where different strategies coexist, compete and cooperate to survive, bloom, die, and be born again.

Near the end I will try to expose my vision on how the current trends in web development are shaping a new movement that I call "the Metamodernist Web".

A rough timeline of web development trends

The history of ideas is a perpetual cycle of inception, development, decadence, oblivion, enlightenment, rediscovery and reinvention, each new trend reacting to its predecessors by rejecting or embracing existing ideas and introducing new ones. The web is no different. Actually, many of the periods overlap, most trends still cohabit and confront nowadays, and contemporary technologies may belong to or span several older trends. We, as web developers, are standing on the shoulders of giants. In the following parts, I will use the past tense for historical references, and the present tense to describe the core features of each trend so as not to give a false feeling of chronology, let alone progress which is a highly subjective matter.

My periodization of web development history uses a classic three-age system, each being divided into several periods. Like all periodizations, this is highly subjective, and there is no clear beginning or end date :

The First Age: Early Days, Classical period, Post-Classical period
The Second Age: First Browser War, Dark Ages, Renaissance period, Modernist period
The Third Age: Second Browser War, Postmodernist period, Neoclassical period, Metamodernist period