5 ms·

I don't do front end dev, and haven't for a very long time, but can someone help me understand how this doesn't lead to inflexible hard to maintain soup? Just t

• joshmanders 6y ago
  Tailwind is completely flexible, if you would rather have your colors be `brand-light', `brand-dark`, etc you can. Just update your config however you want. It just comes with a config out of the box that is highly usable for any app and any need without customizing. Purge then allows you to strip out all the extra unused CSS in production.
  • kolektiv 6y ago
    Ok, so I could mark everything as "brand-dark" and then change the definition of that in the CSS? Mmm. Ok. How about layout and sizing? A lot of that looks a lot more defined - I'll pick a random example from their own homepage then: "border-b border-gray-200 py-6 flex items-center justify-between mb-16 sm:mb-20 -mx-4 px-4 sm:mx-0 sm:px-0" - if I wanted to change my approach to centring, justification, and sizing, it still seems like a lot of search and replace... (I think I understand that the approach is that I'd then change what those definitions mean centrally - but that won't help me if I decide that two properties which are currently different should be the same, or vice versa).
    • _jjkk 6y ago
      Layout tends to be a property of a particular component, and semantic classes don't work well there either. In a complicated codebase with multiple devs, the number of times you could confidently make a "one-place-CSS-change" to a semantic layout class is very small. It's likely that in one place or another, some dev made an assumption about your `sub-container` class or whatever, which causes your change to break their layout. Most large codebases thus end up with a TON of very specific class names (often used in one place), so the dev can be confident in their layout; this is the biggest contributor to unmaintainability that I've seen in large applications. If everyone is forced to use e.g. d-flex justify-content-center ..... it hugely improves readability as any developer can quickly look at any layout and see what is going on without building a mental index of semantic class names that the original dev chose.
      • JxLS-cpgbe0 6y ago
        but my Cards are design components, they don't have semantic classes. How is ctrl+f "border-b border-gray-200 py-6 flex items-center justify-between mb-16 sm:mb-20 -mx-4 px-4 sm:mx-0 sm:px-0" better than changing .myCard__title{}?
        • _jjkk 6y ago
          I guess it depends on the project, but I can't recall one time I've had to do a CTRL F like you've mentioned. Of course if you have a very simple page with just some cards, a couple page layouts, that is one thing. Probably can get by with just a myCard class that works everywhere on the site. But in most projects, as the number of custom components grows, nobody wants to go back and touch (break?) old CSS, so they end up just writing a bunch of fresh stuff for this new feature and throwing it on the pile. This problem happens often, while the refactor-in-one-place case happens very little.
          • JxLS-cpgbe0 6y ago
            I was going to say the opposite. Search-and-replace would never work on a high-volume site with a lot of components. Replace ".font-bold" and you just affected anything that was bold across the entire site. I could see a use for this in JSX though.
    • joshmanders 6y ago
      Then you extract components. https://tailwindcss.com/docs/extracting-components https://tailwindcss.com/docs/extracting-components
      • JxLS-cpgbe0 6y ago
        > Create a template partial or JavaScript component The parent comment was specifically about not using components. But you use your Bootstrap/Tailwind utility classes in JSX. Now your styling is tightly-coupled to your component again. Isn't that just CSS-in-JS with more steps and less power?
• zachrip 6y ago
  Theming can be done for specific types of elements but also your own keys like "primary", "secondary", etc. You should be able to change the color in one place.
• omnimus 6y ago
  Actually it's more like toolkit to make your own set of utility classes. With one config you can really change it to be whatever you need. I always throw away colors on every project and change it to semantic naming. I add / remove fontsizes, spacing whatever project needs. I've been also confused how can people use it without touching the config but apparently many do. I guess when developers don't have particular design or brand they just pick from whats available.
  • hanniabu 6y ago
    > Actually it's more like toolkit to make your own set of utility classes. You mean like CSS? Why recreate raw CSS as classes and use that in your CSS? I'm sorry but all I'm seeing is a huge disconnect.
    • corytheboyd 6y ago
      Yes, like CSS, but it’s effectively a much smaller subset of CSS. Instead of the entire CSS specification being on the table though, it’s a drastically smaller set of “utility” classes (or properties, to follow the “but it’s css” logic)
    • dgb23 6y ago
      It systematically abstracts CSS to an atomic subset. You either take the default configuration with a few tweaks, for example if you are a programmer first. Or you define a more complete, unique system upfront, for example if you implement a bespoke interface from a UI designer. If you see emerging patterns that ask for composition, then you can easily compose utilities and give your components semantic class names. It is a blessing for productivity, performance and maintainability, because it decouples CSS concretions by introducing a light, composable abstraction layer between raw CSS and component/semantic CSS. Think of it as a lightweight, well defined query builder on top of SQL that you use for safe parameter binding and composability. (The analogy leaks a bit but you get the drift)
    • leemcalilly 6y ago
      It’s CSS with a design system. If you need to bump a value like margin or font size by one click you know you’re doing that within the context of a harmonious scale, not just writing free-form css, reinventing a design system (if you even have one) from scratch on every site.
• gambler 6y ago
  > can someone help me understand how this doesn't lead to inflexible hard to maintain soup? It most likely does, but it's not old and popular enough for people to have accumulated enough technical debt within systems built with it.
  • mikael-gramont 6y ago
    My thoughts exactly.
• jarek83 6y ago
  I'm on the same boat. No one here really tells how to avoid the ease of getting tens of classes added across many tags. Tailwind requires a lot of self-discipline and that is very easy to omit in some projects. I can't imagine maintaining a project with tailwind on board.
  • deergomoo 6y ago
    As someone who is actively maintaining several projects using Tailwind now, it really doesn’t in practice. In fact if anything it requires _less_ discipline, because a styling change can’t really break a layout elsewhere. You avoid repeated classes by extracting components (either template partials, or actual components if you’re using a front-end framework). The components themselves define how they look, and then you assemble them, perhaps with a few additional classes for things like spacing. If you need to change a component you don’t need to go and change classes everywhere you’ve used it, you just change the component itself. If you feel like reading further, Tailwind’s author explained his rationale very clearly in a blog post a few years ago [1] [1]: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...
• kall 6y ago
  Basically, these concerns are split in half now, between components and design systems. In my opinion tailwind works out best if you use components or use template partials in a component style. In that case, there won‘t be that many places where you declare what your primary nav looks like. You just go into the PrimaryNav component and change the class. In the other case you mention, you may want to use a semantic color name, which you can do in tailwind.config.js no problem, so your color class could be bg-action-300 or bg-red-action. Now this is not the same as some action-primary css class which could contain color, layout, an IE hack whatever. It‘s only predictable design system primitives like color, spacing, typography style, shadows etc. You can think of these like types in a programming language because they are enforced and predictable, not ad hoc thought up by developers per project. Both of these things have emerged more strongly in frontend in recent years, so it makes sense that different things make sense than 10 years ago (semantic classes)
• cactus2093 6y ago
  The inflexible soup can come just as easily in the opposite direction though. Eventually you have prominent-action-7 and you need documentation to understand what all these supposedly semantic names actually mean in reality and figure out which one you want. Or you want to change the look of your prominent actions, so you change the class definition and then later you realize someone made a totally different kind of thing look like a prominent action and just reused the class but now it should no longer be the same. Making a change in one place breaks other things in totally unrelated places in the app. So in order to avoid that, you need to look closely at every use of a thing anyway when making a change to make sure you're not breaking something. And if you're doing that, then you're not even getting any benefit from your abstraction anymore, you almost might as well change every instance of the thing one by one if you have to carefully comb through them all anyway. > So if I want to change the colour of all prominent-actions across my web app As I was just saying, it's naive to think this would ever be a simple one-line change of a constant. It will inevitably be a moderate sized undertaking no matter what you do, because of all the cruft and coupling that may have built up under the old assumptions. But it's also not something you're doing every day, so it should be far from the first thing on your mind when thinking about which patterns are most helpful to use. But, even putting all that aside, using utility classes like Tailwind doesn't even prevent you from abstracting as much as you'd like. You just do it at a different level. You're not likely writing static html on every page anyway, you're probably using code to generate your html whether that's React components, server-side rendered views with partials and templates, templates in a static site generator, etc. So you can still do the abstraction you want at the level of your components or your view code instead of via css classes. In that world you can think of tailwind as just a higher-level version of the underlying css properties. And you're still free to repeat yourself or DRY-ify your code as much as you want (though as I allude to above, I tend to think DRY in programming is often very overrated).
• kumarvvr 6y ago
  Ideally, you can use theming. https://tailwindcss.com/docs/theme https://tailwindcss.com/docs/theme Its slightly more work, but well worth it. Regarding the 'class soup' thing, I found that using 'primary-nav', etc to also devolve into soups, albeit, soups of a different taste.