4 ms·

I just moved our website from semantic to tailwind after I didn’t understand the semantic bits anymore. Main problem was: the semantic css was elegant, but und

I just moved our website from semantic to tailwind after I didn’t understand the semantic bits anymore. Main problem was: the semantic css was elegant, but understanding it again after half a year of not editing the page took super long. Tailwind is clear. The code looks uglier but I instantly know what’s going on. No hidden things. And no fear in editing a piece of html that it will break sth else. Huge upside.

quickthrower2 3y ago
Copy paste for styling isn't as bad as it sounds. Obviously with React you get components you can reuse. But manually chucking out mb-2, mx-2, my-3 to get it to look nice to the eye and having the same things repeat in different spots without a "meaning" or "semantics" can be quite nice. For small-medium size projects of course.
- berkes 3y ago
  That quickly falls apart when I add an mb-2 to a Thingy, but fail to check that Thingy is also used inside SideThings (which we all forgot existed at all) wich already has whitespace (but somehow uses mt-2 because the developer preferred to declare intermediate whitespace at the top instead of the bottom). So when the communication dept calls me on friday, I add quickly add an #main div.nth-child(2).mb-2 { margin-bottom: 0 !important } to overrides.css and call it a day. Point being: manually sprinkling mb-2s throughout your codebase is a recipe for disaster: an sure way to an unmaintainable frontend.
  - earthnail 3y ago
    Until someone else edits your code and doesn't understand why the layout suddenly broke. nth-child(2) is very prone to this.
    - kaba0 3y ago
      Or worse, it breaks at a completely different site you didn’t even touch, won’t notice and might also pass through manual testing (if that’s even a thing at your place), and end up in prod. Sure, there are AI-based testing tools that check for frontend changes, but let’s be honest, they are very rarely used, if at all.
    - berkes 3y ago
      Yes. My point was that to "fix" a scattering of .mb-2 going astray, we often pull out even worse solutions. Making the software as a whole worse.
      - quickthrower2 3y ago
        Hacks like this exist in non-tailwind projects where the classes have lost all meaning and the CSS is in a messy state. On the other hand, in tailwind you could organize things well using your template/component system, be that ReactJS, Vue, ERB, EJS, CSHTML etc. I agree there is subtlety though. A well organized and "benevolent dictator-ed" crop of CSS files is going to be more powerful than it's Tailwind equivalent due to having selectors etc. available.
  - egeozcan 3y ago
    > #main div.nth-child(2).mb-2 { margin-bottom: 0 !important } to overrides.css and call it a day And then 100 times doing the same later... We all know how it ends up looking because we all did it.
amjnsx 3y ago
> but understanding it again after half a year of not editing the page took super long. Longer than converting the entire website to Tailwind?
- earthnail 3y ago
  I wrote a new part of the website in tailwind to see what all the fuzz is about. Then I decided to rewrite the rest of it. It's a small website, but it's complex with desktop and mobile layouts, audio players etc etc. There's a design system behind it, but many small exceptions to it to make it look really nice. Writing the new part of the website was so fast with Tailwind that I just thought I'd give the rewrite a go. It wasn't that painful, and while it definitely took longer than understanding the existing bits just to edit sth, it also allowed me to clean up the CSS mess that had accumulated over two years. If I had just sat down and tried to clean up the CSS mess, it probably would've taken longer if I hadn't converted it to Tailwind at the same time. And I needed to do some cleanup as we were trying to tie different sub pages into a coherent experience. Just to clarify: please don't take this as advice of "go and rewrite your code". Rewrites are almost always bad. But in my case here, it was a good decision. My personal learning is that a startup landing page just changes too much to be able to fit into semantic classes nicely.
tipiirai 3y ago
Indeed. This is a matter of taste. I personally find semantic CSS much clearer. I move faster with it because I need less code to achieve the same thing, and the resulting site is leaner.
tuyiown 3y ago
Yep ! This is the huge problem with css and «meaningful» selectors, no matter how much you try to make things clear, nuances and details fades and you end up going back end forth between css code, inspector and HTML to figure out what's happening. Utility based css selectors that do one and single thing are clear and explicit, removing most (but not all) that hassle.
- tipiirai 3y ago
  Not all developers have experienced these problems. There are people who prefer the semantic approach. I'm definitely one.
  - aloisdg 3y ago
    Not all team are homogeneous. go for the friction less solution.
  - HelloNurse 3y ago
    I strongly doubt a reasonably designed "semantic" design can be half-forgotten after taking a break; the fine points of the implementation of sophisticated rules (e.g. why did we put the left border on the parent and the right border on the child) might suffer from obsolescence and lack of documentation, but the markup structure and the names should be obvious. Forgetting what plethora of non-semantic classes should be used on what elements seems a far more likely problem.
  - tuyiown 3y ago
    Yes, there are conditions of people and project where you can avoid those. But they a are plenty of situation when it becomes too hard, such as when you can't constraint a designer to your implementation details, or that same semantic concepts have different UI cases.

quickthrower2 3y ago

Copy paste for styling isn't as bad as it sounds. Obviously with React you get components you can reuse. But manually chucking out mb-2, mx-2, my-3 to get it to look nice to the eye and having the same things repeat in different spots without a "meaning" or "semantics" can be quite nice. For small-medium size projects of course.

berkes 3y ago
That quickly falls apart when I add an mb-2 to a Thingy, but fail to check that Thingy is also used inside SideThings (which we all forgot existed at all) wich already has whitespace (but somehow uses mt-2 because the developer preferred to declare intermediate whitespace at the top instead of the bottom). So when the communication dept calls me on friday, I add quickly add an #main div.nth-child(2).mb-2 { margin-bottom: 0 !important } to overrides.css and call it a day. Point being: manually sprinkling mb-2s throughout your codebase is a recipe for disaster: an sure way to an unmaintainable frontend.
- earthnail 3y ago
  Until someone else edits your code and doesn't understand why the layout suddenly broke. nth-child(2) is very prone to this.
  - kaba0 3y ago
    Or worse, it breaks at a completely different site you didn’t even touch, won’t notice and might also pass through manual testing (if that’s even a thing at your place), and end up in prod. Sure, there are AI-based testing tools that check for frontend changes, but let’s be honest, they are very rarely used, if at all.
  - berkes 3y ago
    Yes. My point was that to "fix" a scattering of .mb-2 going astray, we often pull out even worse solutions. Making the software as a whole worse.
    - quickthrower2 3y ago
      Hacks like this exist in non-tailwind projects where the classes have lost all meaning and the CSS is in a messy state. On the other hand, in tailwind you could organize things well using your template/component system, be that ReactJS, Vue, ERB, EJS, CSHTML etc. I agree there is subtlety though. A well organized and "benevolent dictator-ed" crop of CSS files is going to be more powerful than it's Tailwind equivalent due to having selectors etc. available.
- egeozcan 3y ago
  > #main div.nth-child(2).mb-2 { margin-bottom: 0 !important } to overrides.css and call it a day And then 100 times doing the same later... We all know how it ends up looking because we all did it.

amjnsx 3y ago

> but understanding it again after half a year of not editing the page took super long. Longer than converting the entire website to Tailwind?

earthnail 3y ago
I wrote a new part of the website in tailwind to see what all the fuzz is about. Then I decided to rewrite the rest of it. It's a small website, but it's complex with desktop and mobile layouts, audio players etc etc. There's a design system behind it, but many small exceptions to it to make it look really nice. Writing the new part of the website was so fast with Tailwind that I just thought I'd give the rewrite a go. It wasn't that painful, and while it definitely took longer than understanding the existing bits just to edit sth, it also allowed me to clean up the CSS mess that had accumulated over two years. If I had just sat down and tried to clean up the CSS mess, it probably would've taken longer if I hadn't converted it to Tailwind at the same time. And I needed to do some cleanup as we were trying to tie different sub pages into a coherent experience. Just to clarify: please don't take this as advice of "go and rewrite your code". Rewrites are almost always bad. But in my case here, it was a good decision. My personal learning is that a startup landing page just changes too much to be able to fit into semantic classes nicely.

tipiirai 3y ago

Indeed. This is a matter of taste. I personally find semantic CSS much clearer. I move faster with it because I need less code to achieve the same thing, and the resulting site is leaner.

tuyiown 3y ago

Yep ! This is the huge problem with css and «meaningful» selectors, no matter how much you try to make things clear, nuances and details fades and you end up going back end forth between css code, inspector and HTML to figure out what's happening. Utility based css selectors that do one and single thing are clear and explicit, removing most (but not all) that hassle.

tipiirai 3y ago
Not all developers have experienced these problems. There are people who prefer the semantic approach. I'm definitely one.
- aloisdg 3y ago
  Not all team are homogeneous. go for the friction less solution.
- HelloNurse 3y ago
  I strongly doubt a reasonably designed "semantic" design can be half-forgotten after taking a break; the fine points of the implementation of sophisticated rules (e.g. why did we put the left border on the parent and the right border on the child) might suffer from obsolescence and lack of documentation, but the markup structure and the names should be obvious. Forgetting what plethora of non-semantic classes should be used on what elements seems a far more likely problem.
- tuyiown 3y ago
  Yes, there are conditions of people and project where you can avoid those. But they a are plenty of situation when it becomes too hard, such as when you can't constraint a designer to your implementation details, or that same semantic concepts have different UI cases.