Over-Architecting in Web Design

I recently read a post by @justinfagnani on X that says:

"Lit is not a framework. The browser is the framework."

This got me thinking about how we've been building for the web in recent years.

For quite some time now, if you know HTML, CSS, and JavaScript, you really don’t need a framework to build web applications. At most, you might use some libraries to simplify certain tasks, but even these are gradually being incorporated into the platform itself, like routing or state management.

Our focus, however, has shifted towards learning frameworks, and now meta-frameworks, which do make it easier to build web environments. They optimize pages, automatically generate necessary files like sitemaps.xml, optimize images, remove unused CSS, bundle, minify, and optimize JavaScript. They’re effective, yes. But they don't adhere to the standard.

Meta-frameworks like Astro let you use standards, but they don’t exactly make it easy. Instead, they streamline using other frameworks or their own components in a more user-friendly, non-standard format to "simplify" component creation. They also employ techniques to facilitate SEO, loading, and indexing—depending on how you’ve implemented them.

To me, this approach has two major issues:

1. Cognitive overload: Developers must learn to manage not only the framework itself but now also the meta-framework and its set of tools, which often adds unnecessary complexity to project architecture.

2. Detachment from the standard: Focusing on frameworks means we’re not investing time in understanding the latest developments in the web itself, which are substantial. CSS, for example, is making a huge leap forward with features like container queries. Meanwhile, JavaScript and HTML are also evolving, with HTML potentially introducing a new <select> element that will allow HTML and CSS within <option>, opening new and more flexible ways to create rich selectors.

In many frameworks, though, these innovations are implemented through their own components, so to developers, it can seem like these new features are framework inventions instead of standard advancements.

I remember a few years ago, when these meta-frameworks were just emerging, a developer excitedly told me, “They’ve invented SSR (Server-Side Rendering); now we can generate HTML on the server, creating static pages.” I looked at him in surprise. He insisted, thinking I was just as impressed with this “novelty” saying, “Isn’t it incredible? What a fantastic idea.” The irony was that SSR has been around since the early days of the web.

Today’s web developers, those studying web development and entering the field, often lack historical context. They don’t know how web development originally worked. They don’t understand the reasons we moved from server-side rendering to client-side rendering and started using frameworks. Somewhere along the line, when “Ajax” gained popularity, we lost our way—probably driven by the desire for standards to cover everything we needed, while big companies fought to impose their own criteria, tags, and languages in the browser (I still remember Microsoft’s infamous VisualBasicScript).

Frameworks aren’t the problem. Not at all. They added power and value to web development. They allowed us to create applications for everyone, spurring the rise of hundreds of thousands of web developers and bootcamps.

Frameworks and meta-frameworks aren’t the issue; they even helped democratize web development, enabling millions to create applications and fueling the bootcamp boom. But as the web platform matures and standards become more robust, framework creators have business incentives to retain and promote their tools. They’re not going to say, “Stop using my framework; you can do everything with standards now.” Plus, migrating applications built with these frameworks to the standard is nearly impossible, especially since, in my experience, most lack E2E or functional tests to ensure that migration maintains the original behavior.

So, why aren’t we investing in tools that help us leverage today’s standards?

There isn’t a meta-framework that “forces” you to use the standard, making it easier in the process.

We need solutions that help us organize our projects efficiently and assist with build and optimization tasks if we want to do SSR, CSR, SSG, ISR, Hydration, create MPAs or SPAs. But we should be fully aware of our needs and the pros and cons of each choice. These tools should optimize images, JavaScript, CSS, and generate only the necessary files. They should allow the use of libraries that stick to the standard and adequately cover the platform’s remaining gaps. They should optimize and support SEO, loading, and indexing, facilitate testing, and harness the platform’s power.

It’s time to reduce over-engineering and excessive architectural design in our web projects. Let’s keep learning, not just how to use a framework, but also how to appreciate and apply the incredible advancements in web standards.

No excuses.