6 ms·

CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step in

CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step involved, and it avoids cluttering your markup with excessive code. You could opt to use style attributes directly within your HTML. Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes? Using style attributes even seems more straightforward since it doesn't require translating code in your head. I simply don't see the appeal.

morbicer 2y ago
There's a bunch of things you can't do with style attributes, just to pick a few: - Pseudo-classes (e.g., :hover, :focus) - Pseudo-elements (e.g., ::before, ::after) - Media queries - Keyframes and animations And the DX in a larger project isn't great either. On the other hand, this upcoming standard is a great addition for collocating styles https://developer.mozilla.org/en-US/docs/Web/CSS/@scope https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
- nilslindemann 2y ago
  https://developer.mozilla.org/en-US/docs/Web/CSS/@layer https://developer.mozilla.org/en-US/docs/Web/CSS/@layer also solves a lot of problems.
  - jeanlucas 2y ago
    Indeed, it also solves a lot of problems
tipiirai 2y ago
It's because we've normalized React and tight coupling. Styling belongs to components, not in design systems. I feel the JavaScript-first engineering ecosystem needs brave new design-led companies, who see the power of modern CSS and systematic design.
aembleton 2y ago
> I simply don't see the appeal. - Not having to name CSS classes - Easier to read as it's inline with the rest of your HTML - Standardised way of naming so that everywhere uses the same conventions - Not having to manage a separate file and remove unused components - Being able to use media queries, which I couldn't do in a style tag - No risk of changing a class that is used elsewhere. CSS has global scoping which has its benefits but is risky.
- skeletal88 2y ago
  The problem is that with bootstrap I have card, table, etc. With tailwind I have an unreadable alpabet soup when I am not a designer but a developer and am not familiar with tailwind.
  - Ralfp 2y ago
    And then you build on that, and you have card-alert, card-message card-message-small, card-body-alert, card-body-message, card-form, card-login-form together with extra sass variables for them. And then you ask "why not just have variable for each component, not each component's style?" and this is where tailwind steps in.
  - gedy 2y ago
    I greatly agree with you, but should mention that there is DaisyUI which is a Tailwind plugin that adds these for you. It seems inspired by Bootstrap and others: https://daisyui.com/ https://daisyui.com/
  - mablopoule 2y ago
    This is the big one for me. In any big enough or unfamiliar frontend project, my go-to way to explore the codebase is to launch the front-end, and use the inspector to check the elements, and then search-back in the codebase the relevant classes to see what page/component display that, and how does it fetches the data. If there is only an alphabet soup, I no longer have a simple set of classes I can grep the codebase with to quickly find the relevant components.
itzami 2y ago
> Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes? In bigger projects, if we start looking at the amount of files one has to deal with, Tailwind becomes very appealing. We've went through the regular `.css` route but then you have weird names, and, potentially, duplications or even conflicts. `css modules` is an option but you've now essentially duplicating the number of files that you have for each component / page. `sass` or `less` essentially bring the problems from `css modules` and regular `.css` into one. I don't inherently like or dislike Tailwind (although I very much started by absolutely disliking it) but you feel its value in a project with 200+ files composed of components and pages
dbbk 2y ago
You're seriously advocating for inline styles in the year 2025, it does not surprise me you are confused.
jitl 2y ago
These days tailwind is often paired with a component abstraction system that takes place of css classes as an abstraction system. Component abstraction achieves an even more powerful separation of semantics from styling, compare: <h1 class=hero>Cool page</h1> vs: <Hero>Cool page</Hero> In both cases you need to go find the “hero” abstraction, but in component world we are also abstracting over the HTML tag name in addition to whatever styling stuff. When it comes to defining the “stylistic detail” in either case, it has been separated from the “content” which is our page source file. I am happy to pay a build step to get better separation of concerns - content from presentation.

morbicer 2y ago

There's a bunch of things you can't do with style attributes, just to pick a few: - Pseudo-classes (e.g., :hover, :focus) - Pseudo-elements (e.g., ::before, ::after) - Media queries - Keyframes and animations And the DX in a larger project isn't great either. On the other hand, this upcoming standard is a great addition for collocating styles https://developer.mozilla.org/en-US/docs/Web/CSS/@scope https://developer.mozilla.org/en-US/docs/Web/CSS/@scope

nilslindemann 2y ago
https://developer.mozilla.org/en-US/docs/Web/CSS/@layer https://developer.mozilla.org/en-US/docs/Web/CSS/@layer also solves a lot of problems.
- jeanlucas 2y ago
  Indeed, it also solves a lot of problems

tipiirai 2y ago

It's because we've normalized React and tight coupling. Styling belongs to components, not in design systems. I feel the JavaScript-first engineering ecosystem needs brave new design-led companies, who see the power of modern CSS and systematic design.

aembleton 2y ago

> I simply don't see the appeal. - Not having to name CSS classes - Easier to read as it's inline with the rest of your HTML - Standardised way of naming so that everywhere uses the same conventions - Not having to manage a separate file and remove unused components - Being able to use media queries, which I couldn't do in a style tag - No risk of changing a class that is used elsewhere. CSS has global scoping which has its benefits but is risky.

skeletal88 2y ago
The problem is that with bootstrap I have card, table, etc. With tailwind I have an unreadable alpabet soup when I am not a designer but a developer and am not familiar with tailwind.
- Ralfp 2y ago
  And then you build on that, and you have card-alert, card-message card-message-small, card-body-alert, card-body-message, card-form, card-login-form together with extra sass variables for them. And then you ask "why not just have variable for each component, not each component's style?" and this is where tailwind steps in.
- gedy 2y ago
  I greatly agree with you, but should mention that there is DaisyUI which is a Tailwind plugin that adds these for you. It seems inspired by Bootstrap and others: https://daisyui.com/ https://daisyui.com/
- mablopoule 2y ago
  This is the big one for me. In any big enough or unfamiliar frontend project, my go-to way to explore the codebase is to launch the front-end, and use the inspector to check the elements, and then search-back in the codebase the relevant classes to see what page/component display that, and how does it fetches the data. If there is only an alphabet soup, I no longer have a simple set of classes I can grep the codebase with to quickly find the relevant components.

itzami 2y ago

> Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes? In bigger projects, if we start looking at the amount of files one has to deal with, Tailwind becomes very appealing. We've went through the regular `.css` route but then you have weird names, and, potentially, duplications or even conflicts. `css modules` is an option but you've now essentially duplicating the number of files that you have for each component / page. `sass` or `less` essentially bring the problems from `css modules` and regular `.css` into one. I don't inherently like or dislike Tailwind (although I very much started by absolutely disliking it) but you feel its value in a project with 200+ files composed of components and pages

dbbk 2y ago

You're seriously advocating for inline styles in the year 2025, it does not surprise me you are confused.

jitl 2y ago

These days tailwind is often paired with a component abstraction system that takes place of css classes as an abstraction system. Component abstraction achieves an even more powerful separation of semantics from styling, compare: <h1 class=hero>Cool page</h1> vs: <Hero>Cool page</Hero> In both cases you need to go find the “hero” abstraction, but in component world we are also abstracting over the HTML tag name in addition to whatever styling stuff. When it comes to defining the “stylistic detail” in either case, it has been separated from the “content” which is our page source file. I am happy to pay a build step to get better separation of concerns - content from presentation.