[prinny_]

I am a FE developer and I believe that we collectively have a loser's mentality when dealing with CSS.

In my mind, SCSS + CSS modules + maybe a processor tool is an rock solid and modern set of tech that produces excellent results and most importantly moves styling off the main thread. It makes sense to use it, but we don't. FE interviews even for senior+ roles are JS/React/system design questions. Nothing about CSS and I get it. Why interview for something you don't use internally?

I recently read something that stuck with me, which was about micro front ends but I think applies in more cases than this: "it doesn't solve a technical problem but an organizational one".

There was an excellent reddit discussion on the pros and cons of tailwind and it boiled down to "it's really hard to enforce CSS guidelines for teams of multiple people". Tech leads didn't want to monitor how 10 or 20 or 50+ different FE developers wrote CSS and opted for tailwind so that everyone wrote the same, even if that meant multiple inline classes pasted on each element. I find this reluctance to enforcing guidelines weird, considering at $WORK we have multiple confluence pages and internal documents about React and Javascript guidelines and I have seen similar documents in previous work places. Would it be really different to apply the same mental paradigm for CSS?

Of course, all this is under the hindsight knowledge that HTML and CSS have evolved in recent years to be truly powerful and versatile. I get the technical decision to go all in on JSS and React 5 years ago. I don't now.

[zelphirkalt]

It seems to me, that many FE devs don't even know CSS these days. Rather just tack on some "ready" made component found on NPM or some component library. When it actually comes to using CSS to fix something about part of a page or part of a component, I often see non-responsive ways of doing that, badly tested across browsers, breaking at some width of the viewport, etc.

In my view CSS is essential. Not knowing CSS at least somewhat well is a huge obstacle in producing high quality frontend work. It's like being a carpenter, but simply not knowing one important aspect of wood, or not being able to use a specific tool to work with wood, lets say a tool to smooth surfaces. CSS is part of the medium you work with as a FE engineer. It is unfathomable to me, how a FE engineer can not know this stuff well. If some FE engineer is reading this, and feels some impostor syndrome: Yes, if you don't know your medium and tools as least in the basics, then you should feel like an impostor.

I see broken responsiveness very often. Of course in almost all websites, that rely on JS to display what is essentially a bunch of static texts.

If I was interviewing for a FE position, and really had to go through the circus of asking interviewees code questions, I would definitely include a minimum of CSS knowledge there. Basic things like how they would scope their CSS to specific elements or classes of elements and how they would prevent their styling to bleed into other stuff. Or how they would set up a theme with just CSS. Not questions expecting them to write CSS on a whiteboard, of course. Just testing their basic understanding.

[epolanski]

The overwhelming majority of devs out there absolutely do not understand the Dom or css.

I have interviewed FE devs and from years they are absolutely unable to implement a native form.

[troupo]

> In my mind, SCSS + CSS modules + maybe a processor tool is an rock solid and modern set of tech

"my set of non-standard tools and preprocessors is superior to these guys' non-standard tools and preprocessors" is not a good argument.

> I find this reluctance to enforcing guidelines weird

Because CSS doesn't lend itself to any enforcement. All the tools that appear around it includng those you like like SASS and "some processing" don't appear because people don't understand something or can't enforce something.

> Of course, all this is under the hindsight knowledge that HTML and CSS have evolved in recent years to be truly powerful and versatile.

Indeed. And many of these features have been made available across all major browsers only in the past two or so years.

No one is going to rewrite everything from SASS or CSS-in-JS just because some features now exist in vanilla CSS.

[prinny_]

I never said we have to rewrite existing apps and I explicitly mention that these improvements are recent. You come off as overly sarcastic and irritating in an otherwise civil thread.

[Tade0]

I share this sentiment.

CSS modules are really enough - there's no need to overthink it any further.

I'm currently in a project where my first task, spanning several months, was to clean up after the previous guy. The main issues in styling were misguided attempts at sharing styles implemented via breaking encapsulation.

[aduty]

If you have a workplace (not just a manager or even a set of them but an entire organization or subset thereof) that is allergic to punishing people then it's easier and less headache inducing to just tell everyone to use a particular framework with a set of customizations to maintain some semblance of unity. This is true if large teams and small "teams" that are overburdened with lots of disparate projects.

Should they be allergic to punishing people? No, but it be how it do.

[marcosdumay]

> I find this reluctance to enforcing guidelines weird

It's worse than that. All the hype in design has been about creating a global design language, and enforcing it over all your teams for more than a decade now. All the hype has been on centralizing the design team, moving it away from the developers for some years. All the hype has been on tools that claim to enable reusing and distributing that work...

And yet everything is done in a way that developers have to do everything themselves and don't get to coordinate with each other.

(Honestly, I'm settling on the opinion that non-developing application design is a scam all around.)