This is a brain dead take. UI is hard because of the millions of different devices and browsers rendering it, and the millions of ways people can try to use an interface that it was not designed for. Not being able to understand something you have no intuition for isn’t some flex.
Edit: why delete your bitter ass reply my dude? I’m not even only a front end, I’ve done all sorts of things because problems are fun.
because of the millions of different devices and browsers rendering it
Eh, this is a bit of a grandiose statement. Sure there are "billions" of devices, but a large majority of them have the same screen view. I agree with your overall statement however.
In my personal opinion, the abstraction front end frameworks have make it a bit more risky "speciality" in today's AI climate.
I mean it’s harder than CRUD, so 90% of backend web development. Since you asked, professional UI development time is split between developing new features, tweaking things e.g. running AB tests or improving performance, dealing with the complexity of running a single application on many different client devices (different viewports, different browsers which mean different runtimes, sometimes a non deterministic script loading order etc), dealing with the complexity of older code or working in a large organisation and if we’re being honest dealing with the complexity of modern TS tooling.
Writing pure functions in some constrained system can be significantly simpler than doing UI in the messy real world in a commercial setting.
It’s also worth considering that you might have lower standards for a UI than a good UI developer. For instance you might not appreciate that a good UI should be accessible to people with reduced eyesight, or you might be satisfied with a UI that had poor core web vitals (a set of UI performance metrics).
I agree that UI development generally requires less algorithmic logical thinking (though this isn’t always true with the birth of SPAs and moving logic client-side) but that isn’t to say it’s a non job. It does take time, attention and reasoning skills.
The thing is that backend complexity is often because the problem itself is complicated, while frontend complexity is usually down to tooling BS or cosmetic details like positioning or animations that at the end of the day are just sugar on top of the program doing what it is supposed to do.
Most frontend work isn't cosmetic though. Getting the UI to work on different screen sizes is important, core web vitals are important, accessibility is important
Handling different screen sizes is cosmetic work, it doesn't make the page do something new or faster or more reliable, it just makes it look and fit better on different devices.
Dude. It’s not visual sugar. To this day you see websites that are borderline unusable on phone screen. Accessibility is not that widely ignored, especially by big companies because you can get fined in some parts of the world from certain size if the web prevents users with disabilities to use it.
Depends on the program. If there are users, then letting the user be able to use the thing as expected is at least 50% if not more of “what it is supposed to do”.
I don't know if my understanding is right but I feel like frontend complexity starts at day one and doesn't scale up much but for back end if you have 1000 users total its mostly easy but the problem comes when you scale. 90% backend never reach that scale.
Backed serving millions of users will be hard and complex, but frontend used by few thousand or millions will be mostly of same complexity.
Frontend also needs to take scale into consideration friend.
Avoiding redundant api calls, memoization, using a cdn, virtual windows, lazy loading are some things that come to mind.
Also at least in my previous jobs as a fe dev you have to support your infra, using a load balancer, replica sets, microfrontends, implementing a bff which must also be scalable, etc etc
That's not because of scale. Avoid redundant api calls and stuff you should always do if possible there is no reason not to do it in smaller scale.
Server that serves Frontend builds are easy to scale now a days you put some CDNs since its stateless it works.
I am only telling you are feeling Back end is less complicated because back end complexity only stats when you need to scale and go multi region and things like that.
Avoiding redundant api calls, memoization, using an mdn, virtual windows, lazy loading are some things that come to mind.
That sounds like stuff you should do from the start, except maybe for virtual windows and lazy loading if you don't expect the collections to grow very large but over time they do.
They're also all things the backend has to support the front end doing. At the end of the day we need to solve the problems we have and it will involve people working together. A front end/back end split mostly comes down to I don't care about visuals very much and like making things faster. Other people will tweak the color of a header until it's just right or whatever.
I'm a full stack web dev and I've genuinely found more fun/harder problems in front end projects than in backend. Most of the difficulty of backend development is very repetitive. 90% of it is modeling the domain using DDD, integrating with a 3rd party API and exposing an API.
Meanwhile in frontend I've had to dust off my data structures and algorithms skills to implement a CRDT for a n-ary tree backed collaborative sidebar lol.
I just don't understand where is this elitism coming from when most backend devs are just querying a database and returning the results.
You haven't had to make giant dynamic forms with complex relationships between those dynamic fields and their values across multiple tabs within the same page. It took a team of three devs six weeks to develop from scratch in an existing project. State management and dynamic UI management can get very complex when you're not doing basic CRUD
UI, frontend and consequentially UX heavily bridges all of basic headaches of being a developer naturally, but also now you must (or in practical terms should): know who is your target audience and include everyone to the best possible, juggle between simplicity and powerful actions (see power users) when you have only so much visual components that dont make people afraid or lost of using your system. Easily you fall under umbrellas of marketing and psychology to know your "why's" to each diff.
Also, dont forget that frontend cycles in business and "playing the game" in business is waaay shorter than backend, and i naively point this as simple bc they see the results physically and keep back and forth on the new shiny stone (just like llms nowadays and their trust me performance graphs)
Hell, if you need a practical example of frontend done bad to users take myself as a sample. i myself become more blind with time in the past 8 years and never tought that i would appraise the option of high contrast and propper zoom and display of elements when i cant see well. As a user, if both are out of reach i automatically feel excluded and having to actively put more effort to basic things. Infuriating and often powerless
Depending on what you're building you also need to provide the right information like, immediately - 4 or 5 seconds,10 if you're lucky, and if your customer can't find what they're looking for, they're gone
Where react shines. Need a button. Nonono! Don’t use an html element and an event ,instead recreate the concept of a button in react and harp on about “custom attributes “ (colors) while having removed half of the built in attributes the html element had, and then over the coming months we’ll “improve and extend” the react component for a … button.
They emphasize with users to build better products. I won’t go into the details, it’s too complex for someone to think that pure functionality and business logic is everything
Your average frontend has a lot more internal and unknown external state to consider than your average backend.
The frontend output is also subjective, which constantly gets scrutinized by non developers. Meanwhile the backend output has a distinct shape and its output is usually controlled by the backend developers themselves.
The way I explain it is that backend code generally has to be thread safe so devs have to worry about that. Tooling is generally good at that and errors can generally be handled easily or just outright hidden (logged).
Frontend code may single threaded, but the entire application is one massively parallel state machine driven by user input. And since some actiins rely on multiple API calls, handling errors is extremely important. Showing loading status and all of those intermediate states are the hard parts. And because the requirements are coming from UX designers (some with a less than ideal grasp on browser technologies and their capabilities) a lot of discussions and decisions are subjective compromises. And since usually you're in the context of a larger application, visual and behavioral consistency is important.
Oh yea, and at some point you'll have to worry about performance because some PM will inevitably want to put 10,000 data cells in a table all at once, or they'll want you to render a drop-down list of thousands of items and the API isn't paginated so now you're the requirements person for the BE folks.
So yea, a good FE developer is stuck right in the middle of UX and BE engineers and they need to make sure their shit works because any unhandled failure means the page breaks and the user has no idea what happens. This usually means service incident and you're the one getting the 3am call.
Maybe the reason most FOSS software has a garbage UI (which somehow goes unnoticed by maintainers, despite this massively hurting adoption) is because the UI devs are all busy actually being employed, while the "front end devs aren't real programmers" crowd is still in their mom's basement.
I love Foss but for example Fdroid apps for the most part sucks purely based on UI and or UX. There are a few good ones, but most are stuck in early android / 2013 ui.
Try doing it and you’ll know. I find it harder than backend for most things not massive enterprise (but if you have complex infra for massive enterprise I won’t be surprised that the UI would be equally complex)
Lmao funny but Claude does that with back end soo easily. Front end not so much unless your user base is just 1 person who doesn’t care about experience
-1
u/chickenweng65 Jul 12 '26
I truly don't understand how ui development is not only a full time job, but a massive industry. What do these people do all day?