So, it’s 2019, 30 years after Tim Berners-Lee first created HTTP, and we’ve finally hit peak web dev.

Long gone are the simple text pages, even the more complex grid-based systems are gone now. Everyone knows the only real way to lay out websites is a single column of text in the middle of the screen, surrounded by whitespace. Helpfully, there are at least 20 frameworks to ensure maximum readability in this column, and there are numerous articles on medium.com explaining why each one is “simply the only true way to develop a website”.

CSS is almost obsolete by now, we all use inline styles generated by JavaScript. It’s so much cleaner, and avoids having to load pesky .css files from disk.

We used to generate pages with PHP, back in the dark ages. Then we started using client-side JS frameworks to generate our front-ends. Over time, these got so advanced that they no longer needed to use the original DOM, they could virtualise it. This was all thrown out of the window with webserverJS, the webdev framework that took the world by storm.

We should have seen it coming, docker and virtual machines foretold of its coming.

The great WebServer.JS framework used a revolutionary system in which every single function had its own server, allowing for total non-blocking concurrency. A simple website might only need to call generateHTMLTag() and generateBodyTag() (each running on separate virtual instances), but a more complex website might make 4000 or 5000 HTTP calls per page request. It was magical. Everything just worked.

Suddenly websites began to load immediately, with absolutely no overhead generating a base website. It was said to be good practice to spread your Webserver.JS services far and wide to make sure it never died entirely. Yeah, bad network conditions in some obscure datacentre might mean your website might be missing that generateH1Tag() call, but 99% of the rest of the site loaded just fine!

Yes a man-in-the-middle attack could insert goatse into your HTML, that’s because Webserver.JS doesn’t validate anything for maximum speed. Would you sacrifice valuable milliseconds making sure everything was valid? That’s what we used to do, and if it’s old, it’s wrong.

The average lifecycle of frameworks these days is approaching 48 hours, HackerNews is alight with articles announcing new and improved frameworks, each with a more simplistic logo, but without fail using the hallowed .io TLD. Any framework that couldn’t afford a .io was instantly dismissed as behind the times. A .com? Get out of here grandpa.

Infrastructure as a service (IaaS) became mandatory, handling anywhere up to 10,000 servers is no small task. But, despite the massive task of co-ordinating all of these servers, a JS framework appeared that span up virtual servers on-demand, leading to some companies controlling millions of virtualised servers at peak load to keep up with the billions of HTTP requests being generated by their websites.

I can’t wait to see how many more webservers we can jam into data centres in the coming 30 years. Maybe by 2049 every variable will be stored in its own server, ready to be called at any moment, without the damn overhead of accessing main memory!

Here’s to 30 years of HTTP!