Happy Birthday, WWW – 30 years of mining a landfill for valid code

Today the World Wide Web is 30 years old. I’ve worked on it since 1997 or so and I saw a lot of technologies and design trends come and go. I’ve also seen a lot of “this is much better and will replace the web” solutions come and go. What remained is the web with its “dumb” technologies HTTP, HTML and CSS. Each of them are forgiving in their nature. They allow developers to make mistakes without punishing the end user. Many people sing the praise of this approach and architecture, so I’m not going to repeat it.

Enter JavaScript. When I started with JavaScript, it was a fun thing to do as it prevented you from having to reload a document. You could validate a a form and tell people they forgot something. A much better experience than finding out after a few seconds of loading the document. And of course hoping people in the other room don’t pick up the phone and interrupt your modem connection.

JavaScript is fun to work with as a developer. You can generate HTML and CSS with it and you have full control over what you create. You can detect things like window size and if certain technologies are supported and create content accordingly. You can load things on demand and only when the user needs them. It feels great to be in control.

CSS and HTML, on the other hand, feel like you give away control and hope for the best that it will work. There is no feedback channel, you can’t set up an error trap. That’s on purpose and the main thing to learn as a web developer is that you aren’t in control, but your users are. The more flexible your solution is to cater to the needs of your user, the more successful it will be. “Survival of the fittest” isn’t about strength, but about adaptability.

JavaScript isn’t a web technology. It isn’t governed by the W3C but by ECMA. What works and doesn’t work in JavaScript is dependent on browser makers. What you can use in JavaScript is also dependent on the end user having a “modern” browser. “Modern” means nothing, by the way, and I wished we stopped using that term as it is fleeting.

Other things that affect your JavaScript happiness are proxies and blocker add-ons. Or bad connectivity and a file not loading. The issue is that JavaScript isn’t as forgiving as HTML and CSS is – when you do something wrong, things break. Used wrongly, JavaScript can seriously affect the performance and even the security of the web product you create. To a degree this also applies to CSS and HTML, but you have a lot more power with JavaScript.

However, if you work with a new-ish computer on a fast connection, you are most likely not savvy to any of these issues. Instead, you’re prone to pile up more and more dependencies and code to increase your developer convenience.

When it comes to used technologies of the web, it shouldn’t be a surprise that a lot of it depends on JavaScript. And on not well-thought-out, hacky and unmaintained JavaScript to boot. Libraries don’t get updated regularly despite blatant security issues in them. Stop-gap solutions built to work around an issue of a browser in a certain version never get removed.

The web is a landfill of accumulated, unmaintained and often bafflingly bad code. And yet it works. This isn’t only the result of sturdy technologies driving it. It is – to a large part – browsers doing anything they can not to break the web.

The first browser I used as a daily driver was Netscape 3. Netscape had no chill. If you didn’t close your tables in your HTML, it didn’t show anything. That taught me to value HTML validators as part of my workflow. But these days browsers can’t ever break the web. Whatever you throw at them, something will render. And that takes a lot of work and we should thank browser makers more as that is something that kept the web alive.

Working on browsers taught me a lot of things and made me a lot more humble than I was when I was a web developer. As a web developer I thought browser makers keep the web from evolving as it doesn’t affect their bottom line. As a developer working for browsers I learned that a huge part of the engine is dedicated to backwards compatibility. JavaScript engines make sure that code that performs badly because of the way it was written still runs smoothly. And new features of the platform only get into production after making sure that they aren’t a security, accessiblity or performance issue.

So, when we celebrate the web today, I also think we should celebrate the people who built the technology that enabled it. Browser makers, framework creators, server-software creators and all the people working on the infrastructure of it.

Of course it is damn cool that the first web site ever (and yes, the Space Jam one – enough already) still renders in browsers now. The reason is though that these web sites don’t do anything hard and are quite clean code. That the web in between, with the crimes of DHTML, the library and browser wars and all the hacks people put in there to achieve a certain effect still renders is because of browsers allowing for this.

I would love to be able to make browsers a lot leaner. But the web we have now is a mess. A wonderful, exciting mess that allows anyone to take part in it as a creator. And that’s thanks to its base technologies and to a lot of people in browser companies making sure it keeps working.