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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>------------------<p>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...?<p>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.<p>----------