Ask HN: Should Frontend(CSS) and Backend Devs Be Paid Equally? A Discussion

4 points by marvwhere 1 year ago | 4 comments

Hey everyone,

We're having an internal discussion about whether there should be a pay difference between top-tier frontend developers and backend developers, or if they should be compensated equally.

In the past, CSS was a skill many could handle. However, in recent years, it has become increasingly complex, with new features being added to browsers almost monthly.

Senior CSS experts argue that there isn't a significant difference in skill level between frontend and backend developers, suggesting that both should be paid the same.

What do you think? How does your agency handle this? Whether you own or work at an agency, we'd love to hear your perspective.

Currently, we pay them the same, but we're reconsidering as we gain more experience.

Looking forward to your insights!

caprock 1 year ago |

The market will determine this based on supply and demand. Look around and see what the median pay rates are for your market.

Pay is sometimes correlated with difficulty and complexity of the task. So high difficulty will often lower the supply of people willing/able to handle the task.

Occasionally, the domain will matter more. More people want to work in gaming, and fewer want to manage systems out on an offshore rig.

efortis 1 year ago |

No two devs perform equally regardless of their expertise.

For example, if you pay all backend devs the same, you’ll eventually loose or miss the higher performers in some way.

cranberryturkey 1 year ago |

I think they both are difficult depending on the stack. At some jobs I've had the backend jobs were super simple...and the frontends were super complex....not always the case but with everything now being pushed to the client side with SPAs it becomes a lot more difficult than maintaining a simple crud api endpoint.

solardev 1 year ago |

If your question is more generally about frontend vs backend, it probably depends on your market conditions, the specific languages in question, your tech stack, your needs, and individual candidates' expectations and skill levels.

For example, a frontend React dev fresh out of boot camp with no real-world experience shouldn't be paid as much as your senior backend person who's scaled many APIs across numerous countries and stacks for four FAANGs.

On the other hand, if your app is frontend-heavy (think Figma or Photopea or Google Analytics), then you would do well to hire someone with significant experience working on business apps of similar clientside complexity.

If you just need a pretty-looking marketing site and blog, that's probably not something you need to hire an entire frontend specialist for; just use Wix or similar or outsource it to a design agency, or get an entry-to-mid level full stack web person.

There's a very high skill ceiling to both fields. All "frontend" means is that it runs in the browser, but these days that can mean anything from "a simple contact form" to a "massively multiplayer 3D game running in WASM and WebGL" because the browser is so powerful. Likewise, "backend" can mean anything from "able to spin up a Wordpress blog on a shared LAMP host" to "senior AWS architect at Amazon". In the past (90s-2000s), everyone was just a web dev or sys admin or whatever. The frontend/backend split really came about because our work (both frontend and back) got so much more specialized and much bigger in scope/scale, not because either side of it is easier or harder. The difficulty is less about front vs back and more about your specific business needs and app architecture.

And in general, you want the two sides to be able to collaborate together effectively on API design, performance, security, UX, accessibility, etc. If one side or the other feels shafted by their teammates, that resentment will build and it's not going to be a great outcome for your business.

I'm not a HR person, but as a developer, what I like to see at companies isn't necessarily "everybody is paid the exact same amount" but that pay and promotions are transparent and fair, meaning posted salary ranges upfront, clearly defined promotion criteria, regular reviews with meaningful feedback, etc. There will always be pay variances between different skills and even individuals of the same skillset, but those are more often due to market conditions than individual ability. We saw huge salary gains during COVID and now we're nearly worthless a few years later; our skills haven't changed, but the market certainly has.

------------------

Also... as an aside... what does CSS mean in this context? Cascading Style Sheets...? It's confusing because nobody is really a "CSS developer" per se; CSS is just one tool in an ever-growing frontend toolkit, usually a secondary skill to the main language someone works in (whether that's React, JS, Rails, PHP, HTMX, whatever). I don't know what a "Senior CSS Expert" is, but the industry hasn't really hired HTML+CSS only positions in a very long time (more than a decade) and as far as I know, nobody has ever specialized in CSS only (unless they were working for a standards body or browser developer). Even in the 90s, it was uncommon to write complex business apps directly in HTML/CSS. Maybe I'm misunderstanding what you mean, or there's another meaning of that acronym...? Maybe a translation issue...?

If someone only knows CSS (and maybe HTML, but nothing else), they're not really a frontend developer by today's standards. They're not really even a developer. I don't mean that as an insult, just that it's not what the market would bear. Maybe a UI designer can get away with that (it would be helpful for them, especially in translating Figma files for developers), but anybody in a programming position would certainly know more than just CSS. You shouldn't really have to pay someone just for CSS; if you need to keep up with the latest styling trends, that's usually more of a question of design and framework usage (eg Tailwind) than a limitation in CSS itself. Yes, the standards change a lot, but they are generally backward compatible, and no production project has to (or should) chase the bleeding edge.

----------