That's actually true. What makes backends harder (or rather slower?) to build though is the longlivety of the data involved. Backends that don't deal with data are indeed simpler than frontends in my experience.

> The attitude of the backend people of looking down upon frontend people

That has nothing to do with the complexity. It comes from the fact that frontend is more approachable and also more hip. It attracts more "amateurs" or people who don't know what they are doing, for one reason or another. The result is that technology on the backend-side is more advanced and mature than on the frontend side - though that might be a bit subjective and not apply to specific areas.

You actually give your own example: "frameworks with millions of entry points" and a dozen new ones every year. :) However, I think frontend is in the progress of catching up - e.g. Javascript is currently replaced with Typescript, which is not being looked down upon by backend people, at least not as much.

For some reason - unbeknownst to God and his prophets, very smart, intelligent folk want to use a BMX as farming tool to plough and till the soil. Now we aren't going to ask silly questions like - why use a bmx when you have a whole barn full of tractors.

No.

We are going to ask how to get maximum output from the pedal mechanism. How to replace the human with a robot so we plough faster and how best to install solar panels for day time power source as well as highly specialized lithium ion cells made specifically for this purpose, so we can cover more ground.

A farmer, who has been farming for his whole life, really belived the tractors with billions of man hours in commercial farms, trusty, easy to fix and operate with a plethora of mechanics to fix and improve them.

But that just gives the farmer a vague existential crisis, what really gets him in the dumps is how they get the the goods to and from the farm. See he has big lumbering trailers and a few modernis rigs. Hes been using them forever, they are insured and also have possibly the highest reliability of transport. The new farmers merely smirk at the diesel autos. They have sonething better, smaller, faster and many of it. Quadbikes hooked to trailers. Hundreds and thousands of them. Apparently a central computer, bless it, controls and orchestrates the many quad bikes. The old farmer feels lost and helpless everytime he goes out to harvest. His trusty harvester looks impossibly old and slow, steady as she goes. No matter that she can haul a few hundred tons a week, it is nowhere new sophistacted than the automated quadbikes - zipping in and out with their 80kg loads at break neck speed. It's like watching a symphony.

He wonders what they actually grow there. Seeing such advanced alien technology ,to him at least, these new farmers must be planting something more delicate than rice, yield higher than wheat, and sturdier than simple corn. Surely, he reasons, his life is all but over.

But is it?

The FOMO chronicles, Afseyuk, 2020

A front end is a state machine that relies on a bunch of enormous framework layers. Give me an app, mobile or web, and I'll find a glitch or two in the first few minutes of using it.

Backends on the other hand, like you said, only ever talk to other programs. And that means building a 100% correct and bug free backend system is not such a fantastical goal.

I find that a very strong claim, is it rhetorical or meant literally? If the latter, what can you find in (say) whatsapp* ?

(*: aside from messages delaying or appearing out-of-write-order, which are probably backend bugs inevitably arising from its distributed nature)

- scale - a frontend shows one user's view at once, a backend may need to be updating state for millions of users without slowing anyone's experience down. But these sorts of things are somewhat different than just "backend code", it's often closely tied to infra and data designs, which doesn't necessarily look like "backend coding" but is critical to make the rest work.

- business logic complexity - often the backend teams are tasked with working with frontend to figure out a simple, user-friendly API surface for the app and also to figure out how to make that work with the various not-written-down, not-even-fully-enumerated business logic permutations and backend-data permutations that could be going on. If they do their job right, the frontend can show different screens with values from the API ready to plug in for a particular scenario without having to worry about the combinatorial rules behind the scenes that led us to want to show the user THIS screen instead of any other one. The difficulty there isn't a mathematical or "hard" one, it's that the product team probably has no idea just how gnarly the set of business rules they sketched out actually gets. A backend has to support everything the frontend client can do today, but often ALSO support a bunch of things the public frontend apps don't yet do (whether this is for admin tasks, or for future readiness, or what).

I'm not sure I see the significance of the number of symbols in UIKit - you usually don't need all of them, I assume, and I know that there are some common patterns that get re-used a lot. Is it so different from in backend when there are dozens of databases you could choose, and a bunch of frameworks for each of a bunch of different languages you could choose, but for most problems it's not going to make a huge difference?

One thing that often hides the difficulty on backend is that the frontend team might be interacting with just one or two backend teams that then interact with a different set of teams behind them, etc. But the true "backend vs frontend" question has to include ALL of those teams, even the ones you don't directly interact with, since they're all in the critical path.

"Hard frontend problems are harder than easy backend problems" - ok, sure. But that's not a very interesting comparison.

Look at CAP theorem: it literally says "you can't have a perfect system here, you have to choose." That's a backend problem with literally no "100% correct and bug free" answer!

(With regard to the original article here, your error is that you're assuming modern backend software is closer to "low level" than "high level" compared to frontend code. It really isn't. And in terms of running your code, it's often at a HIGHER level than an app running directly on a user's device - you're in containers on VMs on someone else's hardware in a cloud environment, say.)

To me, the “you can’t have a perfect system” is really just, “You can’t have 100% availability, and you can’t have 100% durability either.” The hard part is then convincing the users of your system that even though your system seems perfect, they should be prepared for it to fail.

IMO the backend API solution is somewhat easy. 503 Service Unavailable. Then the front-end needs to somehow present a meaningful error message to the user, with a plan for how the user can accomplish their desired action or at least save their state and try continuing later… which can get insanely complicated…

But that's often not the requirement... 100% available isn't the requirement per se either, but "as available as possible because outages cost us $XXXX/minute" is. And pushing that number up is HARD.

And remember the context of this thread: we have a claim here that backend IS easy and that it CAN be "100% correct and bug free." Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless.

Strawman argument. I think you’re responding to something I didn’t write. The argument is kind of absurd.

> …but "as available as possible because outages cost us $XXXX/minute" is.

“As available as possible” is not a reasonable requirement. If this is your requirement, you’re in deep shit, but for different reasons. The problem is that you can generally spend more money to get more uptime. At some point, you have to say that the cost of more uptime is too dear.

You can do experiments, testing, and simulation to get a more quantitative handle on the trade-off between uptime and resources spent. If you care that much, that is. But “as available as possible” is a bad requirement because there’s no way to tell if it’s satisfied.

What ends up happening is that people unsatisfied with uptime can blame you for not having enough uptime, but they aren’t telling you how much is enough. The purpose of having a requirement is to record an agreement between different teams about “how much uptime is enough uptime”. It can be the wrong number, and it can be revisited, but if it’s not a number (with a way to measure it), you won’t be able to calculate other numbers like “how many database replicas do I need?”

> And remember the context of this thread…

I’m responding to the CAP theorem bit. You said that the CAP theorem means, “you can't have a perfect system here, you have to choose”, and I think that this is misstating the CAP theorem.

> Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless.

503 errors aren’t random. They happen when the backend is unavailable. It’s not a random “stuff is broken” error—that’s 500.

This is not a cop-out. Services will sometimes be unavailable. The 503 status is the correct way to signal this to the front-end. The fact that the back-end returns a 5xx series error code does not mean that there is a bug in the back-end.

Likewise, if the service is important enough, your front-end should be able to respond to a 503 error with some kind of reasonable workflow for the user.

I honestly think you've never built a decent sized, non-trivial mobile app for example, and you probably have no idea how tedious and difficult it is to produce something that will be pleasant for the users to deal with.

So it's a stupid definition. I haven't built a large mobile app, but I'm not claiming frontend dev is easy.

You're claiming backend dev is easy but your argument so far reduces to "it's easy because the hard parts actually aren't part of it" which is tautological and pointless. You're not even just claiming it's easy, you're claiming it can be built 100% correct and bug free.

What's the most complicated backend system you've built? What database, what user scale, what traffic scale, what technologies, what servers, etc?

[0] the part of the backend that renders pages, if one exists, and the part that validates user input should be VERY VERY different components, anyway...

If I screw something up in the frontend, then in most cases, I can fix it and people use the new version / reload the page and that's it. In backend, if I screw up, in most cases I now have a data problem and an ongoing problem that might only be fixable through an operational update. I might even have lost/overwritten data that is not recoverable or only through backups.

Sure, this can happen on the frontend too (e.g. sending a wrong update command to the backend API or when storing some data/configuration directly in the browser) but from my experience it is much much more likely to happened in the backend and if it does, it is more severe.

This doesn't make things more difficult on the technical side per se, but it slows things down a lot. I can't count how often I wished to be able to just truncate all user data and start with a fresh plate, instead of with a long, messed up user data history that contains quirks, fixes/workarounds in the data and that I have to stay compatible with and not forget.

Frontend is hard so we use lots of frameworks which makes frontend hard so we use some more frameworks.....

Agreed, personally when I've heard this, it's frequently due to the "backend" devs really struggling with the complexity of user interface needs, especially UI state. This is the root of a lot the "JavaScript is such a trainwreck" type comments too.

A higher level engineer is meant to "scale her impact" by owning the architecture, the platform, the playground in which other engineers live. In backend world there are opportunities to do this in nearly any business domain or sufficiently complex problem. But a company only needs so many UI frameworks. As such we see very good, long tenured mobile and frontend engineers simply cranking out feature after feature. There's no career progression that way.

I think the high horse is because frontend dev is hard. The backend has more methodical tooling. Javascript is not considered a clean language even if it has improved.

It would be nice if you could use clean modern tools but the web is forced to support legacy browsers so it is what it is.

I personally like the full stack and don't look down in either direction, but I understand the sentiment.

That's interesting, do you have a source for this?

For reference the Qt5 framework only has about 25k publicly documented functions and the shared libs expose ~100k symbols.

Backend:

- running a migration on a table of 100 million rows... in MySQL 5.6. Well, things can get complicated.

- building the infrastructure and monitoring of a k8s cluster

- debugging concurrency bugs

I think these topics are not really easier than their frontend counterparts. I do believe some aspects of frontend development are harder than some of backend development (and the other way around). I do not think, in general, that "backends are so much easier to build compared to frontends" though.

Evidence would suggest otherwise. I can build a decent and reliable frontend with a no code solution. That's not to say frontend is "easy", just that trying to say which is harder is ridiculous. They're different.

I personally don't like working on frontends because it feels like getting on a hamster wheel that spins faster than in any other domain. ymmv though.

If a user enters a number incorrectly on a frontend, a frontend can’t just say no. It might have to try its best to parse the number, or if it can’t, the error has to be presented in a user friendly way. A frontend can’t just throw an exception and say Bad Request.

Followed by the distant sound of enterprise, banking, and government frontend devs laughing.

A system can't just reject data it doesn't like.

Things that can be built that way are not interesting. Of course you can just assemble online stores without writing a single line of code, but that's not exactly programming. We are talking about frontends that have some sort of novelty or at least non-standard flows in them.