This just makes my eyes bleed. CSS-in-JS was bad enough but now you want to mix-in SASS and Tailwind? Is there a prize or something for the number of technologies which can be squeezed into a line of JS? Please stop it.
Overall I think opinions on HN are quite progressive, the only area where I've seen this being different so far is CSS-in-JS frameworks.
I think a lot of people already have an opinion without trying it, oh well.
1. All of a given component’s dependencies and implementation can be viewed/resolved/navigated together.
2. Point 1 also aids static analysis, allowing easier type checking & linting, refactoring, dead code elimination etc.
Makes one wonder if anyone even bothers to learn CSS nowadays. Perhaps we wouldn't have Tailwind or CSS-in-JS if more people did.
Why are there trends in software development? Are we trying to solve problems or we're trying to be trendy? Is this a clothing industry?
I would have thought we should use mature technologies that have been vetted and gone through the trough of disillusionment and onto the ramp of productivity. Proven tech stack that I can rely on gives me peace. Older the tech, the more reliable it is.
The opposite of "trendy" is what we need to popularize and make it cool. It should be cool to use a 5 year old library in JS!
It is cool to use 5 year old JS projects like React. If you look at the projects listed in the report, you see the graphs going back to 2016. Which is 5 years ago. And how they have been popular for 5 years.
Not haphazardly monkey patching anything you see, add emojis to make it look cute and get 30k stars on GitHub.
I want formalization of software development. It is orthogonal to experimentation and trying out fresh ideas.
Change is good. But not towards a local optimum and getting stuck there.
If it weren't so bad, we wouldn't be here.
- css is not scoped by default. Predicting the effect of adding a new rule is very hard if you are not using scoping solutions or if you are not constently writing new class names with a strict convention
- because of the first point, css is never refactored in most places. It becomes an ever growing monster of a code base
- css selectors are build to write css that depends on html. A lot of webapp should be writing html that depends on a small set of css rules in order to get a consistent ui
- the initial "semantic html approach" is counter productive for most webapps. This blog post is a very good read about this particular point: https://adamwathan.me/css-utility-classes-and-separation-of-...
Personally, I'm more interested in HTML as a document format in the original sense. Limited as it is, I just can't fathom the blackout moment where, confronted with a very basic HTML document plus a CSS stylesheet about the same size or more written in a completely different yet redundant syntax, somebody would say "yup, that seems like a reasonable document format for exchanging most of the world's text".
Edit: regarding your scoping requirement, isn't just including the id or class of a component in CSS selectors or, when necessary, sass-like nested CSS rules enough of a scoping mechanism?
The basic approach is to only use selectors with a single class name and nothing else. No child selector or anything.
Then you use a naming convention for class names. The most popular is called BEM (for Block/Element/Modifier).
Sass can help you write BEM class names: https://medium.com/@andrew_barnes/bem-and-sass-a-perfect-mat...
You might use other libraries. Those work by generating class names for you and applying those classes at the right place. There is a whole set of possibilities here: css-modules, styled-component, jss, etc. Some of those libraries use a separate file for writing the css rules (like css modules). Some other libraries ask you to write those rules next to your react/angular/whatever component (styled-component/jss). Those are often called css-in-js.
All of this is only useful when you are making a webapp.
CSS-in-JS solves a lot of problems that people that have been writing 'real CSS' have been experiencing for a long time. Writing CSS for very large applications that deal with lots of shared components across engineering teams is a hard task. Some of those problems are alleviated by libraries like styled-components.
It's not for every use case and should only be used when there is a genuine need (rather than 'because it's shiny.') But shrugging off CSS-in-JS because you don't understand it is a bit silly.
Namely?