Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I think one concept that's slowly coming into focus for me is just how many engineers want you to experience _their_ experience and spend your time reveling at how clever _their_ stuff is. As if they think you wake up and want to do CSS work. CSS is not the goal. The website I'm building isn't even the goal. The goal is to solve some problem.

Everything that I have to do to solve that problem is an unfortunate (but inevitable) reality. But let's be clear: the goal is to minimize as close to zero, how much time you have to spend doing these things.

CSS, like all code, is a total liability. I want to spend as little time designing and writing it as possible. Which is why I hate CSS: it demands you know the exact current and future (hahahaha) structure of your webpage. `!important` is not some panacea, but I cackle at the ignorance of suggesting that the user is wrong for misusing it.

View on HN

> Which is why I hate CSS: it demands you know the exact current and future (hahahaha) structure of your webpage.

Replace structure with users, environment or other factor you can't control and you'll realize you must hate every other aspects of development :)

Boy this is exactly how it felt to me as a junior. I was just sure it was the fault of everyone else’s configuration that was the problem, not mine. The hardest lesson a junior has to learn is that the customer is always right. No one cares if your program runs perfectly on your machine, because of course it does, it has to run perfectly on every machine.

Some machines are configured by the devil himself.

This is the concept of Byzantine faults

I think some are configured in such a way the devil itself is perplexed by its sheer chaos.

> The goal is to solve some problem.

but you also have instrumental goals, like you don't want to relearn how to reinvent the wheel every time. you don't want to figure out from first principles every time how to transmit style information next to HTML in a concise way, to apply that to the DOM, etc.

hence the tools of the trade.

and there's an endless iteration of this problem. that's why every new version of each tool helps to do certain things faster, in an easier way, with less code. usually tools focus on trendy things, and as a consequence other things usually become harder to accomplish with the tools (simply because the tools become more complex, their documentation becomes bigger, etc)

there are certain abstractions that are very powerful, work well, sort of simple to grasp and compose (Turing machines, loops, map-reduce, structural pattern matching, types / interfaces, distance vector routing & IP addresses)

and the cascade is somewhere along the spectrum of tools.

sure, it's far from perfect, but learning the basics is okay, it gets the job done, so it's a quite expressive tool.

This is the main reason to use modern methodolgies such as (pick only one):

- css BEM with class only selectors

- css modules

- functional librairies (like tailwindcss)

with those you first write your html, then "apply" css.

The problem is that people don't treat css as code. If you use styled components or css in js you'll treat it as code.

Nobody would change private properties in a js class from outside that class. Same to css, you should not change css attributes from parents. Those are private to their component they are rendering.

If you need that, provide a public attribute to the component and he'll change it's design.

Do this, and css is very maintainable.

Misuse literally means "the wrong or improper use of something", so your statement also suggests the user is wrong...

Reply on news.ycombinator.com