Building a front end that other humans will use is literally art. Like in the classical sense. Confounding this with an API surface, 2nd state machine and additional team (the backend developers) turns an already difficult mission into an impossible one.

Learning how to do the whole thing is a lot easier in 2025 than it was in 2010. You have a consistent browser API surface and a chatbot that has the capability of every junior developer on earth combined at your disposal.

Being put into the position of full ownership means you will reject bad technologies out of sheer survival instinct. You'll reach for approaches like SSR. Putting all of the state on the server (by using server side rendering exclusively) means that there is no more API. No more distributed state. You are now permitted to write sql queries that directly populate the relevant HTML partials without any intermediate bullshit. Imagine how quickly we could compose response bodies if the authoritative data store lives on an NVMe disk in the same machine. You could be measuring your page render times in microseconds instead of milliseconds.

I disagree, at least partially. When this article was written, one of the biggest difficulties with front-end development was browser incompatibilities. Front-end developers were deploying to a hostile, inconsistent environment.

Things have gotten much better on that front. Browser support for standards is much better. People upgrade to the latest versions much more quickly. Systems that transcode from modern style to backwards compatible style, like Babel, TypeScript, Lightning CSS, or PostCSS, are commonplace.

The end result is that front-end developers are far more able to target modern APIs and functionality without worrying about compatibilities anywhere near as much. The browser environment has become much more consistent and capable.

Do some developers overcomplicate things with monstrous WebPack configs? They sure do. But the important thing is that they chose that. If you want to keep a super-simple build, you can do that too. You have the choice of how complicated your stack is; you don’t have a choice of how complicated the browser environment is.

> With E2EE and blockchain-based apps becoming mainstream

Blockchain isn’t mainstream, and hardly any front-end developers need to care about E2EE.

> Advanced interactions, personalization, and real-time updates require sophisticated client-side computation. We're beyond "thin clients"

This is marketing speak that doesn’t reflect the day-to-day work of a front-end developer.

> The Big 4 invest $millions in each interface and users expect the same level of UX/UI from anyone. Let's talk about simplicity on the surface :)

What do accounting firms have to do with this?

On top of that, the complexity of front end (for me, which is in a “real time” app) often comes down to providing a user experience that “feels good” while also accounting for the complexities of keeping things in sync with the backend(s). For example, I often want a user to be able to update a thing and I want that change to feel immediate, but if 1% of the time that errors out because of business logic reasons, I need to be able to undo the immediateness, restore the previous state, maybe reconcile the local state with the newer remote state, and then display the problem to the user.

Maybe I’m just doing things wrong but there’s just a lot of complexity related to that and I struggle compartmentalizing it in a maintainable way

I largely agree with your points. The backend has the largest security and reliability burden. It’s the bottleneck everything has to go through, and it can’t trust anything it’s receives. If it breaks nothing else can work. Also, backend deployments tend to involve a lot more moving parts.

> they are easier to do a surface-level check too (just use the app and check that it works)

If what you were getting at with this is that the make change -> see result loop for the frontend is overall faster, I’d thoroughly agree with that. It’s why I’ve never stayed on the backend for long. It’s pretty cool to be able to make a change and see it reflected in the UI within a couple hundred milliseconds without losing application state.

But while that’s probably the usual case, for a significant amount of the work it’s woefully insufficient. When trying to fix something, “just using the app” often involves significant deviations from the way you’d normally use it. Typical user bases use apps in maddeningly diverse ways. They have different browsers, operating systems, displays (DPI and color systems/accuracy), screen sizes, pointing devices (mouse vs touch), and assistive technologies (e.g. multiple screen readers, each of which has its own quirks). Members of product teams—particularly ones who aren’t web specialists—frequently forget some of these. Surface level tests obviously don’t include the entire testing matrix, but they often involve iterating on at least two combinations of use at the same time, and those combinations may involve significant overhead.

Accessibility presents a particularly hard challenge for quick tests, as most developers I’ve worked with don’t know how to use screen readers to do much, so just using the app isn’t possible for them without some additional learning.

Hopefully your testing matrix is mostly automated, but those automated tests are too slow to use during development. Initial bug isolation and getting proper tests around specific interactions can be extremely tricky.