Version labels are useful only when they preserve the history of the platform they describe. This note separates the browser-application milestones from the later blockchain marketing use of "web3."

The practical issue is category hygiene: AJAX, WebSockets, local storage, HTML5, CSS3, and structured client applications changed what the web could do before the blockchain label became popular.

Web-platform noteOriginally posted 2021-10-27; expanded here around browser capability and naming.

Article focus: AJAX, post-jQuery client applications, local navigation, WebSockets, localStorage, HTML5, CSS3, and web-version naming.

The Browser Milestone

The older Web 2.0 label fits the AJAX shift: pages could update without full document reloads, and browser applications could begin to feel interactive rather than purely document-driven.

The next practical shift was the structured client application: Node.js-era tooling, Backbone/Marionette, Flux-style application state, local navigation, WebSockets, localStorage, HTML5, and CSS3. Those pieces made the browser a durable application runtime, not only a request/response document viewer.

The Naming Problem

The later blockchain use of "web3" overloaded a term that could already describe a browser-platform generation. The objection is not that decentralized systems are uninteresting. The objection is that naming should not erase the platform work that already changed the web's execution model.

For builders, the useful distinction is concrete: what state lives locally, what updates in real time, what can navigate without server round trips, what persists across sessions, and what protocols actually move data between peers or servers.