1. 24
  1. 11

    The class names are long because they do a lot of things.

    “With Tailwind, you’re forced to interpret semantics on the fly”

    With css, you’re forced to flip to through some other file to get it. If you don’t see the tailwind code as obviously better, I would still say try it, and if you’re not convinced, don’t use it I guess, but nothing written there at all convinces me otherwise.

    Point 3 is absurd, the docs immediately explain how to set up purging so that unused class names. My purged css is like 4.5kb and my unpurged css is like 8MB.

    1. 4

      Yep, I thought that was a pretty disingenuous point. Purging excess CSS is talked about so much, even on the homepage:

      It’s tiny in production.

      Tailwind automatically removes all unused CSS when building for production, which means your final CSS bundle is the smallest it could possibly be. In fact, most Tailwind projects ship less than 10KB of CSS to the client.

      1. 8

        One problem with the “we don’t care about the size because our custom minifier will make it small” is that it adds yet another part to the ridiculously fragile rube-goldberg machine that is npm.

        1. 3

          Also, may I introduce you to Windi CSS, that doesn’t even generate unused tailwind classes in the first place :) ! https://github.com/windicss/windicss

          1. 1

            Or twind, which doesn’t even require you to generate a CSS file in the first place. :-)

            If you use the shim that is: https://twind.dev/docs/modules/twind_shim.html

      2. 7

        TLDR:

          1. Tailwind Makes Your Code Difficult to Read
          1. Tailwind Is Vendor Lock-in
          1. Tailwind Is Bloated
          1. Tailwind Is an Unnecessary Abstraction
          1. Semantics Is Important. Tailwind Forgoes It.
          1. Tailwind and Dev Tools Don’t Play Nicely
          1. Tailwind Is Still Missing Some Key Features
        1. 3

          I’m current in the process of using CSS Grid to replace an old layout and it’s really damn simple once you work your head around it. I’ve got an older site where I use Foundation 5. I barely have to touch it and it works well enough, but I wouldn’t recommend using something like Foundation today.

          It all really comes down to tradeoffs. The opening page of Tailwind looks neat, but I feel like a lot of stuff could be accomplished without a framework as well and you’ll be dealing with the same level of headache.

          1. 1

            I don’t get the semantics point. Isn’t Tailwind supposed to help you build your own semantics where you need them?

            1. 6

              As I understand it (from reading the article and never having use Tailwind):

              The original idea of CSS was to separate content from presentation by having only semantic markup in your HTML. Your HTML would have class names for elements that defined some ontology for your document (e.g. article, person name, to-do list entry, and so on). The CSS would be a completely separate thing that then describes how to render that semantic structure into something visually appealing. You could have different CSS for different renderings (e.g. one for screen readers, one for small screens, one for print output [CSS 2.1 added a load of things specifically for print output, though Opera was the only thing to support them for a long time], and so on).

              That works well for web sites that are web sites. It works less well for web sites that are apps that use a HTML view as the front part of a GUI framework, where your styling is closely coupled in your application logic to the contents in your (generated) HTML. You end up making up names like one-of-the-first-three-buttons or whatever. For this kind of use, you actually want to be using inline style attributes, you’re just using separate CSS as a way of doing some ad-hoc Huffman encoding of your style attributes.

              From what I can tell, Tailwind is focused on the latter use case, providing small bits of CSS so you can define class attributes that do the equivalent of an inline style attribute. From the perspective of someone who is not a web developer and so may be missing something important, this seems like a terrible idea. If you want to solve this problem, it would be better for your web app framework to generate inline style attributes and then do a post-processing phase that pulls common style attributes into CSS classes. I am not sure if you can use CSS selectors in inline styles though, so that might not be possible.

              1. 1

                As far as having you use the right HTML element for every task goes: IME tailwind generally helps with this by removing the temptation to use a particular element for its effect on style.