Things we’re not used to tend to be harder

I’m a developer, and I CSS. I probably have written more CSS than I have written Java, Ruby, PHP, Python and JavaScript combined.

Being a front-end developer is a dying art. By front-end I don’t mean ES6, Babelifyied React SPAs. I mean meat and potatoes: “here’s a design, turn it into a website please”.

CSS doesn’t get the love it deserves in the developer crowd. I think I know why that is: it’s hard. Especially coming from the fairy land that is Java/JavaScript/Ruby/PHP/insert language.

Now I’m not saying all these languages are easy by any stretch but CSS always throws up issues that stump me… for a good while.

1. The difficulty of a declarative language

CSS is a purely* *rule-based language. In a world where we write mainly Object-Oriented or procedural code, this does not sit comfortably. It’s just not the paradigm we’re used to.

Developers tend to struggle going from procedural to object-oriented programming and from OO to functional programming.

Changing paradigm means a change in mentality and that’s just not everyone’s cup of tea.

In CSS:

• The rule declared last will take precedence.

• The rule declared on the most specific selector takes precedence.

• There aren’t any looping constructs.

• There aren’t any scoping constructs.

This is nothing like your Java, PHP, Ruby, C.

Which brings us to the second strand of CSS issues.

2. No scopes

CS 101: Avoid global things… impossible in CSS

By default, a CSS rule is global. Now computer science tells us: “avoid global things if you can”… which you can’t in CSS.

To simulate scopes you either have two choices: pre-processors or methodologies.

Pre-processors like Sass, LESS or Stylus mean you can simulate scopes. You nest selectors so that changes on one page don’t affect other pages. This essentially outputs what some would consider bad CSS. And it comes with its own issues:

• nest too deeply and you’re going to get performance/readability issues

• you need a build tool to compile from your pre-processed language down to CSS

And that spells one thing: more complexity hence more trouble.

Methodologies like BEM, and OOCSS allow you to avoid the scoping issues at the cost of learning and rigorously applying the methodology. Style guides help, but really it’s a case of making do with a pretty hard to use language.

3. Purely semantic

CSS is completely semantic. Since we’re saying “this looks like this” in our code, the only way to test it is to make sure “this looks like this”… which is quite hard.

Automated testing CSS? Unless you have a lot of time and want to go with webdriver > browser > take snapshots > compare the images… well, you can’t really. You just have to measure as best you can, usually with your eyeballs.

Refactoring CSS?

“Just rewrite the whole thing”.

Extending CSS?

“Wing it and hope for the best”.

If it looks right, the CSS is right. Which means the only way to be good at CSS is to be good at CSS.

4. Quirks

CSS has a ton of quirks. Different browsers implement things differently and have different default styles.

This can be fixed with frameworks (or reset stylesheets), which are costly in terms of page load-time.

Conclusion

Writing good CSS is hard, it needs to look perfectly right across browsers and devices. Worst of all, any random person can tell you your CSS is off. I’m guessing the average client won’t be trying to hit the edge cases of your server-logic. Which all contributes to a high-pressure, medium-reward environment for front-end guys.

That’s why it’s so hard to find front-end web developers who can do the basics right. Getting the basics right is time-consuming and doesn’t pay half as well so why even bother?