[aembleton]

> 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.

[agos]

no, a single html attribute containing "relative before:absolute before:top-0 before:h-px before:w-[200vw] before:bg-gray-950/5 dark:before:bg-white/10 before:-left-[100vw] after:absolute after:bottom-0 after:h-px after:w-[200vw] after:bg-gray-950/5 dark:after:bg-white/10 after:-left-[100vw]" is not "easier to read" (example taken at random from the Tailwind homepage)

[oneeyedpigeon]

Just viewing the source of the Tailwind homepage breaks me out in a cold sweat. And then there's:

    > console.log(document.querySelectorAll("body > script").length)
    27

[aembleton]

Easier to figure out what to change without affecting other HTML components, though.

[superq]

Individually applied styles kinda defeats the purpose of cascading style sheets though.

As someone who's quite conversant with regular CSS, I really did like the ease of applying whatever style I wanted right in the code without needing to "worry" about whether this div is a "panel" or a "hero" or whatever, but it really does tend to make a huge mess of my HTML in very short order.

[8n4vidtmkvmk]

Have y'all not heard of css modules or BEM?

[jitl]

pointless make-work compared to inline-styles-like workflow like tailwind, if you have a component framework

[8n4vidtmkvmk]

You might like Styled Components then, if you're using React anyway. Not sure if there's similar systems for other frameworks. I don't consider it pointless make-work to develop a consistent stylesheet to use throughout your app though.

[jitl]

Styled Components is too low-level (let’s name every div!!!) and comes with a substantial performance cost. Tailwind is a much better option.

[presentation]

Use PandaCSS, the result is similar but the syntax is a readable object instead of… that

[skeletal88]

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]

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]

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/

[mablopoule]

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.

[yurishimo]

This is just not true. You can absolutely grep the soup (I do it daily). Most UI components share a lot of common baselines but include a specific modification for use in place (often a color or extra spacing). That means most of the time, the entire class string is unique to that element, even if the classes themselves are not. At most, you might have a couple of duplications, but then you should probably be looking at a template level component if the functionality is related.

`mx-4 py-2 rounded-xl shadow bg-green-500` is just as easy to global-search for as `notice--success`

[jitl]

Use the component library’s inspector/devtools to identify components. Eg in a React app, look at the React component tree rather than the DOM tree

[lawn]

> Easier to read as it's inline with the rest of your HTML

I really don't think a big blob of text with a bunch of unnamed divs is easier to read.

The styles night be easier to find but they're absolutely not easier to read.

[benjiro]

> - Not having to name CSS classes

Most websites are maybe 20 components and localized pages. Not exactly that hard to name and keep constant. Can not think of names, just ask one of the AIs.

> - Easier to read as it's inline with the rest of your HTML

Only if you do a few styles. The moment you have mobile + desktop + dark/light you start to leave lines half a mile long.

> - Not having to manage a separate file and remove unused components

Counterpoint: Components/templates are still the same hell to manage.

> - Being able to use media queries, which I couldn't do in a style tag

CSS ... literally the bread and butter.

> - No risk of changing a class that is used elsewhere. CSS has global scoping which has its benefits but is risky.

Counterpoint: You will end up with styles that are applied to parts, then copied, forgotten to change, and then have a mix of styles that conflict with each other.

And you do not use global scoped CSS, but localized per page. All you need is local CSS + a single parent id/class and voila. Local scoped will not mess with global. Do not do stupid stuff like button { style style style }. No, make global scoped iButton, so you never run into the issue off having parental styles doing funny things to child styles.

Let me introduce our lord and savvier called Nested CSS + Named CSS tags ... Reusable, standardized, ...

Tailscale is frankly a solution for front end JS frameworks, and less for any server rendered html. Use local CSS for html pages that are really local. No need to make global CSS for price cards that you only use on one page. But if something is used over multiple pages, buttons, ... that is global. Simple, no?

Ironically, i am in the process of actually removing Tailscale everywhere because the recent 3 > 4 upgrade screwed so much up. What stayed good? My actual CSS nexted/tag components that i never.

That is one of the issues with frameworks in general, etc, things between versions can really mean a lot more work vs just having everything "basic".

I feel a lot of issue that people have with CSS are more related to not having a proper understanding about CSS, and ignoring some basics. Like do not style base tags. Use nested + custom naming tags, local css + a local id/css and you have no issue with overlap. Best of all, you gain the ability to make easier reusable components as your CSS are the components, not some JS/... whatever call you need to do to render something. It gets messy fast if your breadcrumbs is a components with items, and you need to change something later on. But if its a basic breadcrumbs{} css, adding feature is just a matter of adding naming.

Trust me, took me years to get out of this mindset (and it helped that CSS evolved a lot but most people do not even realize that CSS today != what they know/grew up with)

[65]

Big one: Way smaller CSS bundle size.