It all started with an era where only a very few early adopters were laying the very foundations of what we take for granted today – including weird and also wrong decisions that we have to work with today. New HTML elements, for example, were introduced with or sometimes also, famously, without much consensus. Like in the case of the IMG tag that Marc Andreessen casually suggested in an email thread in 1993 and then, although it was met with some opposition, simply released in the next version of his Mosaic browser. A few years later, we witnessed the browser wars with Microsoft emerging as the winning company that would dominate the browser market for quite some time. Just like Netscape did with its Navigator, Microsoft implemented its own exclusive features at the time in an attempt to reinforce Internet Explorer’s monopoly position. That browsers pushed for their own agenda started to become a real problem for web designers and developers who had a hard time building for this fragmented Web and, as a response to all the frustration, in 1998, the Web Standards Project was born. Its goal was to remind browser vendors that “HTML, XML, CSS and the DOM are more than just a set of interesting technologies” and that by defining their own standards, companies were actively hurting both authors and users of the Web. I sometimes wonder how the Web would look like today if the people who started the Web Standards movement had remained silent or if their project would not have been successful.
But their efforts were successful and it is one of the main reasons why we have quite a healthy standards process today, with all browser vendors and developers at companies like Google, Apple, or Mozilla working towards the same goal: a consistent and thorough implementation of W3C-specified standards. These open and evolving platform standards are the foundation of everything we build on the Web today. They move slower than some of us might wish, but that’s intentional. Everyone has learned from the mistakes of the past where elements like <blink> found their way into browsers. If a new standard is defined today, it better is specified as thoroughly as possible and with resilience in mind. After all, it will be part of the foundational layer of the Web for years to come. Even after 31 years, the worlds first website can be viewed in any browser without any issues. And if you use a picture element or CSS Grid on a website today, you should be able to expect it to work just as flawlessly 31 years from now.
Yes, frameworks often provide a great developer experience, they make things easy that used to be harder to achieve before, and they seemingly work at the bleeding edge of technology and innovate at mind-blowing speed.
But does this make web standards and native platform features weaker or even obsolete? To the contrary. Frameworks come and go. They are transient. Web standards, on the other hand, are the reason the Web is good now and it will become even better in the future. Web standards are why we can all build for the Web using a shared understanding of what it actually means to build resilient, performant, and accessible solutions with the foundational material of the Web. In fact, it feels like the pendulum has just started to swing back again as people realize just how bad frameworks are for performance and as they start exploring new CSS features, native web components, and what can be built on top of all that. Let’s just not forget that we need to take everyone with us, including clients, managers, content strategists, designers, and developers on all sides of all front- and backends.
Happy Blue Beanie Day, everyone.