When Did Frontend Development Become a Nightmare?

Do you remember when building the frontend was actually fun?

Today, for many, it's a nightmare. It often feels easier to build a geo-distributed backend than it is to simply understand the modern frontend stack. What went wrong? How did we create this monster, and more importantly, can we fix it? Let's explore these questions.

The Genesis: A Lean UI and Testability

To understand our current predicament, we need to step back in time. Martin Fowler, in his seminal work "Patterns of Enterprise Application Architecture," highlighted a significant shift with the advent of client-server systems and Object-Oriented Programming: a strong push towards a three-layer architecture. In this model, the UI was intended to be a thin presentation layer, devoid of complex domain logic.

This philosophy drove the evolution of patterns like MVC, MVP, and later MVVM. All these patterns shared a common goal: to establish a clear separation between the view (what the user sees) and the actual logic.

But why was such an emphasis placed on making the view a "dumb" or "passive" layer? The primary reason was testability. Testing user interfaces has historically been a challenging endeavor. As Fowler articulates in his blog post "Humble Object," elements that are difficult or impossible to test are prone to bugs. The solution? Move as much logic as possible out of these hard-to-test elements. This separation of view from logic allows developers to test core business rules independently of the UI, a fundamental principle embraced by clean, hexagonal, and onion architectures – topics we frequently discuss on this channel.

Beyond testability, keeping the UI lean also offered benefits because UIs tend to change more frequently than business rules. Furthermore, with the rise of mobile, TV, and the Internet of Things, it became common to build multiple frontend experiences around a single, core business model.

By the late 2000s, building a UI was relatively straightforward. Technologies like PHP or Spring MVC with templating engines, augmented by JavaScript and jQuery for dynamic behavior, made web development accessible and efficient. However, some developers yearned for more. And this is where the modern frontend's story truly begins.

Chapter 1: The Rise of the Single Page Application

While server-side rendering dominated, the Single Page Application (SPA) started gaining traction, and with its popularity, the troubles began. The demand was for richer, faster, more desktop-like user experiences, crucially without a full page reload for every user interaction. To achieve this, a critical architectural decision was made: moving state and some application logic directly into the browser. This was the first "crack in the dam."

Chapter 2: The Component Revolution and State Management Crisis

The release of AngularJS in 2010 and React in 2013 sparked an explosion in SPA popularity. These frameworks introduced powerful concepts such as two-way data binding and reusable components, which were incredibly effective for constructing complex UIs. However, they also introduced a new challenge: how do these numerous, small components communicate and share state efficiently? This question led to the emergence of complex state management libraries like Redux. And inevitably, business logic, once confined to the backend, began to find its way, often hidden, deep within frontend state management stores.

Chapter 3: The Tooling Explosion

Managing this increasingly intricate client-side environment necessitated a massive ecosystem of tools. Bundlers like Webpack, transpilers like Babel, and countless other libraries became essential just to get a basic application up and running. This is the origin of that often-dreaded node_modules folder. Slowly but surely, without a cohesive grand plan, we didn't just add complexity; we inadvertently rebuilt an entire backend directly within the browser.

Consider the implications: modern frontends now handle client-side routing, complex data caching and synchronization, state machines, and a significant amount of business validation and logic.

The Ironic Twist: Full Circle to Server-Side Rendering

Here's where the story takes an ironic turn. We eventually realized that having a massive application running entirely in the browser was detrimental to Search Engine Optimization (SEO) and initial page load performance. What was our solution? We circled back to server-side rendering! [Laughs]

This realization gave rise to incredibly powerful, yet mind-bending, meta-frameworks like Next.js. Now, we have a single framework that blurs the lines, acting as both a backend and a frontend. Logic can execute on the server, on the client, or both, completely muddying the waters of responsibility. Easy, right? Our solution to having a backend on the browser was to create a frontend on the server, making the "monster" even more complicated and confusing.

And if that weren't enough, the advent of AI and "vibe coders" has further accelerated the popularity of these complex technologies. With a simple prompt, you can generate a nice-looking proof of concept, and with a couple of clicks, deploy it to production. However, if you've been in the industry long enough, you know that these rapidly generated apps often become architectural disasters, ill-suited for any real, long-term production system.

Can We Fix It? Embracing Architectural Clarity

So, what do we do now? Can this frontend monster be tamed? The answer isn't simple, but there are clear paths forward.

From a purely theoretical perspective, we could reestablish the backend as the single source of truth. If it's business logic, if it defines our core processes or rules, it unequivocally belongs in the backend. Period.

Rather than migrating logic to the frontend, we could embrace architectural patterns such as the Backend for Frontend (BFF). This pattern involves a dedicated service positioned between your main backend and the UI. Its primary role is to prepare and shape data specifically for the view, allowing the frontend to remain clean, simple, and focused exclusively on presentation. (I've previously created a video discussing this pattern.)

Another crucial step is to embrace the "humble object" philosophy. For every line of logic we consider adding to the frontend, we should ask ourselves: "Does this truly have to be here?" Very often, the honest answer is no.

Perhaps we also need to re-evaluate our default adoption of SPAs. Are they always necessary, or are there scenarios where a more traditional, server-rendered approach is more appropriate and simpler to maintain?

Conclusion: A Call for Simplicity

In conclusion, while the backend world has largely democratized development with frameworks like Spring Boot, effectively reducing complexity, the frontend has taken the opposite trajectory, embracing complexity. I can't help but wonder if the strict backward compatibility with HTML, CSS, and JavaScript has inadvertently forced us to construct these towering, complex abstractions just to achieve modern functionality in an object-oriented way within the browser.

Building the frontend should be fun. It should be about presenting data beautifully and handling user inputs intuitively, not about wrestling with intricate state management and domain logic.

Anyway, that's my perspective. What are your thoughts? Is the "frontend monster" a reality in your projects? Let me know in the comment section below!