We Broke the Web. Now Comes the Rollback-olution™

The Web has gone through so many self-imposed revolutions, it looks a lot more like a badly managed startup. Pivoting perpetually. Forever rewriting its mission statement. But as a side-effect, it tends to generate buzzwords. A ton of them. So here's another one:

WebO+

But let’s start at the beginning. We had Web1.0 - which wasn’t a term that was ever actually coined - but was known as the read-only web. Then Web2.0 came with all its interactivity and API-driven web apps. And finally, we met Web3. What’s next?

I’d say that after 25 years of (re)inventing complexity, we don’t need Web4. We just need to fix Web2.0. But before we talk about the fix, let’s talk about how we broke it.

The Web. What Went Wrong?

It began as a beautifully simple thing. Somewhere out there, there was a computer that held a ton of webpages. And then, there were tons of computers - with tons of webpages - ready to serve any one who requested them.

You would pick your favorite browser application (probably Netscape) and fire it up. And then you’d be greeted with AltaVista (depending on the year, it might even be Yahoo) and then you’d type in a search and Boom!

But it wasn’t just a tool. It was a cultural moment. This old Yahoo! ad captures the vibe perfectly.

This was one of my absolute favourites ads at the time!

But something wasn’t right. The web was… boring. Sure, you could read stuff. But why couldn’t we have the same interactivity we had in games? Why couldn’t the Web feel alive?

And why not? That’s when Web2.0 was born.

Web2.0: The Social & API-Driven Web (Mid-2000s – 2020s)

Suddenly, web pages transformed from regular Wikipedia looking articles to full blown Web Applications.

The term Web Application actually felt triumphant. No serious programmer at the time thought much about Web Developers. No one would dare call us Engineers. Very few even wanted to call us Programmers. You could almost hear them mutter under their breath:

“What? JavaScript? PHP? Ewww…”

Many thought we were “Java” fan boys and girls. Meanwhile, some of us made their salaries look cute.

Then came the Buzzword Bonanza™ - AJAX, JSONP, OAuth. Suddenly, the FrontEnd Engineer (oops, developer) was born. And just like that, frameworks exploded. Your Yahoo! wasn’t Yahoo anymore - literally.

You could suddenly do more. You could talk! Err… chat! And guess what else?

You could totally click on a Button and you wouldn’t have to wait a week for the page to reload!

And it didn’t stop there. Buttons changed color, shapes moved, hover effects responded before you even clicked. The web came alive. Stuff glowed. Things got bolder. Move your mouse, and… something popped out!

Oh, and in case you were wondering, yes, that’s totally where popups came from. At least until we invented pop-up blockers to fight back.

It was a game changer: Skeuomorphic design, Zoomable User Interfaces (remember this?) and of course, the rise of Social Media.

The web became Live. Fun. Interactive.

But beyond the flashy buttons, glowing elements and real-time interactions, something bigger was happening…

Browsers weren’t just rendering cool effects; they were offloading serious computation from our servers to our users’ machines. Instead of relying on expensive, multi-core, memory-filled servers, we realized that every single user already had compute power at their fingertips.

We went from the browser rendering pages to the browser rendering entire applications, full-blown, desktop-grade software. The browser became the new runtime; an OS inside an OS, shouldering the burden once meant for the backend.

At this point, people were finally calling us Engineers. Well… no. We were calling ourselves Engineers. And loudly. And no one was arguing with us.

It was a brilliant move.

Until it wasn’t.

SEO took a NoseDive

Turns out, search engines didn’t sign up for this full-stack revolution. Google could read JavaScript, sure. But understand it? Not so much. Beyond that, performance tanked. I’m sure you’re saying, “But wait. No it didn’t!”. It did, but you probably didn’t feel it because we were graciously met with so much more compute power, much more than we ever did before

Developers were shipping megabytes of JavaScript just to render something as simple as a list. What once took a single HTML file now required hydration, client-side loops, and API calls. It suddenly took tons of JS to make anything functional. In turn, that created new problems. Latency suffered. We had to figure out how to pre-render out static pages (remember PhantomJS anybody?).

Then came React.

Then came the first hydration issues.

Then came Hydra. Cut off one head, two shall take its place… Sorry. Hydration Hell.

And if that wasn’t enough, something even worse was happening behind the scenes. While we were drowning in hydration hell, large organisations were quietly harvesting our data - and selling it. How? They made shiny cool things we could use for free and made us accept terms no one bothered to read.

The cracks weren’t just showing, they were splitting wide open. The web had become a bloated, exploitative mess, and no one knew where to start fixing it.. We needed something new…

Web3. The Decentralized, Crypto-Powered Web (2020s – Now)

Notice something? We got cooler. We dropped the .0. Just Web3. Clean. Minimalist. Sleek.

Oh dear God, no. Not even close.

At least we got new buzzwords! Blockchain. Crypto. Smart Contracts. Decentralization. Tokens. Mining. NFTs. You get the idea. Web3 came in hot, promising to fix the internet by removing central control and letting users own their data. And in many ways, it delivered - for finance, supply chains, trustless transactions and so much more.

But that didn’t actually fix any of our Web2.0 architectural problems, no sir. In fact, people started slapping blockchain on everything. Suddenly, blogs needed tokens, APIs required smart contracts and even basic web apps were being rebuilt with decentralized infrastructure. So instead, it just added more to account for.

At this point, we had truly outdone ourselves. In pushing the boundaries of technology, we didn’t just innovate,we over-engineered everything. And in the process, we gave an old word a brand-new meaning:

Overkill.

But. Finally. After years of over-complication, we hit The Great Reset.

WebO+. The ultimate Rollback-olution™ (2020s – Now)

It’s absurd how we’ve come full circle. We began with server-side rendering because that’s all we had. Then JavaScript evolved, and we pushed more work onto the client. Then came Internet Explorer, which we shall not speak of. Eventually, we decided that sending full HTML pages was too expensive - so we switched to sending JSON. Then, JSON was too big, so we optimized it with better compression. Then, in our pursuit of the ‘pristine’ server, we decided it should only speak one language - JSON (or protobuf) - while the client handled the heavy lifting.

Then reality struck. We still needed server-side rendering for SEO, accessibility and performance. But instead of admitting the mistake, we Frankenstein’d a solution - client-based SSR. And after years of jumping through hoops, we arrived back where we started: Server-side Rendering.

The simple truth hit us: The original web had it right all along. We didn’t need a new paradigm. We needed to stop over-engineering everything.

WebO+ isn’t about going backwards - it’s about correcting 25 years of misdirection. It takes the best parts of Web1, Web2, and Web3 and cuts out the nonsense.

WebO+ is what Web1 would have been, if we had today’s hardware, compression, and smarter rendering.

What it does right.

Now this is assuming you still need a server to make API calls and you’re not generating static pages and serving them out of CDN.

For starters, we’re back to the early 2000s where server-rendered, SEO-friendly pagination still matters, even though client-side tricks like pull-to-refresh make browsing smoother.

But now, servers are more powerful, and compression is faster than ever. Instead of juggling JSON responses and complex client-side loops, the server just sends fully rendered HTML, and the browser drops it straight into the DOM. No extra processing, no unnecessary hydration, just fast, direct rendering.

Yes, you can still use JS/TS on the backend, and yes, you can still reuse the same logic for both server-side and client-side rendering. But some tasks like click handlers and state changes must stay client-side.

The difference? You don’t need to structure two separate component types anymore. Just sprinkle in client-side functionality where needed.

Some frameworks, like Svelte, go further by allowing client-side logic within the same file, making the distinction seamless.

And it’s not just Svelte. SSR is back across the board. Frameworks like Laravel, Next, Nuxt and SvelteKit have brought server rendering back into the mainstream, making it practical again: lean servers, fully rendered pages, instant loads.

React now embraces SSR with Next.js and React Server Components (RSC), though hydration issues still make it more complex than traditional SSR.

A Small Aside, What Inspired this Article?

You see, I saw a video called “Next.js Best Practices You can’t ignore” and the first thing the author said was something along the lines of “Dude, are you using Page Router? Stop. Use App Router.” but he didn’t do much of a job elaborating. So curiously, I asked ChatGPT about it and this is the gist of what I got back:

“Oh, App Router is like how we built websites in the late 90s and early 2000s.”

And then. Something inside me broke.

So I forced my partner to sit down and listen to me rant. I went on and on and finally ended with telling her what I would say to Devs at the time:

It doesn’t matter if the server-side code is pristine gold if your client-side code looks like Medusa just woke up from a freggin’ hangover.

She laughs. That’s something I guess. And the ranting made me feel better so before I go, there are some more things that need to be said.

Frontend Development pushed browsers so damn far that they became full-fledged operating systems. _Chromebook anyone?_

It pushed GPUs to their limits. It pushed JS engines to the point where V8 became so powerful that it didn’t just optimize web performance - it gave birth to entire server-side ecosystems like Node.js & Deno. (Yep. The same dude started both)

Meanwhile, server-side computing kept getting stronger. But most of these BFFs were just sitting there, idling. So the push came from the frontend: “Wake up, server. We need you to do more.”

We’re finally waking up to the fact that frontend wasn’t supposed to be doing all the heavy lifting.

Finally. We are shifting back. So I’d say…

• Goodbye hydration hell.

• Goodbye unnecessary client-side API calls.

• Goodbye shipping 5MB of JavaScript just show a list of blog posts.

And then I'll say…

• Welcome back, server-rendered HTML.

• Welcome back, pre-rendered content.

• Welcome back universal UIs

🔥 Welcome to WebO+.

(And if you haven’t figured it out by now, that’s Web Original Plus™. Just another buzzword? Maybe. But this time, it actually means something.)