Premise
What follows is a response to the beautiful article by Josh Collinsworth that you can find here.
I decided to structure this content by taking each summary quote he makes in his article and responding to each of them with my opinion.
This article is therefore to be considered a series of ideas that identify a personal opinion. Of the 12 quotes reported, I found myself agreeing with ✅ 8 of them, disagreeing with ❌ 3 and having no opinion on 🟡 1.
[TL;DR] I generally agree with the author’s opinion and his point of view, although in some cases the distorted view created by the article has led me to disagree with some statements. The analysis on prejudice has caused, in my opinion, just as much prejudice towards the world of development on the part of the author.
I feel like I’m seeing a widespread diminishment of the practice of frontend. Nearly everywhere I look, I notice its importance minimized, and its challenges trivialized.
✅ I fully agree with this statement.
The frontend has for too long been considered the “little brother” of the backend, and this is a mistake. The frontend is the part of an application that the end user sees and interacts with, and is therefore fundamental to the success of a product. Its importance cannot be underestimated, yet this happens too often, and I myself have sometimes considered my work as a frontend developer “inferior” to what I did in the backend.
Why does this happen? From my point of view, I believe it is because in the last decade the world of frontend development has been invaded by frameworks and libraries that have made work simpler and more accessible to everyone. This has led to responding to many of the problems that arose in the past, leading frontend development to become “simpler”. This has led to a devaluation of the role of the frontend developer, who is often seen as a “code monkey”. Simple, however, does not mean easy, and the frontend developer is often called upon to solve complex problems and make important decisions, precisely because he or she is no longer expected to resolve “simple” problems, already solved by the framework, but rather to enrich the user experiences in new and innovative ways.
It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.
✅ Here too, I agree.
CSS is one of the most underrated and devalued languages in the world of web development. CSS is a powerful and complex language, which allows you to create complex and detailed user interfaces. However, the distance from the normal way of writing code, its particular syntax and its operating logic often make it difficult to master and use. CSS is a language that requires time and dedication to master, and what happened with the CSS-in-JS movement is a clear example of how the community tried to solve a problem that didn’t exist by creating a new one, while also adding abstraction to an already very complex language.
In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?
✅ I agree.
As mentioned in response to the previous quote, I believe that the problem with CSS is due to its operating logic and its particular syntax. The problem is that it is often seen as a “secondary” language compared to JavaScript, when in reality it is a language in itself, with its rules and peculiarities, and requires a learning time comparable to that of a programming. CSS is a powerful and complex language, and its role cannot be underestimated.
Mostly, nobody actually says frontend is less important, or less real, or that you don’t have to be as smart to do it. But it often seems to be implied.
✅ I partially agree.
To tell the truth, I see this theme as much more explicit than the author says. In fact, I often find myself having to debate with people who consider the frontend to be a “minor” job compared to the backend, and who believe that the frontend developer should not be a programmer, but a support to those who do the real work, the backend. When they ask me what my role is, I always answer Full-Stack, because in my training and growth there are various and different elements, and both sides of the coin have been important and significant for me.
I believe the community needs to do more to eradicate this mentality. The frontend developer is a professional in all respects, and his work is fundamental to the success of a product.
The frontend developer is called upon to solve complex problems, supported by constantly evolving tools — which greatly increases the cognitive load — and to make important decisions that directly influence the user experience, the bulwark of a successful product.
Our output is artistic, to some degree, and artistic things have a long, storied history of being tragically devalued merely because they seem simple and enjoyable.
✅ I agree.
Lack of understanding of roles and responsibilities plays a fundamental role in our industry. The frontend developer is often seen as an “artist”, a “creative”, and his work is devalued because it is not “technical” like that of the backend developer. This is a mistake in two respects.
First of all, it is often not the frontend developer who decides the design of an application, but the designer (UX, UI, call it what you want). The frontend developer is called upon to translate the design into code, and to do so in an efficient and high-performance way. This requires technical skills and specific knowledge, which go far beyond simply writing code.
Secondly, as already mentioned above, the responsibilities of a frontend developer often go far beyond simply writing code. If I modify code in my backend application, the automatic tests will most likely notice any regressions sooner than I can. If I modify code in my frontend application, it is very likely that the only way to notice any regressions is to manually test the application or wait for a report from end customers*. This makes the frontend developer’s job much more complex and demanding than one might think. Not to mention the amount of business logic and state management — both promptly poured into the frontend — which make the role increasingly integrated with the business.
*Note: I am well aware of the existence of end-to-end tests, but their implementation is much more complex and expensive than traditional automatic tests, furthermore their reliability is often questioned due to their random and external conditions.
The language implies interfaces are decoupled from the software, and not an actual part of it.
🟡 No opinion on this.
The reference here is to the paradox whereby in our sector there seems to be a difference between Developer and Engineer and which must necessarily be shown as something more. I have no opinion on the matter, but I agree that nowadays the proliferation of titles and banners does nothing but muddy the waters with respect to what each of us actually does.
Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.
✅ I agree.
As already mentioned previously in this article, I agree about the incorrect devaluation of CSS and the frontend world in general. Furthermore, in this part of the article, reference is made to the chauvinism present in our sector, and although I have never had a direct perception of it, I understand its reality and gravity. Our industry is still too often a hostile environment for women, and I believe the community needs to do more to combat this mentality.
As though the nearly impossible job of supporting every possible device, operating system, screen size, browser, user preference, and interface in the past, present and future is so simple we invented all the complexity ourselves, just because we were bored.
✅ I agree with the intrinsic meaning of this statement.
The complexity of today’s world makes the role of the frontend developer even more complex than it has ever been, and when frontend jokes and punchlines become bias, it’s easy to fall into the trap of devaluing the work of frontend workers.
Yes, as a group, we get excited about new things. But why doesn’t that make us curious, or adaptable, or inquisitive? Why don’t we get credit for our joy of learning, instead of denigrated for refusing to stay in place?
❌ I agree less with this one.
Although it is true that the evolution of the frontend world — as already mentioned previously — has led to a proliferation of ideas, tools and methodologies, Shiny Object Syndrome is a real and widespread problem, especially in the frontend community. This doesn’t mean that you shouldn’t be curious or adaptable, but that you often fall into the trap of adopting new technologies without fully understanding the pros and cons, and without evaluating whether they are actually necessary or not.
If our skills are valuable as duct tape over the cracks of organizational shortcomings, why aren’t they valuable during the planning and decision-making that led to those defects, when we could potentially prevent them?
✅ Totally agree.
Exactly as a Software Architect (Or Tech Lead, or whoever is in charge of the architecture) must involve every member of the team in the architectural choices — despite having the last word and ultimately the responsibility over them -, also the decision-making process that leads to the creation of an application or part of it should involve every member of the team, including frontend developers. Those who have been doing this long enough may be able to find gaps in the user experience or design that others wouldn’t see, and involving them in the decision-making process can lead to a better user experience and a successful product.
Frontend tools market themselves as though frontend is something no one wants to do, and nobody should care about any more than they have to.
❌ You can clearly see the frustration increasing as the post develops, but in this case I can only disagree.
The marketing — as Josh defines it — of frontend tools has never trivialized or tried to simplify the challenges of developers, except for a few rare exceptions. These tools increasingly aim to make the frontend developer’s work simpler and more efficient, but never banal, and it is right that the direction remains the same. The promise is never to make the frontend developer a code monkey, but to allow him to focus on what is truly important: the creation of a successful user experience and the impact on the business and the world around him . The same goes for the backend world, where tools have evolved to allow developers to focus on the product, rather than on technical choices or configuration issues.
Finally, let us remember that the world of Developer Relations has developed in a structured manner in recent years, and any missteps by some companies should not be considered the norm.
It seems like nobody thinks of frontend as a critical part of the product anymore; they only think of it as the nice box the product arrives in.
❌ Here too, alas, I disagree with Josh.
The frontend is a fundamental part of a product, and its importance cannot be underestimated, but that doesn’t mean you necessarily have to indulge in complexity and abstraction. Frontend development is already complex enough to not require super-sophisticated design or abstruse architectures, and exactly as in the backend world, standardization, if done with full knowledge of the facts, allows us not to add unnecessary cognitive load and to focus on other aspects of the product.
Top comments (0)