6 ms·

Not having to name a myriad of things! Sure, things like BEM can help you at least avoid naming conflicts, but you still have to decide a few thousand times wha

by 9dev 1y ago

Not having to name a myriad of things! Sure, things like BEM can help you at least avoid naming conflicts, but you still have to decide a few thousand times what something is called semantically correct, in a way that you and your French colleagues and the intern of next year are going to understand it. When I got productive with Tailscale, I finally realised how many brain cycles I wasted on this. I’m, like, a programmer; of course I’ll obsess over picking the perfect name. Of course I will not be happy with the names my junior picked, and of course I will constantly be unhappy with some of them. This game of self-inflicted bike shedding is just a trap for people that like logic and order, and it’s… wholly irrelevant. With tailwind, you just declare how something is supposed to look and feel like, at the place where it is, in the context of your configurable design system. No names, no bike shedding. Okay, that’s not a hundred percent true; you can name group selectors, because as opposed to plain inline styles, Tailwind can target children, siblings, pseudo elements—there are no restrictions. It’s a truly elegant solution for authoring web pages.

ardleon 1y ago
Using webcomponents there is no problem with identifiers, you can repeat the same identifier as many times as you need.
the_other 1y ago
Do you treat your JS and TS the same way, eschewing semantic clarity?
- troupo 1y ago
  Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.
  - skydhash 1y ago
    So you can name a component, but you cannot name the styles attached to that component?
    - 9dev 1y ago
      It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app. It’s not about not being able to name all these things, it’s that it’s pointless to do so.
      - jaggederest 1y ago
        You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.
      - skydhash 1y ago
        Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components. My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
        9dev 1y ago
        > If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less. > Tailwind [is] a path to ruin. Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat. For me, styling on the web is solved.
JimDabell 1y ago
How do you cope with page URLs, with JavaScript classes, variables, methods, Git branches, CSS filenames, image filenames, directory structure, etc.? I know the joke is that naming things is hard, but it really isn’t and every web developer successfully and effortlessly names things all day long without even thinking about it. If I have a sidebar, coming up with the name “sidebar” for a CSS class is not a serious problem I need Tailwind to help me avoid. I don’t find it plausible that other people genuinely feel pain over this one particular instance of naming things without demanding solutions for all the other things they have to name. Can you point to many Tailwind advocates who complain about how difficult it is to pick filenames, or page URLs? I think it’s really strange Tailwind advocates latch onto this one particular thing – naming things is a problem – when they seem to successfully name things all day long in every other context. It doesn’t feel like a real problem. What happens when you need to create a file? Do you get paralysed by the myriad choices of filenames available? Or do you just pick a name and move on?
- deleted 1y ago
  [deleted]
- 9dev 1y ago
  Naming things involves creating an ontology that makes sense. In the context of URLs, that’s an hierarchical structure of things that’s self-describing; in the context of code, it’s a direct model of the domain logic underlying the problem, at least for the most part: There’s lots of code involving "managers" and "containers" and "controllers" and "factories". That’s where it starts to get murky. Meanwhile, CSS classes require creating an ontology of things that’s both reusable, and at the same time referring to small or partial aspects of a thing, sometimes a thing that shows up in other parts of the code, sometimes as a variation, or just a one-off occurrence. If you do it properly, that means you’ll need to find a shared vocabulary for button attachments, centered max width wrappers, field hints, list items, and so on. It’s draining, because it’s not productive. The end result is just hopefully maintainable style sheets.
  - skydhash 1y ago
    It's draining because you're over-complicating things. CSS is for styling HTML. So however you structure your HTML, CSS closely follows (hierarchy of components/partials). Then you consider variants. After that, parents influencing children styles. Then on top of that, you add a reset (because small browser incompatibilities) and maybe a grid utility.
immibis 1y ago
I still don't understand how not naming things is a benefit over inline styles? With inline styles, instead of class="bg-blue" you'd write style="background-color:blue" and then you could remove an entire build step and an entire dependency because the browser already supports this.
- chuckadams 1y ago
  You can override bg-blue with a more specific selector or a user stylesheet, which you cannot do with inline styles.
  - 9dev 1y ago
    That; and also adjacent selectors, pseudo elements, media queries, variants, dark mode handling, state handling (hover, focus, etc.), and much more.
  - immibis 1y ago
    So you make the bg-blue style make things yellow?
    - 9dev 1y ago
      No, but your designers have decided instead of cornflower blue, they want it to be aqua instead. Have fun searching for all variants of the color in your stylesheets—including CSS varsity, hex codes and rgba variants. In Tailwind, all you need to do is update the config file, and it'll apply to backgrounds, text, shadows, anything.
      - harshitaneja 1y ago
        Well that's why we use CSS variables and any change would apply everywhere and also give us semantic information with naming like color-primary or color-surface.
        deleted 1y ago
        [deleted]
perilunar 1y ago
> It’s a truly elegant solution for authoring web pages. It's an ugly hack that undoes a lot of the benefits of CSS.

by 9dev 1y ago

ardleon 1y ago

Using webcomponents there is no problem with identifiers, you can repeat the same identifier as many times as you need.

the_other 1y ago

Do you treat your JS and TS the same way, eschewing semantic clarity?

troupo 1y ago
Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.
- skydhash 1y ago
  So you can name a component, but you cannot name the styles attached to that component?
  - 9dev 1y ago
    It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app. It’s not about not being able to name all these things, it’s that it’s pointless to do so.
    - jaggederest 1y ago
      You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.
    - skydhash 1y ago
      Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components. My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
      - 9dev 1y ago
        > If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less. > Tailwind [is] a path to ruin. Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat. For me, styling on the web is solved.

JimDabell 1y ago

How do you cope with page URLs, with JavaScript classes, variables, methods, Git branches, CSS filenames, image filenames, directory structure, etc.? I know the joke is that naming things is hard, but it really isn’t and every web developer successfully and effortlessly names things all day long without even thinking about it. If I have a sidebar, coming up with the name “sidebar” for a CSS class is not a serious problem I need Tailwind to help me avoid. I don’t find it plausible that other people genuinely feel pain over this one particular instance of naming things without demanding solutions for all the other things they have to name. Can you point to many Tailwind advocates who complain about how difficult it is to pick filenames, or page URLs? I think it’s really strange Tailwind advocates latch onto this one particular thing – naming things is a problem – when they seem to successfully name things all day long in every other context. It doesn’t feel like a real problem. What happens when you need to create a file? Do you get paralysed by the myriad choices of filenames available? Or do you just pick a name and move on?

deleted 1y ago
[deleted]
9dev 1y ago
Naming things involves creating an ontology that makes sense. In the context of URLs, that’s an hierarchical structure of things that’s self-describing; in the context of code, it’s a direct model of the domain logic underlying the problem, at least for the most part: There’s lots of code involving "managers" and "containers" and "controllers" and "factories". That’s where it starts to get murky. Meanwhile, CSS classes require creating an ontology of things that’s both reusable, and at the same time referring to small or partial aspects of a thing, sometimes a thing that shows up in other parts of the code, sometimes as a variation, or just a one-off occurrence. If you do it properly, that means you’ll need to find a shared vocabulary for button attachments, centered max width wrappers, field hints, list items, and so on. It’s draining, because it’s not productive. The end result is just hopefully maintainable style sheets.
- skydhash 1y ago
  It's draining because you're over-complicating things. CSS is for styling HTML. So however you structure your HTML, CSS closely follows (hierarchy of components/partials). Then you consider variants. After that, parents influencing children styles. Then on top of that, you add a reset (because small browser incompatibilities) and maybe a grid utility.

immibis 1y ago

I still don't understand how not naming things is a benefit over inline styles? With inline styles, instead of class="bg-blue" you'd write style="background-color:blue" and then you could remove an entire build step and an entire dependency because the browser already supports this.

chuckadams 1y ago
You can override bg-blue with a more specific selector or a user stylesheet, which you cannot do with inline styles.
- 9dev 1y ago
  That; and also adjacent selectors, pseudo elements, media queries, variants, dark mode handling, state handling (hover, focus, etc.), and much more.
- immibis 1y ago
  So you make the bg-blue style make things yellow?
  - 9dev 1y ago
    No, but your designers have decided instead of cornflower blue, they want it to be aqua instead. Have fun searching for all variants of the color in your stylesheets—including CSS varsity, hex codes and rgba variants. In Tailwind, all you need to do is update the config file, and it'll apply to backgrounds, text, shadows, anything.
    - harshitaneja 1y ago
      Well that's why we use CSS variables and any change would apply everywhere and also give us semantic information with naming like color-primary or color-surface.
      - deleted 1y ago
        [deleted]

perilunar 1y ago

> It’s a truly elegant solution for authoring web pages. It's an ugly hack that undoes a lot of the benefits of CSS.