Be prepared before you start reading this article. Because 90 percent of what I write is whining, and the last 10 percent or so introduces best practices for CSS techniques. I gave you guys a shot in advance.

Front-end engineers may encounter the following dilemmas in their career development:

  • At one stage, it feels like the job is not difficult at all

  • The value created for the team is getting lower and lower

  • What we do ourselves, we can do

Raise your hand if you agree. If you are, you are in the majority.

And to be honest, CSS is pretty simple. And I can guarantee that even a fool could write the following code:


p {

color: red;

}
Copy the code

So what do you have to complain about? Stacking pure CSS code requires no skill. And, of course, it’s very easy to just add global styles to a single element, regardless of the rest of the CSS.

So what’s so hard about CSS?

Backend developer: “Although I have finished the new features, I messed up the front end, but rest assured, I have fixed most of them, so you only need to fine-tune the details of the front end, which should take no more than 30 minutes.”

So I opened the HTML file and (to my surprise) found deprecated HTML tags all over the place, with no thought given to responsive design. Take a deep breath, they’ll write slightly better CSS. However, after I opened the CSS file, I found (again) things like fixed positioning, clearing left floats, right floats and! So I slowly put the mouse around my neck. (Don’t stop me, let me die)

Maybe they don’t always write bad code, but I rarely see back-end engineers write front-end code that works. It’s just as well that writing front-end code isn’t the job of a back-end engineer. But please don’t write a bunch of front-end code and expect front-end engineers to clean up your mess.

So what does a good CSS look like?

Organizational structure Especially if you’ve done large projects, the structure of the project really matters. A positive example — Steven Bradley’s directory structure for maintainable code, written for SCSS projects, but also for common CSS projects. It focuses on modularizing CSS files into maintainable files.

Specification. This is probably the biggest problem I face every day. Unfortunately, most engineers have a rudimentary understanding of the CSS specification, which leads to bad CSS code (e.g. Important) Bad street. So how do we avoid it? The following lists a number of naming conventions worth considering to reduce write-dead (very structure-dependent) CSS selectors. Assuming this doesn’t appeal to you, I would advise you to avoid using more than 3 layers of CSS class/element selectors if you don’t have to.

Naming conventions. Impartially, naming conventions are standard for any large CSS project. Without naming conventions, CSS becomes difficult to maintain and unreliable. Naming conventions allow us to easily reuse CSS in a project and, if necessary, weed out redundant CSS in a project. Here are just a few of the more popular naming conventions: BEM, OOCSS, SMACSS and hiccup, which I wrote myself.

The test. At this point, most other engineers probably don’t realize how much fun it is to be a back-end engineer. Backend engineers only need to get one environment (the server on which the website is located) working. You know what the worst part of being a front-end engineer is? 5 + browsers and thousands of mobile devices… Good front-end testing is a chore and takes a long time. I’ve seen a lot of projects get delayed because they don’t take into account the front end testing, which often takes longer than expected.

So how do you reverse this naive view of CSS?

In the future, back-end engineers can no longer be left to chance. As front end engineers, we don’t just throw a bunch of unresponsive CSS code at the back end and walk away. So why should they write useless bad code and then have us patch it when their CSS code fails? I’m not saying we should tell backend engineers to write CSS code well, but we should tell backend engineers not to write CSS if they find it difficult. Don’t let the other engineers think the front end is easy. The front end is not easy. We front end engineers work as hard as anyone else.