DEV Community

loading...
Cover image for 5 Reasons Why Front-end Is So Hard

5 Reasons Why Front-end Is So Hard

jfbrennan profile image Jordan Brennan ・4 min read

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).

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 you’re less likely to get kicked in the groin.

So to that point, here’s 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 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;
Enter fullscreen mode Exit fullscreen mode

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. 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.

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, 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 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.

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.

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?

I’m curious to know which parts of front-end work people find the most challenging/frustrating.

Discussion (57)

pic
Editor guide
Collapse
kalashin1 profile image
Collapse
noclat profile image
Nicolas Torres

I don't write tests for front-end on end projects. Usually a Storybook (or equivalent) is enough as you document all props with examples, so you know when it breaks and fix it. Front-end tests are much of a hassle for very volatile components.

Collapse
javierriveros profile image
Javier Riveros

Agree with you, frontend testing always has been for me a pain

Thread Thread
jackmellis profile image
Jack

I always write tests. I find they're only a pain if you don't write testable code in the first place...

Thread Thread
jfbrennan profile image
Jordan Brennan Author

There’s certainly easy unit testing that can and should be done, UI component tests are relatively easy too, but there’s a lot of real world cases that are really really hard to mock (browser history, latency handling, failing API calls (i.e. the “error” in zero-1-2-1000-error) and unintentional visual regressions can be very tough catch, especially cross-browser and cross-device. All technically possible, but extremely difficult to maintain

Thread Thread
kalashin1 profile image
Kinanee Samson

I find projects built with angular quite easy to test.

Thread Thread
ortonomy profile image
🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝

but you have to hold your nose when using angular. The stink!

Collapse
chuddyjoachim profile image
Chikezie Joachim

That's where it gets harder.

Collapse
clivend profile image
clivend

only if you actually do it

Collapse
kalashin1 profile image
Kinanee Samson

Only with angular

Thread Thread
ortonomy profile image
🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝

to be fair, anything with angular is kinda painful

Collapse
noclat profile image
Nicolas Torres • Edited

Architecture is hard, CSS is hard. It takes years of practice to fully understand CSS subtleties, and even though you've became comfortable, you end up quite often with dies and retries. Architecture may be the most challenging, because a single change in business rules can trigger the need for a big refactoring, no matter how good you've planned ahead potential evolutions.

Collapse
jfbrennan profile image
Jordan Brennan Author

Yeah, still a challenge even today for sure. Lots of popular architectures, but they all seem to fall into one kind of extreme or another.

I’ve settled into a hybrid kind of architecture over the years: barebones Express that handles auth and then bootstraps the main SPA with core data and/or server-renders some other simple pages where necessary, all assets over CDN. Repeat the architecture as your product offering gets too big.

Collapse
matthewpalmer9 profile image
Matthew Palmer

For me, Frontend design is definitely the hardest. I want to create these robust and beautiful UIs, but every time I feel like I've learned something incredibly significant in CSS, it seems that I can't quite break out of the "ameteur" stage. And I can't figure out what techniques are ideal to compensate.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Everyone is a CSS amateur haha

What exactly do you mean though? You never feel like you know enough or you’re not sure how best to apply the knowledge you do have?

Collapse
matthewpalmer9 profile image
Matthew Palmer

A little of both! For me, its a scaling issue. I'll build something that looks really good, but it doesn't pass the mobile test or seems like the entire design is flawed whether it is due to lack of knowledge or just because I'm a horrible designer.

Example: I'm building a Christmas List application. The details of a list item might be so long that I have to set overflow-x to scroll. But then everything looks like shit. 😂 Now I have this weird table with columns and rows that displays data that only looks remotely decent on a desktop, but ends up squished on mobile. And I can't change things to be a column with media queries because it looks even WORSE! I struggle a lot 🤦‍♂️

Thread Thread
fuzzylogic profile image
Lazar

Tables are tough to do on small screens, don't beat yourself up too much.

I don't know your specific case, but there's no silver bullet, it all depends on how big of a pain in the butt your data is.

Here's a pretty decent article that might give you some ideas on how to approach it uxmatters.com/mt/archives/2020/07/...

Collapse
elmuerte profile image
Michiel Hendriks

What part of front-end work is hard for you?

The frontend developers, and their tendency to ignore work in other "fields", change their minds constantly, abandon their work, their complete lack of resource limitations.

Collapse
aarone4 profile image
Aaron Reese

I know your comment was tongue in cheek but there is a large grain of truth. Because FE is so complex they may try multiple approaches, they are in direct correspondence with the end users and their vague and shifting requirements. As a database guy I am only really concerned about the state of the data at the end of a process and although I need to validate the input I don't have to worry about the transient state as we move from Read to Update. E.g. if a user is modifying a customer address in a RESTless client, who validates that the underlying database records have not been modified between the get and patch requests. Or limited stock (like concert tickets) are not stolen by another submit. The UX and anticipating every way the user could screw the process is hard.

Collapse
jfbrennan profile image
Jordan Brennan Author

Haha yeah, especially the last point. I stepped in to manage a flagship project built with Ember and its initial load was 13 MB! Not 1.3, but 13! 😳

Collapse
jadenconcord profile image
Jaden Concord

Always considered the back end to be more challenging because you can't really see what is going on (also I don't do much backend) but I think differently after this article. Also, it is interesting how there are more back end developers than front end ones.

Collapse
feco2019 profile image
Dimitris Chitas

I will agree with your approach ,but i believe both of the fields they have they mysterious complexities..
I can say something straight forward that i believe Front End is not only based to the pattern that you will use but require a kind of aesthetics,that in the back end you dont need to have it so much because you have to deal with structure and reliabillity not with human eyes and UX.
Btw nice topic thumbs up.!

Collapse
jfbrennan profile image
Jordan Brennan Author

Yeah there’s definitely challenges in both fields. I’ve just found backend to be more of a known problem space with reliable solutions vs. front-end being more unpredictable.

Collapse
feco2019 profile image
Dimitris Chitas

This is the right world "unpredictable"!!

Collapse
nano1709 profile image
Ignacio Vargas

CSS really gets my frustration going up day by day.
I think it's something that, even experience people in the field of CSS has trouble with. Just a minor px or a -/+% can screw the appearance of what you are working with...

Collapse
jfbrennan profile image
Jordan Brennan Author

Responsive development should cure most of those issues if you’re not already following that

The CSS that still bites me is overflow. Every once in awhile I painstakingly have to debug an overflow issue that seems impossible, but is nevertheless ruining my layout

Collapse
jackmellis profile image
Jack

Nice article and all good points. For me the hardest thing is a lack of standards/architecture. Most backend codebases I've worked on have had a pretty similar and pretty standardised structure.

Front end code is often just a jumble of stuff everywhere. "Where is your api layer? Where does your application contact the backend for data?" "I dunno it's just wherever". I've not come across this in a backend app.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Haha “it’s just wherever”. Formally known as the AnyWhereAndEveryWhere Architecture

Collapse
tomavelev profile image
Toma

I’ve learned the hard way how, even the so called native platforms (iOS, android, flutter, others), are again just front ends. I hate the over-architecturization of the front with backend stuff, but , there is no escape/going back.

Collapse
eelstork profile image
Tea

On 2, 3, 5, I write here (a little extreme but also: works for me):
hackernoon.com/behaviors-trees-in-...
On 1 (browsers): I quit web-dev while I was ahead, and an article from you suggesting why you like it (if you do) would be very interesting ; )

Collapse
jfbrennan profile image
Jordan Brennan Author

oh I love it! I might just do an article on that, thanks!

Collapse
sharpninja profile image
The Sharp Ninja

You have a lot of misconceptions about back-end work.

1) Containers are no magic bullet for networking issues. Yes, containers can be deployed to multiple locations at once, but cloud service providers rarely offer this for free, and cloud providers are just as susceptible to a regional outage as anyone else. Getting your infrastructure up and running in another region requires replicating the entire virtual resource set in another facility which takes time if you aren't already paying for geographical redundancy (which is the most expensive product on the menu)

2) Async/Await (or equivalent for your backend language) is way more prevalent in backend code that does more than call CRUD procs from REST services. Almost all IO is done asynchronously to improve system performance for all clients accessing backend services, and using parallelism to create results for clients faster is also incredibly important.

3) Unit tests on the backend have to account for the same wide array of connectivity issues as the front end, with the added bonus of ensuring that aborted calls from the client don't cause data errors that break the application.

4) Good data design is hard. Going from a simple key-value database that was so awesome when the app was written in Python, but you quickly outgrow, to a proper 3BCNF or 4NF relational database is a lot of planning and work, not just something that can be thrown together like a bunch of React components.

5) The services suck because browsers still suck. Once upon a time we had standardized services built on standardized technologies with standardized metadata and discoverable directories of these standardized services. But web developers said they didn't like using XML to transmit data and threw out the standards to implement their own standards-less services because the JavaScript engine already had a native parser to get data into JavaScript that bypassed the fact that JavaScript is extremely slow. Now, nearly every application "implements" a REST middle-layer that they try to implement with Swagger/OpenAPI, but the generated clients never work right, so they have to be fixed by hand. Then, when the services are updated the client quits working and generating a new client fails and that client has to be fixed by hand, too.

BTW, if your experience with backend doesn't extend any further than trying to cobble together a REST service in Node, then you really have no idea what backen development is really like.

Collapse
antharuu profile image
Antharuu

I left to criticize, but in the end you're right. Except for the first point in my opinion, which is no longer a real problem nowadays.

Collapse
jfbrennan profile image
Jordan Brennan Author

I’m always right 😎

But is #1 no longer a problem because of all the tools and techniques that are we use to solve it or are you suggesting the latest versions of browsers mean this problem just doesn’t really exist? I’m lucky enough to work in a product that doesn’t need to support pre-Chromium Edge or IE, but those who do still have a lot of problems to deal with.

Collapse
mahtamunhoquefahim profile image
Mahtamun Hoque Fahim • Edited

Whatever you said, I think you said it in my mind. Really, every aspect of your presentation has to be felt by the front-end designers. Luckily there was Google, I always forget, Google it out again !!

Collapse
ortonomy profile image
Collapse
jfbrennan profile image
Jordan Brennan Author

it's both, like hiking!

Collapse
ortonomy profile image
🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝

I just don't find it difficult. I also specialize to a degree in front-end dev. There are challenges, complexities, annoyances, but I don't know about difficulty.

Collapse
keith0305 profile image
Ron • Edited

Supporting IE11. Dude we gotta run a website designed in 2021 on something that was built for 2013. No CSS variables, no CSS grid, no ES6, etc... It is a PITA.

Collapse
jfbrennan profile image
Collapse
renanduart3 profile image
Renan Duarte

the post image were the best haha

Collapse
amrelmohamady profile image
Amr Elmohamady

Frontend middleware authorization!

Collapse
jfbrennan profile image
Jordan Brennan Author

Tell me more. I think I know what you mean and I want to share an approach that might help

Collapse
amrelmohamady profile image
Amr Elmohamady

I am currently building my first Full stack Web App (Nuxt - Express) without watching tutorial, I started it today if I needed some help you will be the first one to know ♥

Collapse
segnova profile image
Joshua Segura

On number 3 can we add user sharing private information?

Collapse
jfbrennan profile image
Jordan Brennan Author

That’s more or less what I meant with users sharing their account, but yeah let’s add it!

Collapse
wallwrecker profile image
wallWrecker

is it possible to write test in the front end especially for the elements to see if they are behaving like we want?

Collapse
jfbrennan profile image
Jordan Brennan Author

Yes, you’ll want to look at tools like Karma, Mocha, Jest, Jasmine

Collapse
wallwrecker profile image
wallWrecker

NOICE.

Collapse
levirs565 profile image
Levi Rizki Saputra

Great article!

Collapse
muzammilaalpha profile image
muzammilaalpha

Agree with you

Collapse
destroyer22719 profile image
Nathan Cai

Coming from a NodeJS background front-end JavaScript is always changing. Whereas with NodeJS, a MongoDB Express course 5 years ago will probably be about 80% relevant today.

Collapse
rishitkhandelwal profile image
Rishit Khandelwal

Styling and adding vector icons.

Collapse
am_rahuls profile image
Rahul

You gave a completely new perspective of web app to me. Thanks Jordan!

Collapse
jscoder17 profile image
Jscoder17 • Edited

Its only hard because damn JS

Collapse
jfbrennan profile image
Jordan Brennan Author

Haha I love JS. Been doing a little Rust lately and whoa!

Collapse
jscoder17 profile image
Jscoder17

i only wana learn rust because this: rustacean.net/