I think a good understanding of design is also something people don't get about front end. Limited designs from designers means I fill in the gaps in some places.
Dealing with every possible edge case. Breaking out the advanced web APIs when they can easily solve certain problems, e.g. Intersection Observers or Mutation Observers.
Breaking out the advanced CSS APIs like @property rules for super easy and smooth animations.
Improving tooling and JS builds. Making sites fast and reliable.
On and on. Front end can get looked down upon if you're making the same old stuff over and over again. A modal here, a toast there.
But when you get assigned the crazy shit designers come up with, it becomes a very intricate challenge to create the the simplest solutions you can.
I don't think this is already a pattern but maybe somebody else is already doing it like the above so please let me know if it is the case
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.
This allows 3 things: a BE API as a promise AND division of labor (when possible and/or necessary) AND building what's essential on-demand by thinking about the FE's planning and needs first.
The problem with building a BE first is that leads to unnecessary work.
I'm a bit biased because I prefer standardized/CoC, monolithic development that doesn't have too much disconnection between the FE and BE stacks.
1. The ecosystem has fragmented further. Every app uses even more tools and frameworks, each with its own quirks and version incompatibilities
2. With E2EE and blockchain-based apps becoming mainstream, the frontend now handles complex cryptographic operations, key management, and secure data handling entirely client-side. Mistakes here are security vulnerabilities
3. Advanced interactions, personalization, and real-time updates require sophisticated client-side computation. We're beyond "thin clients"
4. 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 :)
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?
I think it's pretty common nowadays to have indexdb to cache data, but also your state management framework (ngrx,redux,mobx,etc) which sits between indexdb and your rendering framework.
I am (unfortunately) a FE engineer nowadays but I write very little HTML/CSS. It's mostly wrangling FE state and making it "efficient", cache invalidation, optimistic updates that mimic BE operations, etc.
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
Maintaining a consistent state is very difficult at the best of times. This obviously has implications for the backend, it needs to respond quickly and the page render in a decent time(minimal libraries).
But the approach just doesn't work for things like Slack, Figma, Google docs. When you're trying to create an experience that's somewhat similar to a native application on the web, you need to start worrying about local state.
Provided page reloads are fast, I think far more sites would be completely fine with just being sites and not rich client apps.
Due to this, companies may have a higher bar of expertise for backend which may give the impression that it is "harder", but I don't think this is a very important distinction.
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.
With backend though, even if it seems to work, there can be severe hidden problems with the architecture and security, so I really need to trust the backend dev or verify things deeply myself in order to ensure quality.
If I'm making a quick app for a startup, I can often hire relatively less experienced frontend devs, but have to care much more about the backend.
Not every project has a quality bar as low as this.
- All of the widely used mobile and desktop browsers
- Inexpensive Android devices - very common, most devs don't test in them, frequently suffer from terrible frontend performance that goes overlooked
- Browsers running common ad blockers
- Screenreaders - frontend accessibility is a whole speciality in itself
- SEO concerns, making sure crawlers see the right stuff
- Slow network connections - simulate how the site behaves on devices in rural areas with bad connections
But, covering all these cases and doing all the polish and animations expected of high quality frontends has usually taken much longer when I've needed to do it, 80% of the dev time has been frontend in some cases.
Prototyping and internal tooling are both obviously things with far different bars for quality (much as I wish internal tooling wasn’t treated like that). I’ve not felt much difference in prototyping endpoints on the backend versus new pages in the UI in terms of difficulty. Internal sites usually have dramatically lower quality bars than production apps, though hopefully you’re not treating accessibility any differently for them. A company can mandate that their employees use a specific browser. The company knows which hardware/OS are used. They also can often support only one language unless they’re large. Most tools don’t have to worry much about turning away customers.
Earlier you mentioned sneaking architectural issues. Frontends are rife with these, and this is part of why there’s so much churn in frontend frameworks and APIs. It’s often incredibly easy to make a UI which appears to work and satisfy the requirements as given, but unless you’re aware of the things listed in other comments the resulting codebase might need an entire rewrite to support the actual features which customers expect. Maybe you built an entire UX which fundamentally doesn’t work when using a screen reader or a software keyboard. You might you have no way to support optimistic updates or undo. Maybe your choice of routing framework won’t allow you to block a route update until some data is loaded or an animation is finished. Sometimes these things are easy to bolt on, sometimes they result in weeks of lost progress. All that might be acceptable for an internal site, but the vast majority of frontend developers spend most of their time on client-facing ones.
I guess my main point is that I frequently hear stuff like this from backend developers, and I also frequently have to fix the frontend code they wrote because they just didn’t know how much goes into making the slightest bit of a non-trivial workflow for customers. As an aside, I think the worst offenders in this regard are actually people who describe themselves as full stack. I have done a fair bit of backend work. I’m not full stack. My backend work rarely has to worry about load balancing or database consistency, but that’s because actual backend devs are catching those things for me. I know those things exist though, and that many more that I’m not aware of do too.
I'll go one farther: nobody hires senior FE engineers.
FE is perceived as having a lower skill ceiling than BE[0]. I rarely see an FE position (or a "senior" FE position) require more than 3 years of experience. And can you blame them when FE technologies churn so much faster than BE ones? It's still fairly common to have a decade old Java backend running against an equally old postgresql database. Who still runs jquery (other than levelsio)?
[0]: I do not agree with this, but it's a common perception.
if you agree no need to up vote.. but if you disagree then do up vote as I told you something you needed to hear..
Given the situation with hiring, this might be good and still give some space to junior devs to exist. But I could be wrong and AI could be doing already a better job.
danpalmer•8mo ago
This is perhaps less true in 2025 than it was in 2012, but I feel it was largely the same until maybe 2022, and is still not far off this.
I think the engineering is underestimated, but also I think job applicants are very bimodal - some coming from a design or boot camp background, able to be productive but not run scaled engineering projects, and some from perhaps a backend/etc background and can scale a codebase, but who are prone to trivialising frontend development and giving less consideration to design and UX.