If you are a developer, you have heard this statement at least once. While I believe that any comparison is pointless because everything is about programming, I’d like to add some complexities often neglected in frontend development, within the context of client/server software.
Take it seriously
Frontend is not a toy. What I find frequent in frontend developers is the recklessness of their choices. Backend developers tend to be more conservative because they are the ones receiving that phone call at night when a service is down, but this doesn’t mean that a frontend bug couldn’t have terrible consequences.
Some people claim that backend is harder than frontend because of the “more serious” problems it has to solve:
- Performance
- Scalability
- Robustness
- Concurrency
For some reason, those qualities are considered less of a priority for a well-written client, but they are equally important and sometimes more important. Users may spot slow, sluggish, power-hungry, buggy apps from a distance.
It’s also true that if you skip native backend software like web servers or databases, which are a big deal, most developers out there are doing simple web services. Let’s be honest: nowadays, most of the above difficulties are not dealt with at the programming level, they are delegated to long-established SaaS platforms. This is great, but only because backend developers are –in my experience– generally more aware of how things happen under the hood.
Sadly, frontend frameworks lead developers in the opposite direction: they make you forget the consequences of bad programming practices. They deviate from the importance of appropriate data structures and algorithms. They convince you that modern machines can endure any load. They overcomplicate code with tons of boilerplate. They waste your time moving your focus on things that nobody cares about e.g. “is that a view or a view model?”. They make you lose the foundations of programming.
The result is a far west full of cowboys writing inefficient, dangerous code, but this is not a problem of the frontend itself.
Never rely on a backend
Not all apps are web-oriented, and Passepartout is an example of frontend development without a backend. Or, better said, frontend development with an uncontrolled backend.
What does this imply? You take direct responsibility for your software. In a world where most apps interact with external APIs, it’s appalling how often frontend developers operate in the best-case scenario where everything works as expected.
I wonder how many write code that, to name a few:
- Expects malformed responses
- Expects no responses
- Handles timeouts
- Works fully offline
- Works headless (without views)
- Migrates persistent data without data loss
This is your responsibility, not the external backend’s, and you do that by giving your frontend a local backend with business logic to rely on. At that point, the presence of an external backend will be of marginal importance.
Domain before UI
Business logic is another concept that, historically, the backend is more used to than the frontend. I believe that backend developers don’t see the immediate effect of their work until late, whereas it takes a few minutes to create a meaningful UI. The instant gratification that comes from “it works!” may indefinitely delay the key decisions to take early in software development.
Presentation is the highest layer in software design, yet in frontend development, the importance of UI is constantly glorified. No surprise, non-tech people and the industry in general judge software from the UI, but frontend developers should prioritize the domain like any other non-UI developer does.
Any software should make sense regardless of having a UI, or a remote API, and frontend makes no exception: UI is no more than the visual representation of a domain. I believe that this simple rule also dignifies frontend apps for making them way more meaningful than “a couple of screens”.
Troubleshooting
How much time do you waste interpreting users’ feedback for the lack of better options? What if you are in a real hurry to solve a frontend problem in production? Clients live in the most unpredictable environments, yet the troubleshooting of their errors is often deferred to backend monitoring.
Logging, proper error handling, profiling, and tracking tools are a superpower, but as long as the backend takes care of that, the frontend couldn’t care less. Drop the backend, and troubleshooting becomes a nightmare. Along the lines of “never rely on a backend”, do your homework and invest decent time in logging at least. Make it a requirement, even more than tests. It’s tedious, it’s time-consuming, but it truly pays off when SHTF.
Logging is a fundamental trait of software robustness, and it takes a lot of practice to describe what code does through human-readable text in a way that will help your future self later. No software is exempt from the need for logging.
In conclusion
Frontend is the face of our product, but UI is only a small part of it. Over the years, the overuse of client-side JavaScript frameworks has made frontend software less of an example of good software design. At the end of the day, though, all design principles still apply, and frontend development deserves the same care and rigor as any other layer of software development.