The Third Age of Web Development
Tags: webdev, javascript, frontend
Published: 2021-01-01 21:36:57

---
title: The Third Age of Web Development
series: From Classicism to Metamodernism — A Short History of Web Development
published: true
description: This article covers the Third Age of Web Development, from the end of the Second Browser War to present days
tags: webdev, javascript, frontend
cover_image: https://i.pinimg.com/originals/4f/8b/ed/4f8beddce0eb03808a88045f752e23a0.jpg
---

_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][second-browser-war], after Microsoft Internet Explorer lost its dominance on the web browser market (2012-today).

[second-browser-war]: https://en.wikipedia.org/wiki/Browser_wars#Second_Browser_War_(2004%E2%80%932017)

## The Postmodernist Period and the Second Browser War

The transition between the [Modernist][modernist-period] 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][angular], 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][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][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][safari], 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)][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)][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][angular-universal] is SSR for [Angular] components), and reinvented techniques that had been available since the dawn of the Web: [lazy loading][lazy-loading] and [code splitting][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][microservices] 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][js-fatigue]".

Milestones:

- iOS [Safari][safari] (2007)
- [OAuth 2.0][oauth2.0] (2012)
- [Babel][babel] (2014)
- [ECMAScript 6][es6]-[11][es11] (2015-2020)
- [JSON Web Token][jwt] (2015)

Emblematic software:

- [Angular]
- [React]
- [Vue.js]
- [Redux]
- [GraphQL]
- [Google Lighthouse][lighthouse]
- [Spring Boot][spring-boot]
- [Redis]
- [Firebase]
- [Amazon Web Services][aws]
- [Google Cloud Platform][gcp]
- [Microsoft Azure][azure]
- [Docker]
- [Kubernetes]
- [Visual Studio Code][vscode]
- [IntelliJ]

### 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)][tti], especially on low-end devices, by implementing techniques such as [Ahead-of-Time compilation (AoT)][aot]. Application code uses non-imperative paradigms such as [functional][functional-programming] and [reactive][reactive-programming] 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][lazy-loading] and [code splitting][code-splitting] help further reduce initial page load times. [Service workers][service-worker] help download and cache assets in the background for offline use.

On the server side, Postmodernist Web frameworks reintroduce some of the [Classical Web][classical-period] techniques for better [SEO] and discoverability, such as [Server-Side Rendering (SSR)][ssr]. Many responsibilities of traditional web servers are delegated to separate services: [Content Delivery Networks (CDNs)][cdn] for static web assets, [Single Sign-On servers (SSO)][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

<!-- References -->

[classical-period]: https://dev.to/fredericbonnet/the-first-age-of-web-development-4elo#the-classical-period
[modernist-period]: https://dev.to/fredericbonnet/the-second-age-of-web-development-2k1a#the-modernist-period
[spa]: https://en.wikipedia.org/wiki/Single-page_application
[graceful-degradation]: https://en.wikipedia.org/wiki/Graceful_degradation
[angularjs]: https://en.wikipedia.org/wiki/AngularJS
[angular]: https://en.wikipedia.org/wiki/Angular_(web_framework)
[typescript]: https://en.wikipedia.org/wiki/TypeScript
[react]: https://en.wikipedia.org/wiki/React_(web_framework)
[react-hooks]: https://reactjs.org/docs/hooks-intro.html
[vue.js]: https://en.wikipedia.org/wiki/Vue.js
[babel]: https://en.wikipedia.org/wiki/Babel_(transcompiler)
[webkit]: https://en.wikipedia.org/wiki/WebKit
[safari]: https://en.wikipedia.org/wiki/Safari_(web_browser)
[mobilegeddon]: https://en.wikipedia.org/wiki/Mobilegeddon
[tti]: https://web.dev/interactive/
[ssr]: https://en.wikipedia.org/wiki/Server-side_scripting
[aot]: https://en.wikipedia.org/wiki/Ahead-of-time_compilation
[angular-universal]: https://angular.io/guide/universal
[lazy-loading]: https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading
[code-splitting]: https://developer.mozilla.org/en-US/docs/Glossary/Code_splitting
[microservices]: https://en.wikipedia.org/wiki/Microservices
[firefox]: https://en.wikipedia.org/wiki/Firefox
[opera]: https://en.wikipedia.org/wiki/Opera_(company)
[presto]: https://en.wikipedia.org/wiki/Presto_(browser_engine)
[blink]: https://en.wikipedia.org/wiki/Blink_(browser_engine)
[gecko]: https://en.wikipedia.org/wiki/Gecko_(software)
[oauth2.0]: https://oauth.net/2/
[es6]: https://www.ecma-international.org/ecma-262/6.0/
[es11]: https://www.ecma-international.org/ecma-262/11.0/
[jwt]: https://en.wikipedia.org/wiki/JSON_Web_Token
[redux]: https://en.wikipedia.org/wiki/Redux_(JavaScript_library)
[graphql]: https://en.wikipedia.org/wiki/GraphQL
[lighthouse]: https://en.wikipedia.org/wiki/Google_Lighthouse
[spring-boot]: https://en.wikipedia.org/wiki/Spring_Framework#Spring_Boot
[redis]: https://en.wikipedia.org/wiki/Redis
[firebase]: https://en.wikipedia.org/wiki/Firebase
[aws]: https://fr.wikipedia.org/wiki/Amazon_Web_Services
[gcp]: https://en.wikipedia.org/wiki/Google_Cloud_Platform
[azure]: https://en.wikipedia.org/wiki/Microsoft_Azure
[docker]: https://en.wikipedia.org/wiki/Docker_(software)
[kubernetes]: https://en.wikipedia.org/wiki/Kubernetes
[vscode]: https://en.wikipedia.org/wiki/Visual_Studio_Code
[intellij]: https://en.wikipedia.org/wiki/IntelliJ_IDEA
[js-fatigue]: https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4
[functional-programming]: https://en.wikipedia.org/wiki/Functional_programming
[reactive-programming]: https://en.wikipedia.org/wiki/Functional_reactive_programming
[service-worker]: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
[seo]: https://en.wikipedia.org/wiki/Search_engine_optimization
[cdn]: https://en.wikipedia.org/wiki/Content_delivery_network
[sso]: https://en.wikipedia.org/wiki/Single_sign-on

## 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][classical-period], the Neoclassical period is centered around content creation, whereas the [Modernist][modernist-period] 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][blogger] in 2003, the [Blogosphere] grew exponentially with hundreds of millions of blogs and millions of articles posted everyday. In parallel, [Content Management Systems (CMS)][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][js-fatigue] of the Modernist and Postmodernist Web, many web developers began to seek alternatives to the dominant [SPA model][spa] 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][graceful-degradation] 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][early-days], 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)][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)][faas], also known as [Serverless computing][serverless]. Opened in 2014, [AWS Lambda][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][rss] (2002)
- [Google Blogger service][gcp] (2003)
- [Markdown][markdown] (2004)
- [Jekyll][jekyll] (2008)
- [AWS Lambda][aws-lambda] (2014)

Emblematic software

- [WordPress]
- [Drupal]
- [Jekyll]
- [Hugo]
- [Gatsby]
- [GitHub]
- [AWS Lambda][aws-lambda]

### 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)][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)][cdn]. When needed, dynamic features can be added as client scripts, and backend logic can be implemented as [serverless functions][serverless] 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][spa], 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][jamstack].

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

<!-- References -->

[blogger]: https://en.wikipedia.org/wiki/Blogger_(service)
[blogosphere]: https://en.wikipedia.org/wiki/Blogosphere
[cms]: https://en.wikipedia.org/wiki/Content_management_system
[wordpress]: https://en.wikipedia.org/wiki/WordPress
[drupal]: https://en.wikipedia.org/wiki/Drupal
[jekyll]: https://en.wikipedia.org/wiki/Jekyll_(software)
[ssg]: https://en.wikipedia.org/wiki/Web_template_system#Static_site_generators
[markdown]: https://en.wikipedia.org/wiki/Markdown
[netlify]: https://en.wikipedia.org/wiki/Netlify
[hugo]: https://en.wikipedia.org/wiki/Hugo_(software)
[eleventy]: https://www.11ty.dev/
[gatsby]: https://www.gatsbyjs.com/
[next.js]: https://nextjs.org/
[vuepress]: https://vuepress.vuejs.org/
[github]: https://en.wikipedia.org/wiki/GitHub
[aws-lambda]: https://en.wikipedia.org/wiki/AWS_Lambda
[rss]: https://www.rssboard.org/rss-specification
[faas]: https://en.wikipedia.org/wiki/Function_as_a_service
[serverless]: https://en.wikipedia.org/wiki/Serverless_computing
[jamstack]: https://jamstack.org/
[early-days]: https://dev.to/fredericbonnet/the-first-age-of-web-development-4elo#the-early-days

## 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][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][modernist-period] 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][spa-polyfill]. New ECMAScript language features push the [Vanilla JS][vanilla-js] developer experience closer to transpiled languages such as TypeScript. [ECMAScript Module support (ESM)][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][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][micro-frontends] 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][service-worker] 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][progressive-enhancement] in mind. [Web App Manifests][web-manifest] 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)][pwa]. And with the support of [WebAssemby (Wasm)][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][modernist-period], 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)][hotwire], 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][progressive-enhancement] techniques to existing models.

Milestones:

- [Web Components][web-components] (2011)
- [asm.js][asm.js] (2013)
- [Polymer][polymer] (2013)
- [Service Workers][service-worker] (2014)
- [HTTP/2][http2] (2015)
- [WebAssembly][wasm] (2015)
- [ESM support in browsers][esm-browser] (2015)
- [PWA][pwa] (2015)

Emblematic software:

- [Snowpack]
- [unpkg]
- [cdnjs]
- [Svelte]
- [Polymer]
- [Ionic]
- [Stencil]
- [Hotwire]

### The Metamodernist Web model

[Progressive Enhancement][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][service-worker] is an ideal place to implement [non-essential features and performance enhancements][every-site-deserves-a-service-worker] 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][evergreen-browsers]. 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][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

<!-- References -->

[dark-ages]: https://dev.to/fredericbonnet/the-second-age-of-web-development-2k1a#the-first-browser-war-and-the-dark-ages
[evergreen-browsers]: https://yeti.co/blog/evergreen-web-browser-a-web-browser-that-automatically-updates-itself/
[spa-polyfill]: https://itnext.io/your-single-page-app-is-now-a-polyfill-7881fb01694e
[every-site-deserves-a-service-worker]: https://blog.logrocket.com/every-website-deserves-a-service-worker/
[vanilla-js]: http://vanilla-js.com/
[esm]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
[npm]: https://en.wikipedia.org/wiki/Npm_(software)ications.
[snowpack]: https://www.snowpack.dev/
[skypack]: https://www.skypack.dev/
[unpkg]: https://unpkg.com/
[cdnjs]: https://cdnjs.com/
[web-components]: https://en.wikipedia.org/wiki/Web_Components
[polymer]: https://en.wikipedia.org/wiki/Polymer_(library)
[ionic]: https://en.wikipedia.org/wiki/Ionic_(mobile_app_framework)
[micro-frontends]: https://martinfowler.com/articles/micro-frontends.html
[web-manifest]: https://developer.mozilla.org/en-US/docs/Web/Manifest
[progressive-enhancement]: https://en.wikipedia.org/wiki/Progressive_enhancement
[pwa]: https://en.wikipedia.org/wiki/Progressive_web_application
[wasm]: https://en.wikipedia.org/wiki/WebAssembly
[svelte]: https://en.wikipedia.org/wiki/Svelte
[basecamp]: https://en.wikipedia.org/wiki/Basecamp_(company)
[hotwire]: https://hotwire.dev/
[stencil]: https://stenciljs.com/
[asm.js]: https://en.wikipedia.org/wiki/Asm.js
[http2]: https://tools.ietf.org/html/rfc7540
[esm-browser]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules

# 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!_