4 ms·

This section is what I am talking about. You compare two methods of writing components and then declare that the tailwind version is tightly coupled but the sem

This section is what I am talking about. You compare two methods of writing components and then declare that the tailwind version is tightly coupled but the semantic version is loosely coupled. In programming lingo this means tailwind is bad and semantic is good. But you don't explain why the tailwind version is tightly coupled and the semantic version is loosely coupled. And you don't do it because it is simply not the case. The coupling between html and css is not tighter or looser. It just goes in a different direction. > The semantic version, allows you to change the design of the gallery freely. You name the component and style it externally. With Tailwind the style cannot be separated from the structure. Same with tailwind. You update your component to update its style. With semantic you can update the css rules without touching the html, but you don't know if this css change won't break another part of your design. If you have a simple html structure like a blog with very few components, then semantic works (but so does anything really). If you have lots of components and you need to update them in order to add new features, then semantic will bring more issues.

tipiirai 3y ago
So `<div class="gallery">` is loose coupling, because the styling is not coupled directly into the element. You can completely switch the gallery design, by switching (or overriding, or modifying) the external stylesheet.
- HelloNurse 3y ago
  The coupling is in the right direction: designing possibly very advanced CSS to get a desired appearance from a given good markup, instead of compromising markup to simplify CSS.
  - sbergot 3y ago
    The issue of this direction is if you need to update the markup, you will need to update the css, which is hard and risky because of css global scoping.
    - HelloNurse 3y ago
      New and updated CSS rules should be usually needed for new "themes", exactly the type of change that semantic markup is robust against (e.g. placing image captions in a sidebar rather than below the respective images), and for backwards compatible extensions of the original design that add support for something new that will only be used in new markup in new pages (e.g. allowing small images inside paragraphs, meant to be displayed inline, in addition to large ones between paragraphs). What kind of fragile markup and problematic CSS global rules are you worrying about?
      - skydhash 3y ago
        > What kind of fragile markup and problematic CSS global rules are you worrying about? I’m wondering that too. If I’m writing a SPA, styles are usually scopped to the component with a base styles for UI atomic elements. And some conventions around spacing. If it’s a website, it will be separated in layouts and small components Bootstrap-like. An update will be identified as a variant or a special case. As for coding this, search all files is usually a godsend when refactoring. You can use ripgrep if the editor does not have a good implementation.
        sbergot 3y ago
        The author uses css targets like *body > header*. Search and replace won't be enough to tell you which components are affected by a given rule.
      - sbergot 3y ago
        A lot of applications have a long lifetime. They are not shipped only once. If I want to add a new feature, say allow users to perform a new operation in an existing screen, I will have to update a few components for this. You want to preserve the theme an consistency of the UI, but adapt its functionality. For this type of changes the semantic version is problematic.
        HelloNurse 3y ago
- config_yml 3y ago
  I have rarely seen this work in practice in 20 years of CSS, but maybe in CSS Zen Garden. Yes, you can freely change the CSS. But usually changes are triggered by the HTML, like some information is added. This then requires you to change the CSS and likely break all sorts of other uses, which is not a problem with Tailwind.
  - tempmac 3y ago
    hmm maybe IDE plugins can solve this? (eg. add a 'hover to show css' or 'expand css if I press ctrl+alt') as for tailwild, I just can't bare its wide-ness - too many className attribute string going over 150~300 char widths, with some ternary operators mixed on top... (seems vanilla-extract / ete have better DX, with occasional inlining for immediate deadlines)
    - sbergot 3y ago
      The only way to know is to go to the page and inspect it using devtools. No Ide will be able to infer which rule is going to apply to any given element. But the problem is that you need to make sure that a given css change is going to affect only a specific set of component. So you need to check all components. Since it will be too time consuming, you will probably skip this step and hope for the best (and do some QA to check that nothing is obviously broken).
      - tempmac 3y ago
        hmm it might be possible with enough tooling: - read from webpack's output - read from css-in-js: emotion / vanilla-extract / etc
        kaba0 3y ago
        Then you avoid the browser, by emulating half a browser.. which is still useless, because you have plenty dynamic state you can’t test this way.
- tipiirai 3y ago
  You can see this in practise here: https://nuejs.org/@spotlight/ https://nuejs.org/@spotlight/ vs here: https://nuejs.org/@base/ https://nuejs.org/@base/ (the gallery component)
- sbergot 3y ago
  It is still coupled because the css will need to know the html structure in order to work. If you update the html, you probably need to update the css.
  - tobr 3y ago
    Both of them need to conform to the same allowed patterns of markup. I think we lack a kind of markup schema or type system that everything can be validated against, where we can verify that our design takes every state and permutation into account, and that both styling and content implements their part of it correctly.
    - sbergot 3y ago
      tailwind doesn't need to know anything about your components.
      - tobr 3y ago
        [delayed]
  - tipiirai 3y ago
    It is _loosely_ coupled. I can switch the design completely without touching HTML. If I modify the HTML structure, the component specification changes and CSS obviously needs to be updated.
    - kaba0 3y ago
      This is simply not true of any real-world application.
    - crdrost 3y ago
      You will be more effective if you deploy your words more carefully. Loose coupling vs tight coupling has an established meaning ≈ “if a change to module X causes a failure in module Y, then we say X and Y are tightly coupled.” This has some “knock-on” effects that you are trying to gesture at, like, “If two modules are tightly coupled then because of that tight coupling we usually have to coordinate deployments between them both.” And then you're like “I can ship new CSS without having to coordinate a deployment of HTML, that must be loose coupling then!” But this is a sloppy way to use the language, because in the one case you have one module, and in the other case you have two: there is no coupling in the Tailwind case because there is nothing to be coupled because it all ships as one module, then you construct a more modular approach, one with two modules in fact, and these modules are (depending on how you squint at it given that we are doing decorative programming and there are no explicit errors) in fact “tightly coupled”—the semantic HTML essentially provides a customized API which the CSS uses by hooking into; this is a common form of tight coupling in microservice deployments for example.[1] So you are actually looking at, one module plus a static asset that defines a common language, vs. two modules that are tightly coupled, and declaring that the two modules are “more loosely coupled” and this is somewhat of a nonsense thing to say. Like I get what you were going for, I didn't write this as a top level complaint because I understand what you meant, but here in the thicket of comments I see that you are not communicating well with your interlocutor because of this sloppiness and language, you might want to pivot? [1] This point about microservices is likely to outrage a random passerby, look I am sure that your microservices use RPCs against HTTP APIs in a way that doesn't cause you much grief in having to update multiple modules in one commit (if monorepo) or stage “topics” (Gerrit’s term) where you carefully have to merge 2 or 3 pull requests to different repositories all at the same time (if multi-repo). But even though your microservices are loosely coupled, I have worked on very similar architectures where we did have to stage topics and if you didn't then changes to service X would break service Y, “We’ll ship a new value for this enum, that requires changing the common schema repo, which requires updating every microservice that looks at that enum so that it doesn't have a deserialization failure ‘this is not an allowed value for that enum’ when the new values start rolling out, the ones that actually switch() or if() on that enum need to be updated to do the right thing, oh, I missed one because it relies on the contract that if enum == x then fieldA is set but if enum == y or z then fieldB is set but now when enum == q neither fieldA nor fieldB is set...” and I am happy that you haven't had these problems but yeah, some microservices are tightly coupled by this definition.
- kaba0 3y ago
  So what does it mean? You want the structure of your HTML to say the browser, that here is anything? Does your designer just give you a design with a huge blank rectangle in the middle? When does it ever make sense? Isn’t it much more meaningful to create a <gallery> component (it can be done through a template-engine, react, whatever, that’s another point). I mean, sure, we could just program with void pointers everywhere, but is it really a good idea?

tipiirai 3y ago

So `<div class="gallery">` is loose coupling, because the styling is not coupled directly into the element. You can completely switch the gallery design, by switching (or overriding, or modifying) the external stylesheet.

HelloNurse 3y ago
The coupling is in the right direction: designing possibly very advanced CSS to get a desired appearance from a given good markup, instead of compromising markup to simplify CSS.
- sbergot 3y ago
  The issue of this direction is if you need to update the markup, you will need to update the css, which is hard and risky because of css global scoping.
  - HelloNurse 3y ago
    New and updated CSS rules should be usually needed for new "themes", exactly the type of change that semantic markup is robust against (e.g. placing image captions in a sidebar rather than below the respective images), and for backwards compatible extensions of the original design that add support for something new that will only be used in new markup in new pages (e.g. allowing small images inside paragraphs, meant to be displayed inline, in addition to large ones between paragraphs). What kind of fragile markup and problematic CSS global rules are you worrying about?
    - skydhash 3y ago
      > What kind of fragile markup and problematic CSS global rules are you worrying about? I’m wondering that too. If I’m writing a SPA, styles are usually scopped to the component with a base styles for UI atomic elements. And some conventions around spacing. If it’s a website, it will be separated in layouts and small components Bootstrap-like. An update will be identified as a variant or a special case. As for coding this, search all files is usually a godsend when refactoring. You can use ripgrep if the editor does not have a good implementation.
      - sbergot 3y ago
        The author uses css targets like *body > header*. Search and replace won't be enough to tell you which components are affected by a given rule.
    - sbergot 3y ago
      A lot of applications have a long lifetime. They are not shipped only once. If I want to add a new feature, say allow users to perform a new operation in an existing screen, I will have to update a few components for this. You want to preserve the theme an consistency of the UI, but adapt its functionality. For this type of changes the semantic version is problematic.
      - HelloNurse 3y ago
config_yml 3y ago
I have rarely seen this work in practice in 20 years of CSS, but maybe in CSS Zen Garden. Yes, you can freely change the CSS. But usually changes are triggered by the HTML, like some information is added. This then requires you to change the CSS and likely break all sorts of other uses, which is not a problem with Tailwind.
- tempmac 3y ago
  hmm maybe IDE plugins can solve this? (eg. add a 'hover to show css' or 'expand css if I press ctrl+alt') as for tailwild, I just can't bare its wide-ness - too many className attribute string going over 150~300 char widths, with some ternary operators mixed on top... (seems vanilla-extract / ete have better DX, with occasional inlining for immediate deadlines)
  - sbergot 3y ago
    The only way to know is to go to the page and inspect it using devtools. No Ide will be able to infer which rule is going to apply to any given element. But the problem is that you need to make sure that a given css change is going to affect only a specific set of component. So you need to check all components. Since it will be too time consuming, you will probably skip this step and hope for the best (and do some QA to check that nothing is obviously broken).
    - tempmac 3y ago
      hmm it might be possible with enough tooling: - read from webpack's output - read from css-in-js: emotion / vanilla-extract / etc
      - kaba0 3y ago
        Then you avoid the browser, by emulating half a browser.. which is still useless, because you have plenty dynamic state you can’t test this way.
tipiirai 3y ago
You can see this in practise here: https://nuejs.org/@spotlight/ https://nuejs.org/@spotlight/ vs here: https://nuejs.org/@base/ https://nuejs.org/@base/ (the gallery component)
sbergot 3y ago
It is still coupled because the css will need to know the html structure in order to work. If you update the html, you probably need to update the css.
- tobr 3y ago
  Both of them need to conform to the same allowed patterns of markup. I think we lack a kind of markup schema or type system that everything can be validated against, where we can verify that our design takes every state and permutation into account, and that both styling and content implements their part of it correctly.
  - sbergot 3y ago
    tailwind doesn't need to know anything about your components.
    - tobr 3y ago
      [delayed]
- tipiirai 3y ago
  It is _loosely_ coupled. I can switch the design completely without touching HTML. If I modify the HTML structure, the component specification changes and CSS obviously needs to be updated.
  - kaba0 3y ago
    This is simply not true of any real-world application.
  - crdrost 3y ago
    You will be more effective if you deploy your words more carefully. Loose coupling vs tight coupling has an established meaning ≈ “if a change to module X causes a failure in module Y, then we say X and Y are tightly coupled.” This has some “knock-on” effects that you are trying to gesture at, like, “If two modules are tightly coupled then because of that tight coupling we usually have to coordinate deployments between them both.” And then you're like “I can ship new CSS without having to coordinate a deployment of HTML, that must be loose coupling then!” But this is a sloppy way to use the language, because in the one case you have one module, and in the other case you have two: there is no coupling in the Tailwind case because there is nothing to be coupled because it all ships as one module, then you construct a more modular approach, one with two modules in fact, and these modules are (depending on how you squint at it given that we are doing decorative programming and there are no explicit errors) in fact “tightly coupled”—the semantic HTML essentially provides a customized API which the CSS uses by hooking into; this is a common form of tight coupling in microservice deployments for example.[1] So you are actually looking at, one module plus a static asset that defines a common language, vs. two modules that are tightly coupled, and declaring that the two modules are “more loosely coupled” and this is somewhat of a nonsense thing to say. Like I get what you were going for, I didn't write this as a top level complaint because I understand what you meant, but here in the thicket of comments I see that you are not communicating well with your interlocutor because of this sloppiness and language, you might want to pivot? [1] This point about microservices is likely to outrage a random passerby, look I am sure that your microservices use RPCs against HTTP APIs in a way that doesn't cause you much grief in having to update multiple modules in one commit (if monorepo) or stage “topics” (Gerrit’s term) where you carefully have to merge 2 or 3 pull requests to different repositories all at the same time (if multi-repo). But even though your microservices are loosely coupled, I have worked on very similar architectures where we did have to stage topics and if you didn't then changes to service X would break service Y, “We’ll ship a new value for this enum, that requires changing the common schema repo, which requires updating every microservice that looks at that enum so that it doesn't have a deserialization failure ‘this is not an allowed value for that enum’ when the new values start rolling out, the ones that actually switch() or if() on that enum need to be updated to do the right thing, oh, I missed one because it relies on the contract that if enum == x then fieldA is set but if enum == y or z then fieldB is set but now when enum == q neither fieldA nor fieldB is set...” and I am happy that you haven't had these problems but yeah, some microservices are tightly coupled by this definition.
kaba0 3y ago
So what does it mean? You want the structure of your HTML to say the browser, that here is anything? Does your designer just give you a design with a huge blank rectangle in the middle? When does it ever make sense? Isn’t it much more meaningful to create a <gallery> component (it can be done through a template-engine, react, whatever, that’s another point). I mean, sure, we could just program with void pointers everywhere, but is it really a good idea?