4 ms·
Here's why I have no interest in trying Tailwind: - It's a DSL within a DSL, which as a rule of thumb I always avoid because it means circumventing any static
by chatmasta 4y ago
Here's why I have no interest in trying Tailwind:
- It's a DSL within a DSL, which as a rule of thumb I always avoid because it means circumventing any static analysis within the main language. The rest of my complaints are mostly derived from this fundamental issue.
- It reminds me (not in a good way) of bootstrap classes circa 2011
- Unlike styled components, there is no static typing or intellisense as it circumvents the TS compiler. I'm sure Tailwind has its own solutions to this problem, but I have enough tooling to deal with already
- It's an arcane "language" that needs to be learned in addition to every other language in your codebase, which makes it difficult to onboard new devs
- A string value containing a long list of short identifiers does not make for readable nor maintainable code
- In 2033, CSS will still be around. Nobody knows whether Tailwind will be, but if "reminds me of bootstrap" is any indication, the ecosystem will not be thriving.
- It's not easy to remove from your project if you decide you don't want to use it anymore (unlike solutions that use CSS or object syles, which can be more readily swapped between frameworks, e.g. migrating from MUI to Emotion or from Emotion to CSS modules)
- None of the problems it purports to solve are recognizable to me
I know that people like Tailwind, but frankly I don't see why, and I suspect there may be some element of stockholm syndrome driving its popularity. And I'm always skeptical of any technology with culty vibes around it.
As for me, my preferred solution is either CSS modules or emotion.js, using either CSS or styled objects, both of which are fully supported by intellisense and typechecking, and are based on a 25 year old standard language instead of a 3 year old DSL within that language.
- nickspicer1993 4y agoHave you tried it in earnest on a project? I was of the same opinion but once you try it (with VS Code and Tailwind plugin) it's hard not to fall in love with the ultra fast feedback loop and well defined colour palette.
- qiller 4y agoIt's definitely not for everyone. I'm on the fence, for example, I do like the utility based approach, but TW breaks a number of my common workflows. For example the feedback loop - I can't quickly add or change a few classes in devtools, since TW might not have compiled those yet. I can't also easily refer from the html code in devtools back to a component that rendered that without clutches (VueDevTools etc).
- capableweb 4y agoHow can the change CSS feedback loop get any faster? I change a CSS value and it automatically updates in the browser, seems like about how fast it can be. Creating a "well defined color palette" is usually a part of the design-process when creating a new application/website. I understand that some people prefer the Bootstrap-process of already having a bunch of colors defined for you up front, but it certainly doesn't suit every project. Plus personally, I don't miss the times when Bootstrap was trendy and every website basically looked the same. I like the individuality of the framework-less web.
- pcthrowaway 4y ago> Creating a "well defined color palette" is usually a part of the design-process when creating a new application/website You can easily do this in tailwind.
- capableweb 4y agoYou can easily do so without Tailwind as well, with CSS variables. What's the difference you're hinting about?
- pcthrowaway 4y agoI must have misunderstood you then. I thought you were suggesting Tailwind restricted you to the default colour palette
- capableweb 4y agoMight be. I was replying to the "it's hard not to fall in love with the ultra fast feedback loop and well defined colour palette." part where I get the impression they like that they don't have to define their own color palette and just use the one provided.
- pcthrowaway 4y agoOh, maybe it wasn't clear then, you can use the default colour palette, and then gradually swap out the built-in class names with the colours you want them to actually map to, or create your own custom colour class names as well. At the very least it should save a step or two compared to building the design system out yourself in a new project
- illiarian 4y ago> It reminds me (not in a good way) of bootstrap classes circa 2011 Unlike Bootstrap Tailwind doesn't have hardcoded components and full on UI elements like "breadcrumb-item" or "modal-title". You want components? You build them yourself. Tailwind is literally just utility classes with a few defaults for sizes and colors thrown in. > unlike solutions that use CSS or object syles, which can be more readily swapped between frameworks, e.g. migrating from MUI to Emotion You're confusing a CSS framework that actually is like Bootstrap (MUI) with a way of writing CSS (emotion). You'll have significantly more troubles trying to move away from MUI with its rigid requirements for code structure and CSS (Typography variant="subtitle1" and Button variant="outlined" etc.) than moving away from Tailwind which is really just a collection of CSS classes that you may or may not use as you wish.
- chatmasta 4y agoMUI to Emotion was probably not the best example, but Emotion to CSS Modules is more relevant to my point. And to be clear, I despise MUI, and actually did migrate from it to Emotion, which was relatively easy because it uses Emotion under the hood. But what I'm getting at with the example of Emotion to CSS Modules, is that they both use standard CSS and the differences are mostly around where it's defined and how it's loaded. Migrating wouldn't be a piece of cake, but it would be mostly a matter of moving blocks of code around, and could be largely automated. Whereas with Tailwind, the utility classes are only meaningful as long as you're fully plugged into the Tailwind ecosystem. There is no "eject" button, AFAIU.
- illiarian 4y ago> but Emotion to CSS Modules is more relevant to my point. And has nothing to do with Tailwind, Bootstrap, or MUI > But what I'm getting at with the example of Emotion to CSS Modules, is that they both use standard CSS So does Tailwind > Whereas with Tailwind, the utility classes are only meaningful as long as you're fully plugged into the Tailwind ecosystem. Same with MUI. Again, it's much harder to migrate off MUI because it literally binds you to a very specific way to structure your components and other components inside those components. Hell, you can't even move from MUI version X to MUI version X+1 without half of your site breaking. You want to move away from Tailwind to something else? Bring in that something else and use it alongside while you replace your components written with Tailwind classes with that something else. Because Tailwind is literally just CSS.
- stocknoob 4y agoSo you’ll come up with hypothetical reasons you don’t like it, instead of just trying something which is loved by many people, and seeing if you actually like it. I do not like it in a boat, I do not like it with my coat, I do not like green eggs and ham.
- chatmasta 4y agoWell, I've had to stop people from introducing it into our projects before, so it is something I have to deal with. I won't passionately advocate against it, but I did enough research and have enough experience to recognize when something will not be worth it to me. And I don't know why you would classify these legitimate points against it as "hypothetical," because as far as I can tell they're solidly grounded in reality. The central argument of its value seems to be "you need to try it to understand it," and I just don't find that to be a compelling argument. It doesn't claim to solve any problems that I recognize in my current workflow of writing well-scoped styled components.
- stocknoob 4y agoIf you’re not going to try it, that’s ok, but I think it would be fruitful to try it for 20 mins, they have an online playground. A huge advantage of tailwind is you can copy/paste another tailwind example from anywhere and it will just work on your site. (It’s like copying text from one site to another!) I remember the arguments in 2008 from people who insisted they needed a physical phone keyboard, like a blackberry. They need to actually try a good touchscreen, vs provide untested arguments why physical keys are better. (Better in some ways? Sure. Overall? No.) At some point it becomes an ego thing, people don’t want to admit their initial impressions were shortsighted. And it’s ok. The better experience wins out.
- chatmasta 4y agoThe problem with that argument is that once you've sufficiently "tried it," you've put so much effort in that you're stuck with it, and since there's no way to eject, you're more willing to justify it to yourself as worth it. This is stockholm syndrome. You're right I should try it, and maybe I will try it on some throwaway project eventually, but it's not a priority and I have no interest in adding it to ongoing production projects. I was very open about the fact I haven't tried it from my first sentence, which was "here are the reasons I have no interest in trying tailwind." I would have more interest if someone could explain a compelling problem that I recognize and that Tailwind solves. But nobody can do that, it's all just "you have to try it [and learn our initiation rituals] and then you'll understand!"