Transient Frameworks

Since the first days of the Web, people have been thinking and debating hard about the best ways forward. The network, the protocols, the browsers, the documents, HTML, CSS, and Javascript – all those things are the result of years of countless discussions, fights, mistakes, and course-corrections. And as long as the Web has been around, people have been looking for ways to innovate, to improve, and to move the Web forward.

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.

The web platform in 2022 is less fragmented and more powerful than ever. Not only in terms of occasional new HTML elements like picture, but also when it comes to new CSS features. CSS Grid arrived in almost all major browsers roughly at the same time. And the same thing is now happening with features like :has(), Container Queries, or Cascade Layers. New JavaScript Web APIs make the platform more capable than ever and native Web Components are opening the door for technology-agnostic, robust implementations of custom user interface components.

In recent years, JavaScript frameworks have dominated the public discussion. To many developers, they not only offer a very convenient way to work, but they also seem to be superior to web standards that have even been labeled as being “broken” by some. Why?

Maybe Jeremy is right. Maybe the majority of full-stack developers doesn’t trust native platform features enough. Maybe they’re under the impression that much of what they’re trying to do is so sophisticated and advanced that native browser features and plain HTML, CSS, and JavaScript can’t possibly be powerful enough to compete. Maybe they believe that this is also the reason why frameworks exist in the first place: because browsers are inconsistent, unreliable, and antiquated, and because plain HTML, CSS, and JavaScript are limited and not up to par with the requirements of modern web development. This is exactly the card some frameworks play when they proclaim on their websites that “best practices don’t work.”

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.

And as, once more, Jeremy Keith points out in his great talk In and Out Of Style, we depend on all the innovation that happens in the faster, more trendy corners because people build things to solve problems for which the standards might not offer a solution yet. Many of the latest additions to HTML, CSS, and JavaScript first existed as JavaScript libraries or frameworks or pre-processors or polyfills and then found their way into the standards process, back into the layers of web technology that move slower and are more resilient.

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.

~

13 Webmentions

Photo of @matthiasott
@matthiasott
@matthiasott Nice post. By "frameworks", are you referring to JS-focused frameworks such as React?
Photo of Jeremy Keith
Jeremy Keith
Transient Frameworks · Matthias Ott – User Experience Designer December 3rd, 2022 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.
Photo of Adactio Links
Adactio Links
Transient Frameworks · Matthias Ott – User Experience Designer matthiasott.com/notes/transien…
Photo of @matthiasott
@matthiasott
Transient Frameworks, by @matthiasott: https://matthiasott.com/notes/transient-frameworks Transient Frameworks · Matthias Ott – User Experience Designer
Photo of Frontend Dogma
Frontend Dogma
Transient Frameworks, by @matthiasott@mastodon.social: matthiasott.com/notes/transien…
Photo of @matthiasott
@matthiasott
“Transient Frameworks” by @matthiasott https://matthiasott.com/notes/transient-frameworks Transient Frameworks · Matthias Ott – User Experience Designer

Likes

Reposts