Introduction
In this 4-part series, I’ll explore how the web has evolved — where it began, what changed, and where it's heading next. This first part takes us to the very beginning: how the web originally worked.
The Foundations of the Early Web
The earliest versions of the web were built using a few core technologies:
- HTTP for communication
- HTML for structure
- CSS for styling
- JavaScript for light interactivity
But the two most essential building blocks were:
- <a> (anchor) tags for navigation
- <form> elements for interaction
That’s it. No client-side routing, no hydration, no JavaScript rendering. Everything was powered by server responses.
What the Backend Used to Handle
Web apps in this era followed a simple cycle:
1. Persistence
All application data was stored in a database (like MySQL, PostgreSQL). The backend was responsible for reading and writing to it.
2. Routing
When a user clicked a link or submitted a form, the browser sent an HTTP request. The server routed it to the correct handler.
3. Data Fetching
The server read from the database and prepared the required information for rendering.
4. Data Mutation
For actions like creating, updating, or deleting records — the server would mutate the database directly.
5. Rendering
The server returned fully-rendered HTML to the browser. Templates were often generated using tools like PHP, ASP, or templating engines like ERB (Rails).
6. Logic
Most application logic — conditionals, permissions, validations — ran on the server.
7. UI Feedback
Feedback was baked into server-rendered pages: alerts, success messages, or errors appeared after a form was submitted and the page was refreshed.
Example: A Classic Login Flow
Here’s how login worked in that original model:
- User visits /login — the server sends back an HTML page.
- They fill in credentials and submit the form.
- The form posts to /authenticate.
- The server checks credentials, sets a session, and redirects to /dashboard.
- The browser makes another full request — and the server returns a new HTML page.
No JavaScript. No frontend state management. No JSON.
The Simplicity Was the Strength
While limited by today’s standards, this architecture had real advantages:
- Predictable flow: Everything was linear.
- Accessibility & SEO: Built-in.
- Progressive enhancement: The baseline just worked — even without JavaScript.
- Fast initial loads: No need to download JS bundles or wait for hydration.
But it also had limitations:
- Full-page reloads were slow and jarring.
- No rich interactivity like instant validation or partial updates.
- Developer ergonomics weren’t great for more dynamic apps.
Summary
So in this early stage of the web, everything — from routing to rendering to persistence — was handled by the backend. The browser’s job was just to render and submit. It was a page-to-page world.
Why This Matters
You might wonder — why are we looking back at something so old and basic?
Because understanding where we came from helps us see the bigger picture of where we’re headed.
Today, we work with frameworks, component libraries, client-side routing, hydration, and partial reactivity — but beneath it all, the core responsibilities haven’t changed:
- Reading and mutating data
- Navigating between screens
- Rendering UI
- Providing feedback
What has changed is where these responsibilities live — backend, frontend, or both.
By understanding how the earliest web apps delegated responsibility almost entirely to the server, we can better appreciate the architectural shifts that came after. And as we’ll see in later parts, the future of the web might actually be a thoughtful return to some of these principles — but modernized and enhanced.
This journey is about clarity. Once we understand the transitions the web has gone through, we can make smarter choices about the tools we use today and the architectures we build for tomorrow.
What Next
In Part 2, we’ll see how this model started to shift — with JavaScript taking on a bigger role, and the first signs of client-side interactivity redefining user expectations.
If you found this post helpful, consider supporting my work — it means a lot.
