18 ms·

Working with Tailwind CSS every day for 2 years

154 points by themosaad 4y ago

donkeyd 4y ago
Nice to see this on the front page at the same time that a negative about Tailwind article pops up. Especially since I'm currently looking at whether to start using Tailwind. It's good to read multiple, conflicting, opinions about something.
Zealotux 4y ago
I don't like Tailwind, except for pure layouting where it truly shines. My belief is this: we should think of layouting and styling as two distinct concepts and it doesn't help that CSS is used for both. After years of experimenting with various CSS approaches, I believe using Tailwind for layout and styled-components for styles is the ultimate setup for React applications.
- daigoba66 4y ago
  How do you distinguish what is "layout" versus "style"? I know there are some obvious things, but like you said CSS is used for both. So there is a lot "grey area". Especially when "style" can affect the "layout".
  - pessimizer 4y ago
    Having gray area doesn't mean you can't separate purposes whenever possible (if that's what you want to do.)
- unsupp0rted 4y ago
  Same feeling here. In Tailwind, I'll use a `p-3` or a `.flex.items-center` all day, but making a nice button is such a slog, since I'm coming from a Vuetify background. Vuetify also has the same layout classes as Tailwind, like `pa-3` and `.d-flex.align-center` I use Vuetify + Pug (instead of raw HTML templates), so I get to make buttons like this: v-btn(outlined color="accent" @click="handleClick") Do Stuff or a Data Table with, say, a custom-formatted UPC column, like this: v-data-table(:loading="loading", :items="items", :headers="headers", :items-per-page="50" dense).my-3 template(v-slot:item.upc="{ item }") span {{formatUpc(item.upc)}} (I like to separate attributes with commas, which is valid pug but invalid HTML) Sure, I could get something like TailwindUI, but their components are walls of divs and classes that each take half an hour to load into my head to visualize what's creating all the combos of states (regular, hover, focus). So my Vuetify + Pug approach works great for greenfield projects that I create. But if I'm downloading a nice template for a side project, say from Cruip.com, it's not like they're going to use the same build chain as me, and they do have to settle on a standard CSS library, so they default to Tailwind (just like 5~10 years ago they would have defaulted to Bootstrap).
  - nightski 4y ago
    I mean what is stopping you from making a Button component once w/ Tailwind similar to Vuetify?
    - unsupp0rted 4y ago
      I've used probably 50~80% of Vuetify if taking together the last dozen projects I've done. I'd basically have to re-implement all of Vuetify in Tailwind, from buttons to chips to toggles to alerts, etc? The v-data-table is like 10 sub-components stuck together, each of which I'd have to re-implement with walls of Tailwind classes.
  - sgt 4y ago
    The secret of TailwindUI is to take the HTML version of their code and just built your own components (e.g. if using VueJS). I would not use their suggested VueJS examples, as generally I prefer the options API. It does however add some extra time to build your app - but consider that they have already built 90% for you - in terms of the design etc.
joshmn 4y ago
I have been working with HTML since I was 11 — 20ish years. I thought I knew most things. text-decoration-thickness? Nope. I have been adding border-bottom to spans for far too long it looks like.
- qiller 4y ago
  Those are pretty new. text-underline-offset is another one that made my "fake" underlines obsolete
  - Gualdrapo 4y ago
    Also remember text-decoration-style, text-decoration-color and text-decoration-skip - setting this last one to 'ink' will make the underline, ahem, skip over the glyphs with descenders, adding to legibility
- philliphaydon 4y ago
  I started html when I was about 11 so I’m at 25 years. I just discovered last night there’s an aspect ratio property… https://caniuse.com/mdn-css_properties_aspect-ratio https://caniuse.com/mdn-css_properties_aspect-ratio
  - dekerta 4y ago
    aspect-ratio is a new standard, so don't feel too bad about that
  - pewpewyouhit 4y ago
    It’s pretty new though. Less than 2 years I think.
    - philliphaydon 4y ago
      I was just shocked. Last night I’m like “hmm need to maintain aspect ratio on this box. Maybe I can use calc and vh or something. And this shocked up in Google. Rocked my world. I wanna go back across a bunch of products I’ve worked on over the years to fix stuff using this! One of my favourite features now!
zagrebian 4y ago
Does that blog have an RSS feed?
aobdev 4y ago
Slightly off topic, but you can chain your language selectors in VS Code settings so that: "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, "[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, Becomes: "[javascript][typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }
- idbehold 4y ago
  Wow thanks for this as it's not at all mentioned in the help text for these (Configure editor settings to be overridden for a language.). Also what a strange choice for multiple languages since there can clearly be conflicts this way: "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, "[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, "[javascript][typescript]": { "editor.defaultFormatter": "something.else" } If they're going to allow conflicts anyways, just invert the structure so you at least get to use normal arrays: "editor.defaultFormatter": { "esbenp.prettier-vscode": ["typescript", "javascript"] } Though, I guess the logic is that the other format allows you to override ANY setting based on language.
deliriumchn 4y ago
I'll be honest here, after working with tailwind for 7 months I really hate this piece of tech and really regret picking this company. I thought it wouldn't be a big deal but after seeing unnecessary long walls of class names I'm really tired. Anything other than basic styling is an absolute pain with tailwind and I don't understand why /my company specifically/ can't just use typestyle/styled-components/css modules to separate walls of text from components. With time, I degraded to the point I where I use classnames library just to split longer class string into 3-4 smaller ones so I can split the component into multiple rows to make it look better
- tuyenhx 4y ago
  I have the same thought. Bootstrap is still my favorite choice.
  - mozey 4y ago
    Yeah, I used Bootstrap for a long time, and got used to how it works. I wanted to like Tailwind, but it seems a bit disingenuous. It's like using inline style tags, just with shorter names. From time to time I've made an effort to learn how CSS works, but after a while I forget the details. It's more productive if I can browse a catalogue of visual examples, with concise markup that is easy to copy and paste. Bulma seems like the more "modern" take on Bootstrap: https://bulma.io/ https://bulma.io/
- aarpmcgee 4y ago
  interesting take! I started using tailwind with the classnames library early on and found it to be a really nice fit for my purposes. Also very interested in more tailwind-specific tools like tw-classed[1] [1]: https://tw-classed.vercel.app/ https://tw-classed.vercel.app/
- Bilal_io 4y ago
  I enjoy using tailwind, but I've only used it for side projects. Not sure if I'd use it for productionbfor the wall of class names issue you've mentioned. It can also be a big pull to swallow for many people, my professional recommendation is that almost always fimilar technology is better for devs. The goal of tailwind is the DX, and it seems to only acheive that with people that enjoy it. I know the statement seems obvious, but there are instances where you don't like a language or a framework, but it doesn't fight against you hence why I consider that a good DX.
AlwaysRock 4y ago
I've been using it regularly for the last 6 months and like it a lot. The blog points out the biggest switching over issues. Converting from rem to px can be annoying if you cant do that math in your head and at first you are often looking up the "simple" tailwinds way to write a css property that you already know. I pretty much always have the tailwinds docs open and thankfully they are very good and searchable. It does get a bit wordy when you try to do too much with it though. The nice part is you can always just plop a class in instead of doing everything with tailwinds.
- alayek 4y ago
  Regarding rem <-> px conversions, I follow this intuition: _multiply by 4 gives you px value, dividing by 4 gives you rem value._ `h-8` utility is height of 8 * 4 = 32px or 8 / 4 = 2 rem. Since design systems are supposed to be consistent, 4px is typically considered 1 unit of distance. However, there are times when I might encounter values in Figma (or get inputs from designer) that won't allow me to use this easily. Say, designer wants a max-width of 252px on an element. I usually use Alfred app on my work MBP to divide it quickly by 16 (since 1 rem is 16px under normal font-size settings), but you can use any calculator, even the one in Google search or DDG search. It turns out to be a fraction, and in this case, it's 15.75 rem. I use utility like `max-w-[16rem]`, closest consistent dimension that's a multiple of 1rem, and ship a pull request preview to the designer, asking for design feedback. Chances are, designer agrees to stick to 16rem, and we ship it as is. If this width of 16rem, or closer values within the 250px vicinity, are used in other places in the design system components or our app; I'd typically add that to the Tailwind config as well. Most of the time question of rem <-> px conversion comes into picture because we look at design dimensions in Figma / Sketch / Indesign etc. tools, and try to implement the same in our UI code. But this would only slow down a developer, switching back-and-forth between design and implementation. What I find more productive while prototyping a UI (or a smaller component), is to just "eye it", instead of getting actual pixel-values right at the first go. From just eye-ing it, I can make a guess if it should be h-3 or h-4 (you can also guess the right value using a binary search style heuristic), and if my implementation looks bigger (or smaller) than the design, I'd adjust accordingly. Only after I've implemented a basic prototype of the UI component, I'd cross-check with the design tool, and edit some utilities if necessary to get as close to the design as possible.
satvikpendem 4y ago
Having used Tailwind, once the class lists get large, it inevitably just becomes CSS classes again. My previous role had const headerStyles = ["bg-slate-100", "rounded-xl", "p-8" ...] ... <div className={...headerStyles} ... >...</div> and so on. So at that point, why use Tailwind anymore? Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like styled-components, emotion, etc. https://vanilla-extract.style https://vanilla-extract.style
- whacked_new 4y ago
  Thanks for the vanilla-extract recommendation, I'll be using this! In my case, tailwind was useful for providing a handy set of vocabularies for simple and common stylings. But once customizations start to pile on, we're back into SCSS. Using 2 systems at once meant additionally gluing them with the postcss toolchain, so effectively we have 3 preprocessors running for every style refresh. Looking in at TypeScript from the clojurescript ecosystem though, I'm still yet to see an equal to https://github.com/noprompt/garden https://github.com/noprompt/garden or https://github.com/Jarzka/stylefy https://github.com/Jarzka/stylefy: single language, excellent composability, compile-time anonymous class names, inline styles... almost like they solved CSS (except for typing) that said, tailwind's and SCSS's VS code integration is pretty amazing.
  - stephen 4y ago
    Fwiw to the avoid 80%-in-TW / 20%-in-SCSS-or-something-else dichotomy/complexity, we built Truss which brings TW (Tachyons) style abbreviations to the existing "something else" tool chain (Emotion in our case). So then everything goes through a single system. https://github.com/homebound-team/truss https://github.com/homebound-team/truss > tailwind's and SCSS's VS code integration is pretty amazing We get that too, by being just vanilla TypeScript, no editor-specific integration necessary. :-D (I've linked to Truss in another response, so will stop now. :-))
- themosaad 4y ago
  > Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like styled-components, emotion, etc. I like Vanilla-Extract! Didn't wanna add to the article by talking about it and other alternatives I tried. It solves the main two problems I encountered with Tailwind CSS by offering type-safety and low learning curve since you're mostly writing vanilla CSS. However, some of its issues are: - Isn't as widely supported as Tailwind CSS since it's exclusive to TypeScript (cannot use it in Laravel) - Requires a special integration with each framework (couldn't use it with Remix.run) - There's a runtime overhead when you use it inline via its Sprinkles package. Without it, you're back to thinking about class names and having your CSS in a separate file which I personally found not to be neither the most productive nor the most maintainable approach. That being said, Vanilla-Extract author has recently Joined Remix.run and I hope they address some of these points soon.
robszumski 4y ago
I love using just the grid/breakpoint part of Bootstrap and use it as grid.css. No need for complication, no preprocessor needed, etc.
qup 4y ago
> If I could do it over again I'd just use pixel values, like h-12 is .75rem (which is 12px by default). (External quote from the maintainer) Bit of a tangent, but what's the play here? The library is worse than it could be because of this reason. And of course you have adoption and don't want to break people's shit. Seems like we're missing out on "what could be."
- Aeolun 4y ago
  People should not have the power to set paddings of less than 4px, and only do so in increments of 4. If you do it this way it becomes harder for anyone to go wild with every variant of padding under 8/12.
734129837261 4y ago
I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to. Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful. In almost every single use case, using vanilla CSS or SCSS is far superior. For React projects (and Vue.js, and Svelte, and Angular), I'd recommend anyone to just use (S)CSS modules. It's so elegant and doesn't come with any of the disadvantages. Except maybe a slightly larger package size. Minimally so. Your framework of choice should be (or allow) code splitting to take place. And a few bytes more or less aren't going to make or break most websites.
- onion2k 4y ago
  It's loved by novices and those who don't know what they're doing, almost exclusively. I've been a frontend dev for 25 years and I quite like Tailwind. I'm not sure which category I fit into. I think it might be both. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. This is a really good example of where Tailwind is actually quite nice. Imagine if you didn't use a utility class, and instead you'd written your styles in plain old CSS or SCSS with "padding: 8px;" everywhere on your years-old-built-up-to-thousands-of-styles design. Replacing those is easy enough, but what about your SCSS mixins? Your CSS calc()s? The places where someone thought an element needed a bit more padding and used "padding: 9px" instead? Manually managing styles is hard. Tailwind makes it a bit easier, mainly because it encourages consistency and removes variability. Finding and replacing a "p-4" everywhere is trivial, and if you've used a library well rather than rolling out an ad hoc mix of things you can be quite confident your change will work everywhere. It's far from perfect but it's quite a well-thought out approach.
  - 4y ago
lloydatkinson 4y ago
Oh two tailwind hate threads today instead of the usual one at a time? Everyone as usual saying "long class lists" even though the literal home page tells you not to do this and to make components or partial views or whatever your tool of choice calls it. At least be inventive and follow the instructions before you start blaming something.
- throwayyy479087 4y ago
  If everyone using a tool is using it wrong, it’s a poorly designed tool
  - eberkund 4y ago
    Everybody isn’t though, just the people who are complaining.
    - lloydatkinson 4y ago
      This is exactly it, and the person you replied to should have known this. You simply can't look at people not reading the docs (or even the home page) who then moan about how the thing they are misusing isn't working - and then conclude it must be the fault of the thing instead of the people misusing the thing.
    - greenhatman 4y ago
      Some people would rather learn every CSS rule than spend 10 minutes reading the Tailwind docs.
  - deleted 4y ago
    [deleted]
- troysk 4y ago
  The homepage has multiple animated examples showing the use of utility class spamming.
- ducharmdev 4y ago
The5thElephant 4y ago
Tailwind certainly has some advantages and nice features, but the length of the class string when you need something common but complex like a custom styled checkbox including focus states, various hovers, media-queries, etc gets absurd and far more difficult to read, debug, and update. I think one of the primary reasons Tailwind is so popular is how poorly React deals with classes and styles. In other frameworks/libraries like Vue/Svelte CSS is treated as a first-class citizen with a lot of nice quality-of-life improvements that React teams are forced to implement using awful CSS-in-JS solutions or with Tailwind. You get single-file-components, scoped styles, etc, all out of the box and without having to learn a new abstraction. If the dev world wasn't a React monoculture (and more devs appreciated CSS deeply) I think you would see significantly less interest in Tailwind.
johnchristopher 4y ago
> This plugin would allow me to use my existing CSS knowledge by writing: <div class="display-flex align-items-center gap-8px border-radius-6px padding-4px" >  </div> > Instead of: <div class="flex items-center gap-2 rounded-full p-1">  </div> But... why ? I just don't get tailwind.
- themosaad 4y ago
  This is far from being the best example of WHY you should use Tailwind CSS. I wrote about the HOW. I'll try to write another article about the WHY soon.
  - johnchristopher 4y ago
    I think something clicked yesterday after reading a comment. It works for SPA/css-in-js/components-based projects, and this long class string is manageable as long as it is only present in one single place in the whole project (thinking about versioning and the mental model of where's what).
- esparrohack 4y ago
  My gripe is that it’s stuff I don’t always have to care about. If I’m not working with CSS it’s just noise. Whatever way that’s refactored, I only want to see that when I’m working with the styles and I don’t wanna do anything special for it either.
poetril 4y ago
Having used both Tailwind and a more traditional scss system in the past. I think my personal favorite is styled components[0]. It strikes a good balance between not having to move between many files, like you might find your self doing with traditional css/scss system. While being declarative and semantically easy to read. It is not perfect by any means, and in larger components/pages it can lead to some pretty long, difficult to reason about files. But its the best workflow I've had the opportunity to work with so far. [0] https://emotion.sh/docs/styled https://emotion.sh/docs/styled
- fragile_frogs 4y ago
  You could combine styled-components/emotion with something like open-props[0]. You get all the power that comes with CSS and a set of variables to help you create a consistent design. That's how I manage my styling. [0] https://open-props.style https://open-props.style
  - poetril 4y ago
    Ooo, that is very interesting. I will have to give that a shot, thanks for sharing!
darepublic 4y ago
I am tired of 'analysis' that looks like this: > Lightning-fast build times since March 15, 2021 Just put some numbers in there. Average code base size, average build time improvement since version x, etc. I can be the judge of whether that is "lighting fast" to me
- themosaad 4y ago
  > Just put some numbers in there. Average code base size, average build time improvement since version x, etc. I can be the judge of whether that is "lighting fast" to me Fair enough. The video I linked to has some numbers Though. It used to take 19.44s to produce a 12MB CSS file in development vs a 1.9s to produce 11KB CSS file since this feature was released. I believe it's even faster now (v3.1.8) as it only takes 260ms to produce a 29KB CSS file in one of my projects with dark mode and lots of variants.
skizm 4y ago
While we're here, what are the top CSS or front end frameworks that are just static CSS files (maybe a single JS file too) that I can either download or hotlink from a CDN? I usually fallback to bootstrap for personal projects or prototypes because it is as easy as including a CSS file and a JS file. No npm install or compile steps required.
mhoad 4y ago
I haven’t seen it mentioned in this thread but for those who like Tailwind in theory but hate all it’s drawbacks you might be interested in Open Props (https://open-props.style/ https://open-props.style/) which is put together by a member of Chrome’s devrel team. The first 10 minutes or so of this video is also a decent introduction it seems which will help put this project into context for you so you can see specifically what kinds of problems it solves in a way that Tailwind doesn’t and vice versa. https://youtu.be/O53MwmolKP4 https://youtu.be/O53MwmolKP4
- fragile_frogs 4y ago
  I've been looking for someone to mention open-props and I really enjoy using it.
- iudqnolq 4y ago
  That website has visual bugs and lag in Firefox. When I combine that with my general stereotypes about Chrome devrel I think this isn't for me.
skilled 4y ago
I recently came to the conclusion that the best way to write CSS is through a Design System and write all the CSS yourself. And when I say Design System - I mean it can be your own or it can be external. The problem with writing a lot of CSS is that you will eventually run in circles and repeat yourself on the same elements with only small differences. A design system lets you adjust it all at once through Variables, and as of recently - some of the more powerful Selectors and Pseudo-classes. It also makes it easier to switch a design so you don't inherently lose all your work. I don't have a strong opinion on Tailwind CSS because I don't use it but I am familiar with it. I know it hasn't been adopted inside CMS's all that much, but it is very popular when it comes to things like individual elements (cards, headers, etc.) because those individual elements will work universally across any Tailwind project.
- themosaad 4y ago
  I hope to work on a product where productivity isn't as essential as the quality of a design system to use such approach. Saw the folks behind a CSS-in-JS library (Stitches) move to it recently[1] However, they still saw the need for utility classes for cases where devs want to hack together something custom[2] [1]: https://twitter.com/colmtuite/status/1572918908637650944 https://twitter.com/colmtuite/status/1572918908637650944 [2]: https://twitter.com/colmtuite/status/1572918911301218305 https://twitter.com/colmtuite/status/1572918911301218305
icambron 4y ago
A lot of people I respect really like Tailwind, but I just don’t get it. Seems like you end up with walls of classes because you don’t name your compositions, and thus your design system doesn’t actually live anywhere. If you have a standard box in your design system with a certain padding, spacing, font size, and so on, are you really going to write out all its constituent properties every time you use it? How do you manage that effectively? As an alternative, use a scss mixin (or even just a class) called standard-box and then use it everywhere. Do that for all the major parts of your design and you’ve created a language with which to build individual chunks of UI. Modifying the design system itself isn’t free but it’s a lot easier than mapping the change to every use of every tailwind class.
- davnicwil 4y ago
  I think the usual solution here is just to make your standard box a component, as opposed to using a div with a class. Then if your design system changes, you just change the wall of tailwind classes in that single component file.
  - deleted 4y ago
    [deleted]
  - eurasiantiger 4y ago
    And now you are inventing your own Theme UI or Emotion
- terminal_d 4y ago
  It is possible to "group" tailwind classes. See https://gist.github.com/axeldouglas/7f45b2a862401c7b515c138e6c7d711b https://gist.github.com/axeldouglas/7f45b2a862401c7b515c138e...
- lghh 4y ago
  You manage this complexity the same way you manage the complexity of repeated code nearly anywhere else: you encapsulate. If you have a standard box (div + styles) that you use everywhere, abstract it in whatever way you're writing your application allows. For example, a component in React.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
wagslane 4y ago
I really like Tailwind, I see a lot of hate in this thread so I'll try to offer a counter-perspective. First of all, it's important to understand what Tailwind is good for, and what it's not good for. Tailwind is NOT a design framework. It doesn't dictate the "theme" of your app. I like to think of tailwind as a tool for writing "clean" css that encourages good UI/UX practices. We need to stop comparing it to Bootstrap. Tailwind is a tool that makes using "good practice" design simple and easy. If you haven't read Adam Wathan's "Refactoring UI", I'd recommend it. It's a book that helps developers make better UI/UX design decisions, and Tailwind is the framework that Adam developed that encourages a lot of those practices. On that note, my recommendation is, "Tailwind CSS is AMAZING if you're a small team of developers and you don't have a dedicated designer". Tailwind probably is NOT a great choice if you work with a team of designers and need everything to be super-custom and pixel-perfect. It's also important to note that tailwind is based on utility-classes. It can easily be used alongside "regular" css. I love that it gives a sane convention for writing that stupid "padding: 4px" class you're going to need. My old apps had crap like this that all did the same thing: .p-4 .pad .padding-4 .padding-button-4 After several developers got their hands on the CSS, and didn't realize there were already classes defined for what they needed.
- danielvaughn 4y ago
  Tailwind can be used very effectively with designers, so long as both teams agree on the scales used. All of that stuff can be modified to your designer's heart's content.
- conradfr 4y ago
  > We need to stop comparing it to Bootstrap. Bootstrap has actually a lot of utility classes (since v4 IIRC).
- yawnxyz 4y ago
  I have a lot of custom stuff like breakpoints and typefaces and new sizes. If your designers can work with the tailwinds configuration file it shouldn’t really be a problem
zupa-hu 4y ago
I think Tailwind is great but I agree with many of the issues raised. I desperately needed a _language_ instead of a framework back when Tailwind was still a framework. As I could not get any response from them, I ended up rolling my own called Turbo CSS - this was like 2 years before their compiled version came out. Take a look if you want to consider alternatives. https://developer.boomla.com/turbo-css https://developer.boomla.com/turbo-css I'd compare the two as Tailwind being primarily a framework, a language second, while Turbo is a language first. For example, in Turbo you write libraries and reference class names in libraries via `my.btn` instead of polluting the global namespace. It also has first class support for classes, like you can do `hover:my.btn`, which Tailwind doesn't support (to my best of knowledge, it definitely didn't back then). Also, Turbo has zero global side-effects, which makes it great if you don't control the entire codebase (think CSS reset).
- themosaad 4y ago
  Great work scratching your own itch! Not as easy addition to the workflow as it doesn't have a CLI but I think that's intentional or not a priority for you. I backed out from maintaining a big Tailwind CSS plugin let alone create my own solution. Similar to React, I don't think Tailwind CSS is easy to replace regardless of the slightly better alternatives that exist or might popup up due to its established community.
esparrohack 4y ago
This style comes and goes. Utility classes. Then a framework like bootstrap comes up. Then it’s back to utility classes. I feel like I’m taking crazy pills
- PainfullyNormal 4y ago
  > I feel like I’m taking crazy pills You're not. If you look hard enough, long enough, you'll see this same pattern in every corner of programming. Round and round, never forward.
  - mixmastamyk 4y ago
    With love we'll find a way, just give it time
  - esparrohack 4y ago
    Funny you said that cus there’s another “look ma no framework!” Thread today.
dang 4y ago
Ongoing related thread: Tailwind is a leaky abstraction - https://news.ycombinator.com/item?id=33787218 https://news.ycombinator.com/item?id=33787218 - Nov 2022 (272 comments)
kristo 4y ago
The root of the issue is that CSS itself has no good design pattern that scales well.
xet7 4y ago
Oh, someone uses Prettier or ESLint ? I removed those from my code, because those caused massive amounts of syntax fix commits. I recommend not adding both, they will fight with each other.
radicalriddler 4y ago
I try my best to use tailwind JUST as a utility library, and really utilize the @apply postcss function. I don't want 1000 classes in my HTML, I want to make re-usable classes filled with the tailwind styles from it's utility classes.
gg2222 4y ago
Haven't seen it mentioned, but if you like Tailwind, maybe take a look at UnoCSS: https://github.com/unocss/unocss https://github.com/unocss/unocss It is like the next evolution of Tailwind. See this blog post for full explanation: https://antfu.me/posts/reimagine-atomic-css https://antfu.me/posts/reimagine-atomic-css
- gg2222 4y ago
  Also, well looks like a lot of people here don't like this style of CSS coding. As someone who's been writing HTML since Netscape days, I find Tailwind/UnoCSS plus a modern web framework (React/Vue/Solid JS) the most productive way to develop websites ever. The main thing is in a single React or Solid JS component, you can have all the code, html and styling for a component in one file or most of the time in one function even. No more having to deal with jumping around between template and css files, having to search for where a class or a styling is defined, or trying to figure out how to structure or even name the css classes. No more having to make decisions like "Should I put this styling in this class or that class or in a classless selector." For me, it just saves too much time to not use. I was skeptical at first, but once I started using it, I could never go back.
emmacharp 4y ago
The problem for me is that Mr Wathan misrepresented « Good CSS » in his essay. His examples are BAD CSS, not good CSS. He then sets out to correct a problem with CSS that HE created by writing dirt poor CSS. `.author-bio > div > h2 { color: red } is NOT good CSS. The div part has no reason being there (why would the div change the color of the title ?). After presenting this auto-created problem, he sets out to solve it with BEM, where you need untold numbers of classes for everything. So now, CSS has a naming problem, created to solve a non-existing auto-created CSS problem. And Tailwind now solves this pseudo-problem. Apart from this, the thing that really bugs me is that every advantage claimed (apart from one) is also non-existing because if you do your CSS right, the same claimed advantages arise in pure CSS. Design tokens ? No need for json, custom properties are all you need. Specificity ? Cascade layers, pseudo-selectors are here for you. The only "advantage" I see is the possibility of working in one file only rather than a couple of files. And that, for me at least, is not a real advantage but only a justification for being lazy. There's no way the price of all these processes and dependencies complexity are worth the laziness-added value.

154 points by themosaad 4y ago

Nice to see this on the front page at the same time that a negative about Tailwind article pops up. Especially since I'm currently looking at whether to start using Tailwind. It's good to read multiple, conflicting, opinions about something.

Zealotux 4y ago

I don't like Tailwind, except for pure layouting where it truly shines. My belief is this: we should think of layouting and styling as two distinct concepts and it doesn't help that CSS is used for both. After years of experimenting with various CSS approaches, I believe using Tailwind for layout and styled-components for styles is the ultimate setup for React applications.

daigoba66 4y ago
How do you distinguish what is "layout" versus "style"? I know there are some obvious things, but like you said CSS is used for both. So there is a lot "grey area". Especially when "style" can affect the "layout".
- pessimizer 4y ago
  Having gray area doesn't mean you can't separate purposes whenever possible (if that's what you want to do.)
unsupp0rted 4y ago
Same feeling here. In Tailwind, I'll use a `p-3` or a `.flex.items-center` all day, but making a nice button is such a slog, since I'm coming from a Vuetify background. Vuetify also has the same layout classes as Tailwind, like `pa-3` and `.d-flex.align-center` I use Vuetify + Pug (instead of raw HTML templates), so I get to make buttons like this: v-btn(outlined color="accent" @click="handleClick") Do Stuff or a Data Table with, say, a custom-formatted UPC column, like this: v-data-table(:loading="loading", :items="items", :headers="headers", :items-per-page="50" dense).my-3 template(v-slot:item.upc="{ item }") span {{formatUpc(item.upc)}} (I like to separate attributes with commas, which is valid pug but invalid HTML) Sure, I could get something like TailwindUI, but their components are walls of divs and classes that each take half an hour to load into my head to visualize what's creating all the combos of states (regular, hover, focus). So my Vuetify + Pug approach works great for greenfield projects that I create. But if I'm downloading a nice template for a side project, say from Cruip.com, it's not like they're going to use the same build chain as me, and they do have to settle on a standard CSS library, so they default to Tailwind (just like 5~10 years ago they would have defaulted to Bootstrap).
- nightski 4y ago
  I mean what is stopping you from making a Button component once w/ Tailwind similar to Vuetify?
  - unsupp0rted 4y ago
    I've used probably 50~80% of Vuetify if taking together the last dozen projects I've done. I'd basically have to re-implement all of Vuetify in Tailwind, from buttons to chips to toggles to alerts, etc? The v-data-table is like 10 sub-components stuck together, each of which I'd have to re-implement with walls of Tailwind classes.
- sgt 4y ago
  The secret of TailwindUI is to take the HTML version of their code and just built your own components (e.g. if using VueJS). I would not use their suggested VueJS examples, as generally I prefer the options API. It does however add some extra time to build your app - but consider that they have already built 90% for you - in terms of the design etc.

joshmn 4y ago

I have been working with HTML since I was 11 — 20ish years. I thought I knew most things. text-decoration-thickness? Nope. I have been adding border-bottom to spans for far too long it looks like.

qiller 4y ago
Those are pretty new. text-underline-offset is another one that made my "fake" underlines obsolete
- Gualdrapo 4y ago
  Also remember text-decoration-style, text-decoration-color and text-decoration-skip - setting this last one to 'ink' will make the underline, ahem, skip over the glyphs with descenders, adding to legibility
philliphaydon 4y ago
I started html when I was about 11 so I’m at 25 years. I just discovered last night there’s an aspect ratio property… https://caniuse.com/mdn-css_properties_aspect-ratio https://caniuse.com/mdn-css_properties_aspect-ratio
- dekerta 4y ago
  aspect-ratio is a new standard, so don't feel too bad about that
- pewpewyouhit 4y ago
  It’s pretty new though. Less than 2 years I think.
  - philliphaydon 4y ago
    I was just shocked. Last night I’m like “hmm need to maintain aspect ratio on this box. Maybe I can use calc and vh or something. And this shocked up in Google. Rocked my world. I wanna go back across a bunch of products I’ve worked on over the years to fix stuff using this! One of my favourite features now!

zagrebian 4y ago

Does that blog have an RSS feed?

aobdev 4y ago

Slightly off topic, but you can chain your language selectors in VS Code settings so that: "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, "[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, Becomes: "[javascript][typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }

idbehold 4y ago
Wow thanks for this as it's not at all mentioned in the help text for these (Configure editor settings to be overridden for a language.). Also what a strange choice for multiple languages since there can clearly be conflicts this way: "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, "[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }, "[javascript][typescript]": { "editor.defaultFormatter": "something.else" } If they're going to allow conflicts anyways, just invert the structure so you at least get to use normal arrays: "editor.defaultFormatter": { "esbenp.prettier-vscode": ["typescript", "javascript"] } Though, I guess the logic is that the other format allows you to override ANY setting based on language.

deliriumchn 4y ago

I'll be honest here, after working with tailwind for 7 months I really hate this piece of tech and really regret picking this company. I thought it wouldn't be a big deal but after seeing unnecessary long walls of class names I'm really tired. Anything other than basic styling is an absolute pain with tailwind and I don't understand why /my company specifically/ can't just use typestyle/styled-components/css modules to separate walls of text from components. With time, I degraded to the point I where I use classnames library just to split longer class string into 3-4 smaller ones so I can split the component into multiple rows to make it look better

tuyenhx 4y ago
I have the same thought. Bootstrap is still my favorite choice.
- mozey 4y ago
  Yeah, I used Bootstrap for a long time, and got used to how it works. I wanted to like Tailwind, but it seems a bit disingenuous. It's like using inline style tags, just with shorter names. From time to time I've made an effort to learn how CSS works, but after a while I forget the details. It's more productive if I can browse a catalogue of visual examples, with concise markup that is easy to copy and paste. Bulma seems like the more "modern" take on Bootstrap: https://bulma.io/ https://bulma.io/
aarpmcgee 4y ago
interesting take! I started using tailwind with the classnames library early on and found it to be a really nice fit for my purposes. Also very interested in more tailwind-specific tools like tw-classed[1] [1]: https://tw-classed.vercel.app/ https://tw-classed.vercel.app/
Bilal_io 4y ago
I enjoy using tailwind, but I've only used it for side projects. Not sure if I'd use it for productionbfor the wall of class names issue you've mentioned. It can also be a big pull to swallow for many people, my professional recommendation is that almost always fimilar technology is better for devs. The goal of tailwind is the DX, and it seems to only acheive that with people that enjoy it. I know the statement seems obvious, but there are instances where you don't like a language or a framework, but it doesn't fight against you hence why I consider that a good DX.

AlwaysRock 4y ago

I've been using it regularly for the last 6 months and like it a lot. The blog points out the biggest switching over issues. Converting from rem to px can be annoying if you cant do that math in your head and at first you are often looking up the "simple" tailwinds way to write a css property that you already know. I pretty much always have the tailwinds docs open and thankfully they are very good and searchable. It does get a bit wordy when you try to do too much with it though. The nice part is you can always just plop a class in instead of doing everything with tailwinds.

alayek 4y ago
Regarding rem <-> px conversions, I follow this intuition: _multiply by 4 gives you px value, dividing by 4 gives you rem value._ `h-8` utility is height of 8 * 4 = 32px or 8 / 4 = 2 rem. Since design systems are supposed to be consistent, 4px is typically considered 1 unit of distance. However, there are times when I might encounter values in Figma (or get inputs from designer) that won't allow me to use this easily. Say, designer wants a max-width of 252px on an element. I usually use Alfred app on my work MBP to divide it quickly by 16 (since 1 rem is 16px under normal font-size settings), but you can use any calculator, even the one in Google search or DDG search. It turns out to be a fraction, and in this case, it's 15.75 rem. I use utility like `max-w-[16rem]`, closest consistent dimension that's a multiple of 1rem, and ship a pull request preview to the designer, asking for design feedback. Chances are, designer agrees to stick to 16rem, and we ship it as is. If this width of 16rem, or closer values within the 250px vicinity, are used in other places in the design system components or our app; I'd typically add that to the Tailwind config as well. Most of the time question of rem <-> px conversion comes into picture because we look at design dimensions in Figma / Sketch / Indesign etc. tools, and try to implement the same in our UI code. But this would only slow down a developer, switching back-and-forth between design and implementation. What I find more productive while prototyping a UI (or a smaller component), is to just "eye it", instead of getting actual pixel-values right at the first go. From just eye-ing it, I can make a guess if it should be h-3 or h-4 (you can also guess the right value using a binary search style heuristic), and if my implementation looks bigger (or smaller) than the design, I'd adjust accordingly. Only after I've implemented a basic prototype of the UI component, I'd cross-check with the design tool, and edit some utilities if necessary to get as close to the design as possible.

satvikpendem 4y ago

Having used Tailwind, once the class lists get large, it inevitably just becomes CSS classes again. My previous role had const headerStyles = ["bg-slate-100", "rounded-xl", "p-8" ...] ... <div className={...headerStyles} ... >...</div> and so on. So at that point, why use Tailwind anymore? Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like styled-components, emotion, etc. https://vanilla-extract.style https://vanilla-extract.style

whacked_new 4y ago
Thanks for the vanilla-extract recommendation, I'll be using this! In my case, tailwind was useful for providing a handy set of vocabularies for simple and common stylings. But once customizations start to pile on, we're back into SCSS. Using 2 systems at once meant additionally gluing them with the postcss toolchain, so effectively we have 3 preprocessors running for every style refresh. Looking in at TypeScript from the clojurescript ecosystem though, I'm still yet to see an equal to https://github.com/noprompt/garden https://github.com/noprompt/garden or https://github.com/Jarzka/stylefy https://github.com/Jarzka/stylefy: single language, excellent composability, compile-time anonymous class names, inline styles... almost like they solved CSS (except for typing) that said, tailwind's and SCSS's VS code integration is pretty amazing.
- stephen 4y ago
  Fwiw to the avoid 80%-in-TW / 20%-in-SCSS-or-something-else dichotomy/complexity, we built Truss which brings TW (Tachyons) style abbreviations to the existing "something else" tool chain (Emotion in our case). So then everything goes through a single system. https://github.com/homebound-team/truss https://github.com/homebound-team/truss > tailwind's and SCSS's VS code integration is pretty amazing We get that too, by being just vanilla TypeScript, no editor-specific integration necessary. :-D (I've linked to Truss in another response, so will stop now. :-))
themosaad 4y ago
> Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like styled-components, emotion, etc. I like Vanilla-Extract! Didn't wanna add to the article by talking about it and other alternatives I tried. It solves the main two problems I encountered with Tailwind CSS by offering type-safety and low learning curve since you're mostly writing vanilla CSS. However, some of its issues are: - Isn't as widely supported as Tailwind CSS since it's exclusive to TypeScript (cannot use it in Laravel) - Requires a special integration with each framework (couldn't use it with Remix.run) - There's a runtime overhead when you use it inline via its Sprinkles package. Without it, you're back to thinking about class names and having your CSS in a separate file which I personally found not to be neither the most productive nor the most maintainable approach. That being said, Vanilla-Extract author has recently Joined Remix.run and I hope they address some of these points soon.

robszumski 4y ago

I love using just the grid/breakpoint part of Bootstrap and use it as grid.css. No need for complication, no preprocessor needed, etc.

qup 4y ago

> If I could do it over again I'd just use pixel values, like h-12 is .75rem (which is 12px by default). (External quote from the maintainer) Bit of a tangent, but what's the play here? The library is worse than it could be because of this reason. And of course you have adoption and don't want to break people's shit. Seems like we're missing out on "what could be."

Aeolun 4y ago
People should not have the power to set paddings of less than 4px, and only do so in increments of 4. If you do it this way it becomes harder for anyone to go wild with every variant of padding under 8/12.

734129837261 4y ago

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. And since there is no context to it, it'll be hard to JUST replace them where you would want them to. Vanilla CSS using `:root` declaration, a fixed base size (using `rem` and `em`), CSS variables and `calc()` are SO powerful. In almost every single use case, using vanilla CSS or SCSS is far superior. For React projects (and Vue.js, and Svelte, and Angular), I'd recommend anyone to just use (S)CSS modules. It's so elegant and doesn't come with any of the disadvantages. Except maybe a slightly larger package size. Minimally so. Your framework of choice should be (or allow) code splitting to take place. And a few bytes more or less aren't going to make or break most websites.

onion2k 4y ago
It's loved by novices and those who don't know what they're doing, almost exclusively. I've been a frontend dev for 25 years and I quite like Tailwind. I'm not sure which category I fit into. I think it might be both. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. This is a really good example of where Tailwind is actually quite nice. Imagine if you didn't use a utility class, and instead you'd written your styles in plain old CSS or SCSS with "padding: 8px;" everywhere on your years-old-built-up-to-thousands-of-styles design. Replacing those is easy enough, but what about your SCSS mixins? Your CSS calc()s? The places where someone thought an element needed a bit more padding and used "padding: 9px" instead? Manually managing styles is hard. Tailwind makes it a bit easier, mainly because it encourages consistency and removes variability. Finding and replacing a "p-4" everywhere is trivial, and if you've used a library well rather than rolling out an ad hoc mix of things you can be quite confident your change will work everywhere. It's far from perfect but it's quite a well-thought out approach.
- 4y ago

lloydatkinson 4y ago

Oh two tailwind hate threads today instead of the usual one at a time? Everyone as usual saying "long class lists" even though the literal home page tells you not to do this and to make components or partial views or whatever your tool of choice calls it. At least be inventive and follow the instructions before you start blaming something.

throwayyy479087 4y ago
If everyone using a tool is using it wrong, it’s a poorly designed tool
- eberkund 4y ago
  Everybody isn’t though, just the people who are complaining.
  - lloydatkinson 4y ago
    This is exactly it, and the person you replied to should have known this. You simply can't look at people not reading the docs (or even the home page) who then moan about how the thing they are misusing isn't working - and then conclude it must be the fault of the thing instead of the people misusing the thing.
  - greenhatman 4y ago
    Some people would rather learn every CSS rule than spend 10 minutes reading the Tailwind docs.
- deleted 4y ago
  [deleted]
troysk 4y ago
The homepage has multiple animated examples showing the use of utility class spamming.
ducharmdev 4y ago

The5thElephant 4y ago

Tailwind certainly has some advantages and nice features, but the length of the class string when you need something common but complex like a custom styled checkbox including focus states, various hovers, media-queries, etc gets absurd and far more difficult to read, debug, and update. I think one of the primary reasons Tailwind is so popular is how poorly React deals with classes and styles. In other frameworks/libraries like Vue/Svelte CSS is treated as a first-class citizen with a lot of nice quality-of-life improvements that React teams are forced to implement using awful CSS-in-JS solutions or with Tailwind. You get single-file-components, scoped styles, etc, all out of the box and without having to learn a new abstraction. If the dev world wasn't a React monoculture (and more devs appreciated CSS deeply) I think you would see significantly less interest in Tailwind.

johnchristopher 4y ago

> This plugin would allow me to use my existing CSS knowledge by writing: <div class="display-flex align-items-center gap-8px border-radius-6px padding-4px" >  </div> > Instead of: <div class="flex items-center gap-2 rounded-full p-1">  </div> But... why ? I just don't get tailwind.

themosaad 4y ago
This is far from being the best example of WHY you should use Tailwind CSS. I wrote about the HOW. I'll try to write another article about the WHY soon.
- johnchristopher 4y ago
  I think something clicked yesterday after reading a comment. It works for SPA/css-in-js/components-based projects, and this long class string is manageable as long as it is only present in one single place in the whole project (thinking about versioning and the mental model of where's what).
esparrohack 4y ago
My gripe is that it’s stuff I don’t always have to care about. If I’m not working with CSS it’s just noise. Whatever way that’s refactored, I only want to see that when I’m working with the styles and I don’t wanna do anything special for it either.

poetril 4y ago

Having used both Tailwind and a more traditional scss system in the past. I think my personal favorite is styled components[0]. It strikes a good balance between not having to move between many files, like you might find your self doing with traditional css/scss system. While being declarative and semantically easy to read. It is not perfect by any means, and in larger components/pages it can lead to some pretty long, difficult to reason about files. But its the best workflow I've had the opportunity to work with so far. [0] https://emotion.sh/docs/styled https://emotion.sh/docs/styled

fragile_frogs 4y ago
You could combine styled-components/emotion with something like open-props[0]. You get all the power that comes with CSS and a set of variables to help you create a consistent design. That's how I manage my styling. [0] https://open-props.style https://open-props.style
- poetril 4y ago
  Ooo, that is very interesting. I will have to give that a shot, thanks for sharing!

darepublic 4y ago

I am tired of 'analysis' that looks like this: > Lightning-fast build times since March 15, 2021 Just put some numbers in there. Average code base size, average build time improvement since version x, etc. I can be the judge of whether that is "lighting fast" to me

themosaad 4y ago
> Just put some numbers in there. Average code base size, average build time improvement since version x, etc. I can be the judge of whether that is "lighting fast" to me Fair enough. The video I linked to has some numbers Though. It used to take 19.44s to produce a 12MB CSS file in development vs a 1.9s to produce 11KB CSS file since this feature was released. I believe it's even faster now (v3.1.8) as it only takes 260ms to produce a 29KB CSS file in one of my projects with dark mode and lots of variants.

skizm 4y ago

While we're here, what are the top CSS or front end frameworks that are just static CSS files (maybe a single JS file too) that I can either download or hotlink from a CDN? I usually fallback to bootstrap for personal projects or prototypes because it is as easy as including a CSS file and a JS file. No npm install or compile steps required.

mhoad 4y ago

I haven’t seen it mentioned in this thread but for those who like Tailwind in theory but hate all it’s drawbacks you might be interested in Open Props (https://open-props.style/ https://open-props.style/) which is put together by a member of Chrome’s devrel team. The first 10 minutes or so of this video is also a decent introduction it seems which will help put this project into context for you so you can see specifically what kinds of problems it solves in a way that Tailwind doesn’t and vice versa. https://youtu.be/O53MwmolKP4 https://youtu.be/O53MwmolKP4

fragile_frogs 4y ago
I've been looking for someone to mention open-props and I really enjoy using it.
iudqnolq 4y ago
That website has visual bugs and lag in Firefox. When I combine that with my general stereotypes about Chrome devrel I think this isn't for me.

skilled 4y ago

I recently came to the conclusion that the best way to write CSS is through a Design System and write all the CSS yourself. And when I say Design System - I mean it can be your own or it can be external. The problem with writing a lot of CSS is that you will eventually run in circles and repeat yourself on the same elements with only small differences. A design system lets you adjust it all at once through Variables, and as of recently - some of the more powerful Selectors and Pseudo-classes. It also makes it easier to switch a design so you don't inherently lose all your work. I don't have a strong opinion on Tailwind CSS because I don't use it but I am familiar with it. I know it hasn't been adopted inside CMS's all that much, but it is very popular when it comes to things like individual elements (cards, headers, etc.) because those individual elements will work universally across any Tailwind project.

themosaad 4y ago
I hope to work on a product where productivity isn't as essential as the quality of a design system to use such approach. Saw the folks behind a CSS-in-JS library (Stitches) move to it recently[1] However, they still saw the need for utility classes for cases where devs want to hack together something custom[2] [1]: https://twitter.com/colmtuite/status/1572918908637650944 https://twitter.com/colmtuite/status/1572918908637650944 [2]: https://twitter.com/colmtuite/status/1572918911301218305 https://twitter.com/colmtuite/status/1572918911301218305

icambron 4y ago

A lot of people I respect really like Tailwind, but I just don’t get it. Seems like you end up with walls of classes because you don’t name your compositions, and thus your design system doesn’t actually live anywhere. If you have a standard box in your design system with a certain padding, spacing, font size, and so on, are you really going to write out all its constituent properties every time you use it? How do you manage that effectively? As an alternative, use a scss mixin (or even just a class) called standard-box and then use it everywhere. Do that for all the major parts of your design and you’ve created a language with which to build individual chunks of UI. Modifying the design system itself isn’t free but it’s a lot easier than mapping the change to every use of every tailwind class.

davnicwil 4y ago
I think the usual solution here is just to make your standard box a component, as opposed to using a div with a class. Then if your design system changes, you just change the wall of tailwind classes in that single component file.
- deleted 4y ago
  [deleted]
- eurasiantiger 4y ago
  And now you are inventing your own Theme UI or Emotion
terminal_d 4y ago
It is possible to "group" tailwind classes. See https://gist.github.com/axeldouglas/7f45b2a862401c7b515c138e6c7d711b https://gist.github.com/axeldouglas/7f45b2a862401c7b515c138e...
lghh 4y ago
You manage this complexity the same way you manage the complexity of repeated code nearly anywhere else: you encapsulate. If you have a standard box (div + styles) that you use everywhere, abstract it in whatever way you're writing your application allows. For example, a component in React.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

wagslane 4y ago

I really like Tailwind, I see a lot of hate in this thread so I'll try to offer a counter-perspective. First of all, it's important to understand what Tailwind is good for, and what it's not good for. Tailwind is NOT a design framework. It doesn't dictate the "theme" of your app. I like to think of tailwind as a tool for writing "clean" css that encourages good UI/UX practices. We need to stop comparing it to Bootstrap. Tailwind is a tool that makes using "good practice" design simple and easy. If you haven't read Adam Wathan's "Refactoring UI", I'd recommend it. It's a book that helps developers make better UI/UX design decisions, and Tailwind is the framework that Adam developed that encourages a lot of those practices. On that note, my recommendation is, "Tailwind CSS is AMAZING if you're a small team of developers and you don't have a dedicated designer". Tailwind probably is NOT a great choice if you work with a team of designers and need everything to be super-custom and pixel-perfect. It's also important to note that tailwind is based on utility-classes. It can easily be used alongside "regular" css. I love that it gives a sane convention for writing that stupid "padding: 4px" class you're going to need. My old apps had crap like this that all did the same thing: .p-4 .pad .padding-4 .padding-button-4 After several developers got their hands on the CSS, and didn't realize there were already classes defined for what they needed.

danielvaughn 4y ago
Tailwind can be used very effectively with designers, so long as both teams agree on the scales used. All of that stuff can be modified to your designer's heart's content.
conradfr 4y ago
> We need to stop comparing it to Bootstrap. Bootstrap has actually a lot of utility classes (since v4 IIRC).
yawnxyz 4y ago
I have a lot of custom stuff like breakpoints and typefaces and new sizes. If your designers can work with the tailwinds configuration file it shouldn’t really be a problem

zupa-hu 4y ago

I think Tailwind is great but I agree with many of the issues raised. I desperately needed a _language_ instead of a framework back when Tailwind was still a framework. As I could not get any response from them, I ended up rolling my own called Turbo CSS - this was like 2 years before their compiled version came out. Take a look if you want to consider alternatives. https://developer.boomla.com/turbo-css https://developer.boomla.com/turbo-css I'd compare the two as Tailwind being primarily a framework, a language second, while Turbo is a language first. For example, in Turbo you write libraries and reference class names in libraries via `my.btn` instead of polluting the global namespace. It also has first class support for classes, like you can do `hover:my.btn`, which Tailwind doesn't support (to my best of knowledge, it definitely didn't back then). Also, Turbo has zero global side-effects, which makes it great if you don't control the entire codebase (think CSS reset).

themosaad 4y ago
Great work scratching your own itch! Not as easy addition to the workflow as it doesn't have a CLI but I think that's intentional or not a priority for you. I backed out from maintaining a big Tailwind CSS plugin let alone create my own solution. Similar to React, I don't think Tailwind CSS is easy to replace regardless of the slightly better alternatives that exist or might popup up due to its established community.

esparrohack 4y ago

This style comes and goes. Utility classes. Then a framework like bootstrap comes up. Then it’s back to utility classes. I feel like I’m taking crazy pills

PainfullyNormal 4y ago
> I feel like I’m taking crazy pills You're not. If you look hard enough, long enough, you'll see this same pattern in every corner of programming. Round and round, never forward.
- mixmastamyk 4y ago
  With love we'll find a way, just give it time
- esparrohack 4y ago
  Funny you said that cus there’s another “look ma no framework!” Thread today.

dang 4y ago

Ongoing related thread: Tailwind is a leaky abstraction - https://news.ycombinator.com/item?id=33787218 https://news.ycombinator.com/item?id=33787218 - Nov 2022 (272 comments)

kristo 4y ago

The root of the issue is that CSS itself has no good design pattern that scales well.

xet7 4y ago

Oh, someone uses Prettier or ESLint ? I removed those from my code, because those caused massive amounts of syntax fix commits. I recommend not adding both, they will fight with each other.

radicalriddler 4y ago

I try my best to use tailwind JUST as a utility library, and really utilize the @apply postcss function. I don't want 1000 classes in my HTML, I want to make re-usable classes filled with the tailwind styles from it's utility classes.

gg2222 4y ago

Haven't seen it mentioned, but if you like Tailwind, maybe take a look at UnoCSS: https://github.com/unocss/unocss https://github.com/unocss/unocss It is like the next evolution of Tailwind. See this blog post for full explanation: https://antfu.me/posts/reimagine-atomic-css https://antfu.me/posts/reimagine-atomic-css

gg2222 4y ago
Also, well looks like a lot of people here don't like this style of CSS coding. As someone who's been writing HTML since Netscape days, I find Tailwind/UnoCSS plus a modern web framework (React/Vue/Solid JS) the most productive way to develop websites ever. The main thing is in a single React or Solid JS component, you can have all the code, html and styling for a component in one file or most of the time in one function even. No more having to deal with jumping around between template and css files, having to search for where a class or a styling is defined, or trying to figure out how to structure or even name the css classes. No more having to make decisions like "Should I put this styling in this class or that class or in a classless selector." For me, it just saves too much time to not use. I was skeptical at first, but once I started using it, I could never go back.

emmacharp 4y ago

The problem for me is that Mr Wathan misrepresented « Good CSS » in his essay. His examples are BAD CSS, not good CSS. He then sets out to correct a problem with CSS that HE created by writing dirt poor CSS. `.author-bio > div > h2 { color: red } is NOT good CSS. The div part has no reason being there (why would the div change the color of the title ?). After presenting this auto-created problem, he sets out to solve it with BEM, where you need untold numbers of classes for everything. So now, CSS has a naming problem, created to solve a non-existing auto-created CSS problem. And Tailwind now solves this pseudo-problem. Apart from this, the thing that really bugs me is that every advantage claimed (apart from one) is also non-existing because if you do your CSS right, the same claimed advantages arise in pure CSS. Design tokens ? No need for json, custom properties are all you need. Specificity ? Cascade layers, pseudo-selectors are here for you. The only "advantage" I see is the possibility of working in one file only rather than a couple of files. And that, for me at least, is not a real advantage but only a justification for being lazy. There's no way the price of all these processes and dependencies complexity are worth the laziness-added value.