I have a favorite Utah story that is I think appropriate here. Many years ago as a young and green consultant I was sent to Salt Lake to help with some ASP.NET/C# app with Utah Department of Liquor. I was told to look for the tallest building in SLC and the warehouse did not disappoint, it was huge (well, SLC is really flat and squat too). They showed me the warehouse full of really fancy robotic stuff (all made in Utah, and they were correct to be proud of it). We got to work looking over the code of the app, and along the way they learn that I am originally from USSR/Russia. "Oh" the devs say, "do you want to see our Russia module"? I am of course intrigued, and discover that during the process of organization of 2002 SLC winter Olympics (Mitt Romney's baby/rise to prominence), there was a huge diplomatic incident. The rules of State of UT at the time limit the number of bottles sold to any one in a given transaction, and the Russian delegation was refusing to come to Utah because they would not be allowed to buy as much liquor (likely vodka) as they wanted to. This got escalated to the highest levels of State department, and the intrepid UT legislature found a way! They [very quickly] passed the law that any person with Russian citizenship could buy whatever the heck they want in any amount. Now it was up to the poor saps in the UT Dept. of Liquor to implement it. But you couldn't just rely on people showing passport! No, the software team feverishly coded up the "Russian Module" that implemented passport number validation, making sure that if you did show a red passport with double-headed eagle, its number was valid. There was serious collaboration on the numbering schemes and maybe even some proto API validation to the Russian Federation servers. Yeah, legit module. Used for 2 weeks, and then decommissioned as the law sunset very rapidly.

So, where there is a will, there is a way. And a VPN.

There are a variety of differences.

Frontend development involves a large number of fuzzy human bits that are constantly moving underneath you. Yes, your backend dependencies can change and you may need to update an API version, but in frontend you have browsers, screen readers, frameworks, and all sorts of massive icebergs largely outside of your control constantly moving.

In the backend, you probably have a language that is fairly stable. Write some unit tests, write some integration tests, but things are predictable and mockable.

Writing UI (properly) requires testing against several versions of several browsers, each with their own rendering quirks. UI tests - screenshots, whatever - are inherently flakier and when something breaks it's harder to know for sure if it's your fault.

You need to test against a variety of screen readers and accessibility tools. None of them are well documents, all of them parse the DOM (or native accessibility stack if you're not doing a web app) in a slightly different way, and the standards are constantly changing. As a bonus, you're legally obligated to get it "right", not that anyone can tell you precisely what "right" is.

Visual design isn't a walk in the park either. The designers will tell you to use color X. Its contrast ratio against colors Y, Z, and B on various pages will hopefully meet the contrast ratios, but then someone will point out that in exactly one of Windows' four different high contrast schemes this ends up being black on black and you will stare into a dark Lovecraftian abyss wondering what hellish algorithms Microsoft uses to pick colors. You'll fix HC Black and break HC white, you'll fix white and break black #2, and you will eventually throw your computer into the Marianas trench and go repair bicycles for a living.