blog/devaluing-frontend

[utterances-bot]

The quiet, pervasive devaluation of frontend - Josh Collinsworth blog

I keep noticing those of us in the frontend field being treated much the same as nurses, paralegals, and executive assistants. Our work is seen as important, certainly, but just not the same as, or as important as, the “real” work.

https://joshcollinsworth.com/blog/devaluing-frontend

[0xadada]

Brilliant article 👏

I’ve always thought of the software engineer like a chef. The backend engineer is a single-meal chef: they create a single menu. It’s the same meal every night, and the diners are the same diners every night (in this metaphor, the homogeneous meal and diners are the uniform environment that a bacend operates within). it might be a complex menu, but at least it’s well-known and invariate.

The frontend engineer is an ad hoc chef, they have vegans joining the table, in the meal changes every night, depending on what food is available. Cook each meal independently for each diner. (to stretch the metaphor, the vegan might low powered device on a 2G network (constraints) And the food availability could be the mobile device size that needs to be accounted for)

Metaphors aside, front end development is complex because the code is run in a heterogeneous and unknowable environment.

[Hoxolotl]

A combination of the Dunning-Kruger effect and bike-shedding. With predictable results.

This is just a story I might be making up, but it might also be based on the truth, and I'm too lazy to double check: There was a time when American car design teams and engineering teams did not mix. The design time just left room for where they thought the engine should go, and the engineering team had to deal with it. We're talking about the 1950's to 1970's. This resulted in beautiful cars, that had the wrong engines ( under powered or overpowered), guzzled fuel, and only drove correctly as long as it was in a straight line. To this day this is noticeable in car design, where some cars are easy to maintain, and others are a nightmare. Because in the first case, the entire car was designed, while in the second case, it was two separate teams shoehorning whatever they could into a project.

As a full stack programmer I often look with envy at the front end designer who designs a user experience and user interface that's elegant. I know I can't do that (yet) as it is a craft honed over years of experience. Programming the back end is easy by comparison as the computer will tell me explicitly what I'm doing wrong, or where my logic failed to give me the right result.

It needs to look good for anybody to touch it, then it needs to work for people to use it.

[torb-no]

This is some of the best writing I've seen on front-end lately. Thank you so much for writing and sharing this!

I have some thoughts that kinda maybe goest against some of yours here, but they're just some reactions I have. That's one of the things blog posts I really like tend to make me do: have these conversations with myself. So I'm sharing some of those thoughts here, but I just want to be very clear that your blog post is excellent and I'm very happy you wrote it!

---

We tend to treat groups of people as an individual holding an individual opinion and when we see inconsistency we cry hypocrisy. However, it might be that different people are holding those opinions. For instance: I do think maintaining CSS is incredibly hard and is a valid criticism of CSS, but I also think we should take UI and styling very seriously. In fact: that is exactly why I have some of those criticisms.

There absolutely are languages that get harsh criticism just like CSS does, sometimes the specific criticism is even very similar! A good example is C++ (which I'd argue is way harder than CSS to maintain). The interesting aspect though is that while C++ get's a lot of harsh criticism, none of that seems to make people look down on those who program C++. Like you've mentioned I think sexism is probably the explanation here.

Another example we could look at is SQL. A friend of mine mentioned to me how she saw someone forcefully arguing that SQL is not a real programming language. And in that vein we have ORMs, like ActiveRecord in Rails that promises programmers don't need to deal with SQL directly. We've also seen the whole NoSQL-trend where you had databases that used JavaScript-like concepts. Both those trend are on the down these days and most so-called ORMs these days are very thin glue towards SQL. Interestingly I've never really seen SQL have low status as such, just that some people at times have wanted to not deal with it.

I also wonder if we just look down upon UI in general and it's not only in web we find this tendency. Think of all the mediocre desktop UI frameworks over the years like Swing (of Java fame).

On the other hand, while native mobile app development is in a strange spot now with churn that can rival the JavaScript world, I don't see much disdain for UI itself there. Maybe it's because with the web, somebody with zero interest for UI can still make something that spits out a very basic UI. Maybe how accessible programming the web is (at least bare basics) have brought in a lot of people who don't care about UI? Because if you're making an iPhone app you have to consider UI deeply from the get-go.

As for homogeneity: as long as the quality is good I don't think that's always such a bad thing. A more consistent UI can help make things easier for users. In the native app desktop world we used to be angry when things didn't look exactly consistent (it was the web that made more variety acceptable in native apps). I still get your frustration though. One thing is that the quality is often not high, and even if it was, it certainly makes the web a more boring and stale.

Again, thank you so much for writing this blog posts. Excellent stuff!

[webcraftsman]

I thought about your article from last year about Tailwind and the two types of developers: builders and crafters. I think that is what comes into play here. And sometimes the "builders" feel like they have the louder voices.

I don't think the "builders" see the problem. I think "crafters" like me have felt the things you have shared have been true for a long time. It does not feel like you are uncovering a new problem. I think it has been going on for some time. There are times that it gets to me more than other times. I feel the same tension within my own dev team.

And please know that by saying this is not a new problem that you should not be writing about it. I appreciate your observations and it is good to have some perspective outside of the bubble I work in. I think it is good to keep the issue in front of people.

Several years ago, I compared front-end development to that of a contractor. The architect designs the building and the contractor builds it. More often than not, it is the architect, not the contractor who gets the attention. Or maybe the engineer who came up with some solution on paper. But the unsung hero is the one who built it and made it a reality. That is how I see my job as a front-end developer. Most people don't realize what I put into a site to make it what it is. I take pride in a lot of behind the scenes details (accessibility being one) that most people are pretty unaware of.

I used to get bothered more by the fact that what I do is not valued as highly as it probably should be. But I have learned to live with it and be okay with it.

Thanks for sharing your thoughts. Always enjoy reading what you have to say.

[timdelange]

Senior Developers tend to gravitate to the back end. Most developers don't like dealing with people, and the front end is something everyone has an opinion on. Challenging frontend tasks often balance peoples opinions with mismatched requirements from the backend, and crafting pixel perfect screens can be laborious and not particularly stimulating on an intellectual level. Challenging backend tasks are normally things that stimulate engineers. Since the senior staff usually have had time to plot their way away from such drudgery, they have to justify their position by talking in a way that gives it prestige. In reality, its just the big kids sitting in the back of the bus and everyone else wishing they could sit there too.

[ramsey]

I’m also fond of saying CSS is the only language that gets blamed when the author is bad.

PHP has entered the chat.

[josh-collinsworth]

I notice all the comments I get on this post (not just here; lots of them on socials, too) boil down to one of three categories:

1. "Yes, thank you, I see this too"
2. "Don't forget about PHP"
3. "Actually, there is no bias against frontend because [a whole bunch of biased things against frontend]"

[jonathanscleon]

I completely agree. You've covered just about everything, but I'd like to add two more:

1. Because frontend isn't considered serious work, it becomes extremely difficult for frontend devs to get promoted into leadership. It didn't matter that I've written backend code for over half a dozen backend languages and frameworks across just as many industries, or that I've been on call enough that I know my way around cloud infrastructure and Terraform (with the credentials to prove it). For a leadership position that spends 20% of time coding (across the stack) and 80% of time with people, architecture, and logistics, most places I've interviewed and worked with will only consider candidates that have spent 80% of their time with backend code, without needing any understanding of how a page renders (which is...kind of important when you're triaging an issue for an angry customer). Interviews require knowledge of specific details for specific backend frameworks, despite having a team of capable backend devs. Without leadership with frontend experience, you run into the same problems over and over, resulting in the slow predictable decay of a product, until you can finally sell it to someone as an API-only solution.
2. I've noticed that everything above and in the article has fed back into frontend dev circles in a really disappointing and toxic manner. Now, if you want to be a Serious Frontend Developer, you must be writing mostly Typescript, using object oriented programming. We need to emulate Java practices in order to be taken seriously. Between that and the insistence that React is the only tool worth using, I've struggled to find a coworker who's knowledge of the web has made it past 2012. Browser engineers have worked so hard to make our lives easier, and I can't get anybody to care about their efforts, let alone leverage it. It's even affecting the WAI-ARIA working group! "why would you add a click event handler on a ? Devs add them to
   s usually, so let's have the example reflect that". Absolutely horrid.

[jonathanscleon]

didn't expect the html to be parsed in that comment. previous sentence should read "why would you add a click event handler on a label? Devs add them to divs usually, so let's have the example reflect that"

[mikestopcontinues]

Yes, frontend is undervalued. But I disagree with a lot of the reasons you list. I think the primary reason is that, while it's more difficult to be a great frontend engineer, it's also much easier to be a bad one. The barrier to entry is far lower. Most devs enter the industry through frontend.

I don't blame other people for noticing, nor for failing to see the difference in most cases. And I take it as part of the frontend engineer's job to make this distinction clear.

[LucasPilarski]

Frankly, this is the first time I heard that front-end is seen as lesser because of some sexist connotation (not to mention notes taking. I mean: what?). Where this notion came from? To back it up with one study feels like reaching to me.

But alas, for me, the reasoning why front-end is perceived as less is pretty simple: cause it looks like something easy that is done for weirdly high cost. Do we really need React with dozens of libraries - one for the table, one for the form, one for form validation, one for web requests, one for keeping the cache for said requests etc. - to display some tables and handle some forms? Do we really need routing, state management, query toolkits etc. for websites that don't need them and SPAs that should not be SPAs in the first place? A big chunk of web is or feels exactly like that: something small built with heavy construction machinery. Which exists to solve problems created by previous solutions and previous machinery. You even said it yourself: why write CSS when you can just download Tailwind? Why learn vanilla when you can be immediately productive with React? Download 1k npm packages, build something quick and dirty, move on and wonder why backend people are rolling their eyes in disgust.

"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 have been in the industry for almost 10 years. I went from vanilla to jQuery to Angular.js to React and Vue and React again. At this point I don't feel like Svelte is here to make web better. It exists to be better than React, just like React was created to beat Angular.js. There is no real curiosity or joy in learning those tools, because there is nothing new or enjoyable to learn. Maybe when you want to expand your general JS knowledge, but other than that what is there to learn? How to write components differently? A new version of useState, with $ at the beginning? Another mutation of hooks? The most fun I had with learning programming related stuff was when I tried Golang for the first time. It was actually fresh, actually different, required something new out of me, that is not orbiting around the same components-state-styles set of problems. Learning Svelte after React feels like doing the same shit again, just with different syntax for useState() and clearer separation between HTML and JS parts.

[dallasransom]

Computer Science/Engineering doesn't teach anything to do with layout, design or usability so there's a cultural bias against it.

Traditionally, design in software has been dismissed as a luxury. The narrative in the early 2000s was that it was a non-essential, superficial aspect of software development that is typically only used to obscure software product's shortcomings.

There are still shady enclaves in government and large organisation's IT departments that remain loyal to this view, avoiding at all costs the possibility of some hippy-dippy, artsy individual being given undue influence over the outcome of the project.

IT software development is the only industry that is focused almost entirely on developing human centric products that, for some reason, managed to avoid having to adopt a dedicated team of designers that see to all the usability details.

Cars, bikes, phones computers, furniture, houses, buildings - any product requiring more than 3 use cases has a team of designers, exploring product possibilities and ensuring the ease of use. But not IT software development - hence all the rubbish back office software out there that is in some cases responsible for people actually dying.

This is slowly changing. The rise of mobile centric development never goes without a team of designers. But the thing is, peeps, you're always working on a product. A good product has good designers and good engineers. You need both.

[GaoJuqian]

I am an ordinary developer who has been developing javascript in China for five years, and I have a deep understanding of what your article describes. And I'm constantly unemployed, and I'm disappointed in the direction I'm working hard. It's not up to me. I'm already trying to change industries.

[ethan-kaseff]

I thought this article was really engaging and thank you for writing it.

I have seen similar sentiments at my company at large, while it is generally focused on Data Services, the Frontend team, while being it's own "arm" seems generally like the prettier part. That said I work on a team with Frontend and Backend and I don't feel that actively on my team.

I thought the argument around the toxically masculine sexism that is pervasive when approaching secondary/supporting/"inferior" roles like frontend/nursing/paralegal and more was really apt and brought a depth to the article I appreciated.