Why is Front End Development So Easy
Why Frontend Development Is So Hard?
It's like Murphy's law every day
Before I begin, a necessary disclaimer:
This article is about web frontend development. I am not an experienced front-end developer. Throughout my career, I have tried my hand on desktop, mobile, and backend development.
Yet, whenever there was a need to try my hand on the front end, I shivered.
I felt excited at the beginning — because the front end gives you an opportunity to see magic on the screen in the quickest possible manner — but that magic didn't last past a few tutorial-level hands-on assignments.
Based on my ideas after my experience. here are my reasons why frontend is quite difficult for an average programmer.
I may be wrong, in which case feel free to drop your feedback in the comments.
1. UI Design Isn't Everyone's Forte
True that many companies have UI/UX designer who works separately from frontend developer, but this is not true in most cases.
On the contrary, most frontend devs are found in agencies that do projects for clients. The UI/UX person is a luxury a frontend dev would have if the client pays for them. In startups, wireframes are mostly created by cofounders, who don't work in tech often.
Worse, the UI/UX person belongs to the client's company. The agency's frontend person is handed down wireframes, and most of their queries go unanswered. Converting those wireframes to the UI that the client manager will love is a task highly dependent on the frontend person's luck.
This brings us to our next point.
2. Communication Is a Necessary Evil That the Frontend Person Must Face
The purpose of most automation is to reduce unnecessary communication. Wherever it is used, it must be done with a proper channel (email) and in proper format (specs, pictures, videos).
Most backend development is CRUD and needs little to no communication after modeling. Strategies like caching and performance improvement require team discussions, but beyond the decision point, there is no need for pixel-perfect specs.
Desktop and mobile UI are strongly demarcated by screens and events. Wireframe/specs serve as the frontend dev's bible.
Not so with the web frontend, where SPAs with too many elements are the latest fad. Clients rarely go beyond providing wireframes, which are not pixel-perfect. Their requirements are often vague, and animations make them harder.
After delivering the first couple of versions, they get to know what they do not want. After ten more versions, they have an idea of what they really want.
By that time, the agency runs out of hours. Our poor frontend person is fighting for their billing, and in hindsight, their job, too.
The story isn't very different in the case of in-house frontend devs. Teams cannot agree on an ideal format to communicate the intended UI. More often than not, backend requests and responses aren't documented well or aren't documented at all. Without a real API in place, frontend devs have to waste a lot of time stubbing fake data. When the real API appears, changes are always inevitable because the format wasn't agreed upon.
Despite their capabilities, frontend people are often at the mercy of backend developers to deliver even the tiniest piece of work.
3. Big Wigs Make the Changes; Small Devs Suffer From Them
This is true in any business of the world. However, in the case of web frontend devs, this is much more frequent.
In any other area of software development, your previous experience provides you with the most necessary assets: The libraries and the modules that you already made. Those are reusable. Once you master them, you can scale your work to gain better opportunities.
Even when compatibility breaks, your code needs minimal fixing. It is only the package files and cloud images that you need to fight with. You can squarely fix the blame on things you didn't code.
If nothing works, you could always go back to the non-JS world where things remain the same for long times.
Not so with the web frontend.
The web frontend packages have the largest blast radius. This is because of the following:
- They are client-facing.
- Changes in any of the following can trigger your UI to halt functioning:
- Browser (aka HTML) standards
- Browser updates
- Framework changes
- Javascript changes
Examples of crises that frontend developers must face every day:
- Privacy changes? Have the frontend person implement the consent box. Not loading fast? Blame them.
- Your latest ad network hiding your product video? Catch the frontend person who last changed it.
- Visits down past the last Google update? Let's blame the frontend person who changed the SEO meta tags.
The root cause of all these crises is that everything gets tested only in production. This is also a major reason why many companies decide against hiring an in-house frontend person and decide to rely upon agencies that are not only cheaper but also easy to blame.
The web browsing experience has gone 100x down in the last decade, thanks to wars between government regulations and companies who control the web and advertising. Yet, every time even a non-paying user complains, the frontend person bites the bullet.
Most of the war is fought on the turf of the GitHub issue pages of the popular open source frameworks/libraries: Angular, React, Vue, and so on. But they don't hold direct accountability for every frontend dev's problem, because they are open source. Because of their indifference, it is quite difficult to trace an average frontend person's problem against bigger root-level changes.
If you have jumped on the latest framework's train, you end up contributing to GitHub issue pages or StackOverflow answers. Your task must take a back seat. Your only chance to be in a stable position is to forecast problems in your codebase along the lines of those root-level changes.
If you didn't board the train soon enough (i.e., you are searching year-old SO questions about a problem), you might be a caveman already. In the frontend world, this sentence is almost a cliche:
It's year 20xy, buddy, you still use 20x(y-1) framework?!
Needless to say, web frontend people fight for their survival harder than their programmer peers. Their interviews are stuffed with extremely subjective choices and volatile standards, and most competent developers often face the dreaded rejection.
Conclusion
HTML was invented to be a declaration-based UI-making standard. Instead, it is continually forced to be handled by browser makers who want to offer novelty and big-tech programmers who want uniformity in everything.
Sadly, UI isn't always about either of them. Businesses often want their UI to be predictable, yet stunning and performant at the same time. Naturally, they do not understand the tech challenges that a frontend person must face.
Despite not being a web frontend person, I tried to list out the high-level problems every frontend developer must face. While many of those problems also exist in other software domains, the nitty-gritty nature of UI makes them more of a challenge for web frontend developers.
That is at least my opinion from my limited knowledge about frontend development.
If you have any more to add, or have different opinions, feel free to comment.
Source: https://betterprogramming.pub/why-frontend-development-is-so-hard-c055bce2fd3a
0 Response to "Why is Front End Development So Easy"
Post a Comment