There are definitely examples of UI programming that is more complex than certain APIs that largely perform basic CRUD operations, but I'd strongly disagree either is inherently more complex than the other, it's just that human behaviours and preferences are messy and unpredictable, which means conceptually "simple and elegant" UIs are often not what users actually enjoy using, and this inevitably has impacts at the code level. APIs don't have to designed to deal with human eccentricities as they're written for developers, and we aren't like normal people.
I find the big difference for me when building an API vs working on a UI is the testing.
I think backend APIs tend to be much easier to test than UIs.
For the backend, it's mostly Request in Response out, check they look good and the side effects (database, caches, queues, etc.) are performed etc.
For the UI you have a lot of async stuff going on and writing non-flakey tests is tricky and verbose with the current tooling - using react testing library which is better than enzyme, but still harder than testing a Django endpoint.
Absolutely - realistically you never can automate UI tests fully, as there's no way of describing all the things humans "expect" to experience while using a UI.
Even when you can, the effort involved in creating and maintaining the tests and confirming that the failures are genuine often doesn't justify the benefits.
Then you've never written APIs that have to do super complex calculations or process huge amounts of data efficiently and reliably.
By far the most complex code I've had to deal with has been "back-end engine" type code, even if it was technically part of a desktop application (but wasn't dealing with user interactions).
My point isn't that "all UI is more complex than all API", but that the constraints and nature of UI tend towards complexity (especially incidental complexity) at a higher rate than API programming. As you observed in a previous post, UI engineers struggle to use techniques like end-to-end testing that API engineers use with relative ease. Why is that? My argument is that engineers working in the API space more completely control their problem space in general. Some examples:
- Want to rigorously specify the interface of an application? In API space, we can use an IDL like Protobuf to write a contract of exact input and output types. In UI space, the best we have is plain-english text language called Gherkin.
- Want to record all inputs and outputs made to application to verify them against new version? With network APIs, we can often record all app-level IO in production using network capture; often with negligible performance impact. To do best possible job for deterministic replay, we can actually hook into our CPU if we try hard. UI? Sorry, again we're running on a customer device, unlikely we can apply these technique. At best we may be able to capture some UI change traces on a few devices with spare bandwidth and CPU.
- Having performance troubles? In API space, feel free to buy more hardware, or optimize more tightly to the existing homogenous platform. Oh, maybe application takes a few minutes to boot up and "warm up"; this is fine, we'll use blue-green deploy and replay a bit of the read-only traffic we captured earlier... In UI space? We probably need to consider 2-3 versions of ~5 different operating systems, running on myriad heterogenous hardware, to say nothing of browser issues; where every few weeks Google releases a new runtime with the potential of performance regressions. Slow to boot? Say goodbye to users; we need the app to paint in 1.7 seconds and be interactive in 3.8 seconds, on demand at any time of day.
- Have a problem with teams stepping on each others toes? In API space, you can try to deploy two services (not saying this is good idea, but plenty of people see it as solution to this problem); end users won't know the difference. Try to deploy two separate apps in UI land? End users will be sad.
- Need to handle large amount of data in API? We have low latency access to storage APIs that scale to petabytes. In a UI? We'll need to build an API first to mediate streaming access to that data and store it for us, since we can probably only store a few hundred megabytes locally before we run out of disk. In both API & UI we need to add a local cache, but how do we test local cache provides good experience? This takes us back to testing topic... where API seems to be easier.
An argument from anecdotal experience isn't worth much in this territory; I can easily same the same thing in reverse: the most complex code I've had to deal with is threading the very narrow constraints of contentEditable programming for Notion's rich text editor. Now let's add a dash of "no true scotsman" as well: You must have never written any such complex UI! See? I think this is an unsatisfying approach to the issue (and not one I make in earnest).
I don't disagree with anything you've written there, but I still disagree that UI code is typically or inherently more complex (or harder to write well) than backend code. I doubt it's anything you can even prove one way or another.
But while the nature of inputs and outputs for UI code tends to be nebulous and somewhat poorly defined, it's hard to argue the range of possible inputs compares with code that has to process massive datasets.
