Hacker News new | past | comments | ask | show | jobs | submit login

The real problem in my experience is that people who consider themselves to be "real" developers don't care about CSS. I do a ton of code reviews and consulting for companies of all sizes and their JavaScript and TypeScript is almost always at least in a borderline defensible state? But CSS is always one giant file that has been growing since 2002 and is treated as an append-only log of !important. Nobody even tries to fix their CSS because nobody can imagine the concept of "well written CSS". It's like JavaScript in the early 2000s, where the language has (in the minds of developers) to be worked around with stuff like tailwind.



Css scoping has been fixed for ages already by css modules, styled components, or/and (native) support for nested css declarations. If those all fail there’s namespace conventions like BEM.

If your css is a mess in 2024 (2016 really) it is all on the developer and not the language.


Fixing scoping in userland, like with styled components or BEM, is definitely doable but not really the same as having native support for scoped styles in CSS.

There's nothing wrong with those solutions and I've used those and similar plenty, but they are fragile. Those are conventions that have to be maintained and stuck with, and often for scoped style solutions you're also left with a hard dependency on a build step (BEM is an exception there). That may not be a problem at all, if you're using react you almost certainly already have a build and bundle step, but not every project is that way.


You are not wrong. But my god, the tech debt in any slightly older web app's CSS is bonkers. Even with really well thought out templates you still end up with ~5000 line css files that have all sorts of state and magic in them. And like all tech debt, it's a triage.

What I'd really like is more intellisense for css so I could take a css file and get sensible code complete and class suggestions for elements.


you raise a very important point: the tooling around CSS is nothing like we have everywhere else. you can get class completion with Tailwind or CSS Modules (which I prefer), but even basic stuff like CSS Variables or SASS mixins are a black hole


I don’t know what tooling you use, but IntelliJ does all that for me, including autocomplete for variables, HTML elements in HTML files or components, and so on.

If you use the inspections, it can also make dead code removal really easy.


Often I only use CSS if I have no choice. I really do try to fix it but I still cant imagine "well written CSS". I look at the 2000 lines of necessities and know some of it isn't even used and other things could be simpler. The process consumes lots of time without much to show for it or worse.


CSS needs a compiler with warnings, dead-code removal, type safety, modularization, standard structuring and "design patterns" - then software engineers will take it seriously.


We do have tools for that though, how would a build tool fit into a language specification? Aren't those different concerns?


Dead CSS code should ideally be a warning on the web platform. This should be in the spec. Browser can probably emit a warning in the console log if there are CSS selectors that are not used. Authors can choose to explicitly mark with a `ignore-unused`, delete them or move such selectors to separate style-sheets that are loaded by the pages that actually use them. With HTTP/3 this makes more sense (CSS modularization) rather than one single massive CSS for the whole site that just keeps growing over time.


That'd definitely be a useful devtools feature! I don't see why it would need to go through the spec process though, browser vendors could build that independently and get it out much quicker.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: