Recently, I see a few articles and people talking about “too much CSS”. Are we at the point where we will have »CSS Engineer« or »CSS Developer« positions on the job market? It would make sense and clarify things compared to »Frontend Engineer«.

There are 548 properties in the CSS spec. 🤯
(…)
How can we practically learn when and how to use all this? —Cory House on Twitter

Sacha Greif’s article is there too much CSS now together with his Futuristic CSS article brought me to these thoughts and now I want to write it up and discuss the concept with you.

Back in the times…

When I started web development in 2004, we used frames, we used Photoshop, Fireworks, and created websites using table layouts, graphics, and basic HTML, CSS, and some JavaScript for the cool analytics counters. We used CGI scripts for forms and comments and hosted everything on some shared hosting service, uploaded via FTP. One person did everything, from server setup to deployment, from graphics to code. It was manageable.

But it was also a very limited web. We didn’t have border-radius, JavaScript wasn’t very capable of doing things, and interactivity was done with Adobe Flash. And here we go: Even back then we had people who specialized in Flash while others focused on coding the website with web-standard technologies (HTML, CSS, JS). And we had tons of wishes, and desires for improved technology: Better HTML semantics, better CSS layout possibilities (and we got float, then flex, then grid, max-width, vw), and styling methods (shadows, transforms, border-styles). Over the years, we got more and more possibilities to create great websites. With that, people started to divide into infrastructure, backend- and frontend developers.

I see myself as a full-stack developer, focusing on frontend development. I have my strengths (performance, semantic markup, CSS, and architecting frontend infrastructures) and my weaknesses (complex JavaScript, SPA engineering, server infrastructure). Many of us are in a similar position, yet on the job market we could clean things up by clarifying.

We live here, now.

Nowadays things are very different. But before we get into more details we have to divide this into two categories: Small websites for normal companies or people and big web services that drive a whole company or software system. And here’s where the clue lies:

For small websites, we need engineers who can code the whole frontend or maybe even do everything on their own, the full stack.

»CSS evolved and we’re beyond the point where everyone can just do it as a side interest.«

But for bigger web services (and that’s where many companies and start-ups are in) we need people who specialize in their area of work. For the frontend we need engineers who build the React app, and engineers who focus on accessibility, on performance, on the styling. For some time we’ve been able to say most people who code JavaScript can also do CSS. But for some years, I had the feeling it’s not appropriate anymore. When I hired frontend people I saw strong JavaScript framework skills while HTML and CSS were only the bare minima or below the standard I expected. So it got them into a Junior position while they may have been Senior in their JS-framework area.

Vice-versa it’s not easy for people anymore to say they’re not great at coding React, Vue, or other frameworks, even if they excel in CSS. Having a job that’s tied to expertise makes sense to me. And since we already have job titles such as »React developer«, »Performance engineer« and others, »CSS engineer« would point out the requirements for the job as well as the strengths of the applicants to recruiters.

CSS evolved and we’re beyond the point where everyone can just do it as a side interest. We all can learn it and build amazing stuff with it, but using it wisely and correctly in a large-scale context isn’t an easy job anymore. It deserves people whose work is to focus on that part of the code.