5 Reasons Why Front-end Is So Hard
Im primarily a frontend developer, but have done enough backend work to know what makes the two different. Its 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).
Web applications, on the the other hand, are like wild stallions. The low barrier to entry (HTML, CSS, and JavaScript) makes them appear tame, but large web apps are in fact very very difficult to work with. Many devs get hurt in the process and limp back to other projects where youre less likely to get kicked in the groin.
So to that point, heres 5 characteristics of front-end that make it so hard:
1. Uncontrollable runtime variances
The code you write will execute in a browser environment you dont own and cant 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.
2. Network disruptions are normal
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. Its 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.
3. Users can do anything at any time
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, theyll 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 user 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 many more!
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!
4. Visual implementations
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.
Todays 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.
5. Async processing
Some front-end tasks are asynchronous, which means code does not always get executed in the order you wrote it. Very confusing when coming from a synchronous runtime. This can take a little getting used to; however, the multi-threading experience I had with Java was painful enough that I think I'd take the async JavaScript APIs any day!
What part of front-end work is hard for you?
Im curious to know which parts of front-end work people find the most challenging/frustrating.
Original Link: https://dev.to/jfbrennan/5-reasons-why-front-end-is-so-hard-2b92

Dev To

More About this Source Visit Dev To