The web didn’t start with a blank canvas. Every time you crack open a code editor, you’re stacking your work on top of choices made by people who, in many cases, are long dead. Those choices weren’t neutral. They baked in assumptions about who holds power, who gets access, and who controls the pipes. If you don’t know what those assumptions are, you’ll end up repeating them. Worse, you’ll think you came up with them yourself.
I get tired of seeing designers and developers act like the web began with React. It didn’t. The web has a history, and that history is political. The way data moves, who can publish, what a browser does with markup—these aren’t just engineering puzzles. They’re questions about who gets a voice and who gets silenced.
The Web Was Born from a Document Culture, Not an App Store
Tim Berners-Lee wasn’t dreaming of SaaS subscriptions. He wanted to link research papers. The first browser was also an editor. The web was read-write from the start. That’s not trivia. It means the whole architecture—HTTP, HTML, URLs—was built to share and connect documents, not to run remote code.
When you treat a web page as an app shell that pulls JSON and renders on the client, you’re working against that architecture. You break deep links. You hide content from search crawlers unless you bolt on server-side rendering. You force users to download and execute JavaScript just to read a paragraph. That’s not innovation. That’s a misunderstanding of the medium.
The early web was also simple on purpose. HTML was small enough to learn in a few hours. That wasn’t a limitation. It was an invitation. Anyone with a text editor and a modem could publish. Now, the barrier is a towering stack of build tools, frameworks, and dependencies. We’ve turned web development into a profession that locks out amateurs. That’s a political outcome, not a technical one.
The Browser Wars Were About Control, Not Features
In the 1990s, Netscape and Microsoft fought for dominance. The weapons weren’t better user experiences. They were proprietary HTML tags. <blink>. <marquee>. ActiveX. Each company wanted to make sites that only worked in their browser. The goal wasn’t a better web. It was a captive audience.
We see the same playbook today. Google’s Chrome dominates. They push features that feed their advertising machine. AMP was a perfect example—a format that looked like the web but lived on Google’s servers, giving them even more control over traffic and monetization. Developers adopted it because it was fast and boosted visibility. The trade-off was handing over more of the web’s infrastructure to a single corporation.
Knowing this history makes you skeptical. When a browser vendor proposes a new API, you ask: who benefits? Does this spread power or concentrate it? The web was meant to be decentralized. Every layer of complexity and centralization we add is a step away from that original promise.
The Web Is a Socially Constructed Technology
Technologies don’t evolve in a vacuum. They’re shaped by the people who build them and the economic systems they live in. The web’s shift from documents to apps wasn’t some natural progression. It was driven by venture capital, by the hunger to monetize attention, by the push to turn a public library into a shopping mall.
Take the hyperlink. It’s the web’s basic building block. It’s also a gesture of trust. When you link to something, you’re saying: this is worth your time. Google’s PageRank turned links into currency. That made the web more navigable, sure. But it also spawned an industry of link farming, SEO manipulation, and content mills. The link stopped being a social gesture and became a financial instrument.
Now think about what we’re building today. Web3. The fediverse. New protocols. Are we designing for community or for extraction? Are we building tools for people or platforms for rent-seeking? The web’s history shows these questions are never just technical. They’re always about power.
Accessibility Is a Legacy of the Web’s Early Choices
HTML was designed to work on any device. A heading is a heading whether you see it on a screen, read it on a text terminal, or hear it through a screen reader. That was intentional. It meant the web could serve blind users, people on slow modems, anyone with a device that could parse text.
Modern web development often trashes this. We build <div> soups with no semantic structure. We make basic navigation depend on JavaScript. We craft experiences that look gorgeous on a MacBook Pro and fall apart everywhere else. This isn’t just sloppy work. It’s exclusion. It says: this web isn’t for you if you can’t afford the latest hardware, if you have a disability, if your internet is slow.
The early web was inclusive by default. You had to go out of your way to make it exclusive. Now, inclusion takes extra effort. That’s a design failure, and it comes from not knowing where the web started.
Infrastructure Encodes Values
The web’s infrastructure—DNS, ISPs, hosting providers—isn’t neutral. It’s a stack of power relationships. Who controls the domain name system? Who can cut off your access? Who logs your traffic? These are political questions dressed up as technical ones.
When you design a web application, you make infrastructure choices. Do you host on AWS, feeding a single corporation’s monopoly? Do you use a CDN that logs every user request? Do you embed third-party scripts that track your visitors without their knowledge? These aren’t just performance or convenience decisions. They’re decisions about who holds power over your users’ data.
The early web ran on open protocols—TCP/IP, HTTP, SMTP. Anyone could implement them. No permission needed. That openness is what let the web explode. Today, we’re layering proprietary platforms on top of those open protocols. We’re building walled gardens on public land. The history of the web reminds us that this is a choice, not a force of nature.
What We Lost When We Got “Rich Experiences”
The web used to be a place where you could View Source and learn how something was built. It was a giant, distributed classroom. You could see the HTML, the CSS, the JavaScript. You could copy, tweak, and play. That’s how a generation of developers taught themselves.
Today, View Source is a joke. The markup is generated by frameworks. The CSS is minified and hashed. The JavaScript is a webpack blob. The web is no longer legible. We traded learnability for performance, and we never asked if the trade was worth it.
This has consequences. It raises the barrier for new developers. It concentrates knowledge in the hands of people who can afford bootcamps or CS degrees. It turns the web into a consumer product instead of a creative medium. The web was supposed to be a place where anyone could write, not just read. We’re losing that.
Designing for the Future Requires Historical Consciousness
If you don’t know where the web came from, you can’t know where it should go. You’ll mistake temporary trends for permanent truths. You’ll optimize for the wrong things. You’ll build fragile systems that break when the next framework arrives.
Historical consciousness means understanding that every technical decision is a trade-off. It means asking: what are we gaining, and what are we losing? It means resisting the hype cycle. It means valuing longevity over novelty. It means building for humans, not for algorithms.
The web is not a product. It’s a commons. It belongs to all of us. But it will only stay a commons if we understand its history and fight to protect its principles. Those principles are openness, accessibility, decentralization, and simplicity. They’re not outdated. They’re the foundation. Build on them, or watch what you build crumble.
Frequently Asked Questions
Why does the history of the web matter for modern developers?
Because the web’s architecture was shaped by specific decisions about openness, accessibility, and decentralization. Ignoring those decisions leads to building systems that break fundamental web functionality—like linking, bookmarking, and working across devices. Understanding the history helps you make informed trade-offs rather than blindly following trends.
How did the web go from documents to applications?
The shift was gradual and driven by economic incentives. Early web pages were static documents. JavaScript added interactivity. AJAX allowed asynchronous data loading. Then frameworks like Angular and React abstracted the page into a client-side application. Each step was sold as progress, but it also increased complexity and centralized control in the hands of a few large platforms.
What can I do to build a web that respects its origins?
Start with semantic HTML. Ensure your content is accessible without JavaScript. Use progressive enhancement. Choose open protocols and formats. Host on infrastructure that respects user privacy. Question whether every new framework or API actually serves your users or just adds complexity. Small, deliberate choices add up.