I find that frontend takes most of the dev time for most apps, and I certainly consider it "harder" to get everything working to the quality level I want. However, backend work is usually more critical, as problems can result in data loss or security issues. Frontend problems often just result in bad UX, and they are easier to do a surface-level check too (just use the app and check that it works).
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’m a frontend dev. I’ve done backend and database administration work at a few points in my career, but never on sizable products or for more than a year or two at a time.
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.
I'm saying from the perspective of someone overseeing a frontend dev, that I can just try out the app feature and see if things seem to be working as expected. Though as you mention, it's necessary to check a variety of devices and other edge cases, depending on the project requirements.
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.
It really depends what I'm building, and I find that these are often additional tasks that are done later after the core functionality is validated. I've most often built apps used internally or to test concepts for early user feedback, that had a relatively low bar. But regardless, I can verify these without as much deep knowledge of the code by trying them myself, but can't verify easily that the backend was coded securely and properly.
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.
> It really depends what I'm building, and I find that these are often additional tasks that are done later after the core functionality is validated. I've most often built apps used internally or to test concepts for early user feedback, that had a relatively low bar.
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'm saying from the perspective of someone overseeing a frontend dev, that I can just try out the app feature and see if things seem to be working as expected
Not every project has a quality bar as low as this.
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.