I’m primarily a frontend developer, but have done enough backend work to know what makes the two different. It’s these differences that remind me frontend is definitely not the easier of the two!
Now don't misunderstand me. The breadth of requirements of large-scale, geographically-distributed services is not lost on me. In their entirety they are no doubt a greater challenge, but your average backend system is not that. Whether stand-alone or a component of something bigger, the typical backend system is pretty straightforward (CRUD the db, manage a queue, process files).
So to that point, here’s 5 characteristics of front-end that make it so hard:
The code you write will execute in a browser environment you don’t own and can’t control and these environments come in a dozen variations.
Browsers implement specs differently (or not at all), which means the perfectly valid code you write may not work as expected, or in some cases you just flat out cannot write the code you want to. But you try:
-webkit-transition: -webkit-transform 1s ease-out; -moz-transition: -moz-transform 1s ease-out; -o-transition: -o-transform 1s ease-out; -ms-transition: -ms-transform 1s ease-out; transition: transform 1s ease-out;
Tools, techniques, and even officially limiting browser support for your app is all necessary to manage that kind of chaos.
The good news is the difference is narrowing. It will never go away because of the way specs are written and adopted by browser vendors, but at least we're past the IE era.
So how does this compare to the backend? One word: containers.
The devices browsers run on can lose network connectivity or hit a prohibitively slow spot in the network at any moment. This is not just a bug you can fix or even something you can prevent. This is a normal every day use case you have to solve for.
Comparably, it is a very rare event that backend systems are affected by connectivity issues, and in many cases it doesn't matter at all because of the client-server paradigm. It’s clients, not servers, that must be robust and reinitiate requests that fail to get through or time out and they need to provide a good UX during these situations.
Front-end projects can almost seem like they have to solve for infinite scenarios:
- The user can try to visit any page - not just what you consider the main page - at any time
- with any device
- with or without logging in.
- If bookmarked, they’ll expect the state of the page to be more or less the way it was when they bookmarked it
- or shared the link with a friend.
- They can navigate away from this page at any time.
- They can refresh it.
- They can clear caches.
- They can use another device without those caches, but still expect to see the same content.
- They can close the page and immediately reopen it, or reopen it 18 months later.
- They can click on anything at any time.
- They can scroll, pinch, rotate, increase or decrease font size, press the tab key, use browser extensions, use private mode, share their account with another person, not have required plugins (Ok, this one is finally over I think...).
- Their OS may have a dark mode.
- They might be using a screen reader.
- It might be a crawler and not an actual human.
- And on it goes...
All of these actions need to be solved for in a way that makes the application secure, reliable, enjoyable, extensible, and maintainable.
This human factor is a challenge for backends too (DoS attack, for example), but only the front-end has to handle the full breadth of human punishment!
This is the pixel-pushing part. It's what many consider to be "front-end" work, but is actually just one of the many concerns.
Today’s designs are more challenging than ever too because of the advancements of the web platform, speed of mobile networks, and the diversity of devices. Take screen size as one example. In college we worked in the reliable 800x600 dimension. Today that screen is in everyone's pocket. We have everything from little phones to big professional 6k displays, and even jumbo multi-screen contexts like the digital menus in McDonalds, which is a web app btw. Screen size alone caused a complete reset in how we approached web design and development, not to mention multi-touch, and now voice is on its way to the web too.
In my experience, graphics code tends to push back harder than regular code and this entire discipline simply does not exist in backend development. As such, backend devs will never know the sheer joy (and pain) of flex box.
I’m curious to know which parts of front-end work people find the most challenging/frustrating.