How the Smartest Engineer Makes the Dumbest Frontend

In modern web development, there's an emerging philosophy that the smartest engineer is the one who creates the dumbest frontend. At first glance, this might seem counterintuitive. Why would we want a "dumb" frontend when the goal is to build intelligent, dynamic user interfaces? The answer lies in a strategic approach: offloading as much logic as possible to the backend, making the frontend a simple, maintainable, and flexible layer.

A "dumb" frontend doesn't mean sacrificing user experience. Instead, it means creating a system where the backend drives everything—from the content displayed to how it's styled and positioned. This results in a frontend that's easier to maintain, more adaptable, and scalable.

Dumb Frontend, Smart Backend: The Strategy

Imagine you're tasked with creating a completion screen for your application. It sounds straightforward: show a message or image when a user completes a task, accompanied by a call-to-action (CTA) button. But there's a twist—you need to create multiple variations of this screen across your website, each tailored to different user flows.

For example:

• One screen might display only an image.

• Another might show a bold text message with a CTA.

• A third might combine multiple text elements with varying positions and styles.

If we hard-code these variations into the frontend, we end up with a tangled mess of conditional logic, duplicated code, and a brittle, hard-to-maintain UI.

The Solution: A Backend-Driven Frontend

The smartest approach is to keep the frontend as "dumb" as possible, while ensuring it adheres to your design language system (DLS) practices, sizes, and colors. This means the frontend's sole responsibility is to render whatever the backend instructs it to render.

Here's how it works:

• Backend Defines Content: All text, images, and CTAs are delivered from the backend via API responses.

• Backend Controls Layout and Styling: The backend specifies the position, style, and visibility of each element. The frontend simply interprets and renders these instructions.

• Configurable CTAs: Not only should the text and styling of CTAs be configurable, but also the actions they trigger. Whether it's redirecting to another page, submitting a form, or opening a modal—these actions are all dictated by the backend.

• Frontend Enforces Consistency: While the backend drives the content and layout, the frontend ensures the UI remains consistent and doesn't break. This is achieved by enforcing DLS rules and ensuring the consistent use of sizes, colors, and spacing.

Your Challenge: Designing a Generic Completion Screen

Let's put this concept into practice. Your challenge is to design a generic completion screen where everything is configurable through the backend.

Consider the following:

• Content Structure: How will you structure the API response to include different types of content (text, images, CTAs)?

• Layout Flexibility: How will the backend specify different layouts and styles for the content?

• Configurable CTAs: How will you allow the backend to configure not just the appearance but also the actions of CTAs?

• Frontend Consistency: How will you ensure that the frontend remains dumb yet smart enough to enforce UI consistency, preventing any layout from breaking or looking out of place?

Stay Tuned for the Next Article

This is just one example of how to make a frontend dumb in a smart way. In the next article, I'll show you how to implement a configurable completion screen using this approach. We'll explore API design, frontend code structure, and how to enforce DLS rules, all while keeping the frontend simple and maintainable.

Take some time to think about your approach, and come back tomorrow to see how this concept is brought to life.
Here is the link for solution - https://jshanos.hashnode.dev/building-a-configurable-comletion-screen-the-smart-backend-approach