23 ms·

Why I don't like Tailwind CSS

• jawngee 6y ago
  I used to think like this for a long time, but after using Tailwind on real projects - there is a definite moment when it clicks and you wonder why you've been doing it any other way.
• seanwilson 6y ago
  Nice article, just some of my opinion on the points raised: > In my personal experience, poor naming conventions (or just poor variable names in general) are the source of a lot of confusion when other people read your code. I would rather look at some CSS that has padding: 0.25rem or margin: 0.5rem instead of trying to mentally map Tailwind’s p-1 or m-2 to their CSS equivalents. Short names for commonly used concepts helps readability (quick to read, takes up less space) and makes it less tiring to type + change. It super tiresome to write long winded CSS (media queries are especially bad for this) and then find out you went in the wrong direction and have to rewrite it. > Look, I don’t like Tailwind for lots of reasons. But none of them are nearly as concerning to me as vendor lock-in. It’s why I don’t want to invest time in migrating existing projects to Tailwind, and why I’d be reluctant to use it for any new projects. Is this a real concern? I've migrated sites from custom CSS -> Bootstrap, Bootstrap -> Foundation, Bootstrap -> custom CSS etc. and it's always painful not matter what. At least with utility classes, you don't get problems where you're scared to delete CSS because you're never really sure where it's being shared. You generally just want to rip out all the previous stuff too as combining two frameworks isn't practical. > For starters, if you’re not sure what to call that <div> in your markup, consider whether it’s actually needed. One of the great things about the Semantic CSS paradigm is that it forces you to structure your markup logically and meaningfully. I think what makes utility classes nice for custom designs is there really aren't good semantic names for a lot of things that are only there for presentation reasons. Like I need to put a <div> around the heading + intro text so I can add some padding between those and the screenshot under it...so call it `.intro-wrapper`? Now there's a CSS quirk that requires me to wrap that all in the <div> so call it `.intro-container`? I want to make the three lines of the header animate in one by one so call them `.header-line1`, `.header-line2`, `.header-line3`? It's tiresome coming up with name for stuff like this you only use once and even more so when you're experimenting and might not even need them. It's just noise that requires you to keep jumping between your CSS and HTML definitions to get anything done. Use semantic HTML tags like <header> <h1> etc. and custom class names for things you're sure you're going to reuse though. Either way, utility classes is yet another "it depends" choice where there's no single answer. Use it where it makes sense.
• mouzogu 6y ago
  I find it good for quick prototyping or personal demo projects but I wouldn't use recommend it for a large project with many contributors. The trade-off between having messy html for faster development or css-in-js is not worth it for me. I still don't like mixing html (jsx) with javascript. I'm an old-school seperation of code vs concerns.
  • cageface 6y ago
    Large projects with many contributors is exactly where Tailwind shines. It prevents that ever growing pile of intractable mud that every CSS codebase tends to turn into over time.
    • jack_riminton 6y ago
      and provides shorthand that everyone understands "-pt-5" is simple and universal once you've learned the shorthand
    • aphextron 6y ago
      >"It prevents that ever growing pile of intractable mud that every CSS codebase tends to turn into over time" This is why the key is not having a seperate CSS codebase. The separation of CSS and JS is just a legacy of web development from the time before component based application development. At most you might need a common source of basic variables like theme colors. But essentially everything else should be scoped within the context of an individual component, and live directly within that component. Huge stylesheets with specific selectors and complicated BEM style class names just aren't necessary anymore.
      • cageface 6y ago
        I’ve built big sites this way too and it’s a small improvement over pure CSS methods but still much less productive and maintainable than the utility approach.
  • matthewmacleod 6y ago
    I still don't like mixing html (jsx) with javascript Your problem here is thinking of JSX as HTML instead of what it really is – a thin syntactical layer on top of Javascript.
• high_byte 6y ago
  >This means that you have to first learn Tailwind’s specific syntax before you can fluently string its utility classes together to achieve powerful results. what kind of argument is that?
  • tiborsaas 6y ago
    It's indeed a weird one. Like how is it a problem that one has to a lean a framework? Just RTFM.
  • aphextron 6y ago
    > what kind of argument is that? A pretty strong one. If I'm maintaining a project, I really do not want to spend my time learning some random DSL made up of obscure class names with abbreviated letters and numbers just to change the padding on a div. The component based approach is infinitely more maintainable. Things like Tailwind are fine for quickly prototyping something if you can't be bothered with design or styling at the time. But long term they are a maintenance nightmare.
    • criswell 6y ago
      If you want to change the padding in a project that's using Tailwind you only need to look for classes that begin with `p` followed by a letter for a side or x and y for an axis (same is true for margins). Those are by far the most cryptic classnames and by the time you finish reading this sentence you got it. In a project where you have to name everything semantically you don't know where the hell the padding is going to be. It's amazing for long term maintainability and quick prototyping. There is a lot of value in classes that does one thing well. Been wrinting CSS for 15 years, switched to Tailwind 2 years ago, just for reference.
    • cageface 6y ago
      I’ve done plenty of big sites with the component based approach and they are anything but maintainable.
      • lex0r 6y ago
• nickjj 6y ago
  #3 can be solved with PurgeCSS. OP wrote: > Because every new class name that you introduce could have potentially hundreds of property-value combinations, and that translates to more compiled CSS—which, of course, means a larger network request, and potentially slower performance. After PurgeCSS you can end up with a 15kb CSS bundled payload even before gzip for a decently sized site. That's so much smaller than most other CSS libraries because Tailwind is very purge friendly.
  • cageface 6y ago
    Unlike other methods I’ve seen Tailwind based projects result in very small CSS payloads that tend to grow asymptotically over time instead of getting bigger and more bloated over time as people keep adding new “semantic” classes.
  • gpspake 6y ago
    And purge css is not some "other thing" you have to go get to use tailwind effectively, it's built in! You don't need webpack in the mix or whatever, you just need a couple of lines in your tailwind config. In real life, tailwind produces the smallest dist files of anything I've used just because the built in treeshaking thing is just effortless and works so well. (Clearly this is my least favorite "I don't like tailwind" gripe lol)
  • davidwparker 6y ago
    Came looking for this comment. 100% agreed, and it seems like the author didn't even try? My site https://www.listenaddict.com/ https://www.listenaddict.com/ is 5.6kg for all the core/layout, and then another 1.6kg for the color theme (I have 12x themes and they're all separate, so the user only has to load one of them). If anything, Tailwind is the opposite of bloat.
• onli 6y ago
  Many good arguments against tailwind here. The whole approach of using a framework with opaque variable names and not chaining instead of real CSS can be criticized, and the article does it well. Though maybe I missed it, but it is actually nice to write a site with such CSS frameworks, be it tailwind or something else, so that should be noted. Reading the code and changing it, that's a different story. However: The author writes a good critique here, and then destroys all of it by favoring the eternal sin of CSS-in-JS instead. If tailwind has its flaws, CSS in JS is the worst approach thinkable, something no web developer would ever do. I'm aware that it's used in the JS framework niche, but that's not web development, that's app UI development in a browser and seems to come mostly from web-foreign developers. If it's that or HTML with tailwind, then tailwind is always better.
  • lifthrasiir 6y ago
    CSS-in-JS originates from the needs for reusable and/or separated web components, so if your website can be factored like them it might be better. To be sure, I do hate "do it in JS" movements and I will gladly get rid of them if I can achieve the same without JS, but it is way better than keeping your HTML (templates included) and CSS (Sass included) in sync. Tailwind does nothing in comparison; it is just an abbreviated inline CSS with opinionated defaults.
  • Hitton 6y ago
    I quite agree, especially with the second paragraph. What I see as main "advantage" is that it stops developers from trying to be smart. With Tailwind first idea when creating a new component is using some combination of existing utility classes and it will be probably more or less ok and consistent with rest. Without Tailwind, developer will probably start create new classes, possibly duplicating or reinventing lot of existing stuff.
• jack_riminton 6y ago
  I only agree with their first point; it makes the html a mess But I think this could be solved with an editor extension that shortens or hides the 'class' unless you mouseover it
  • iKlsR 6y ago
    I asked the author of headwind about this one time, for now what I do is simply use @apply if it's getting a bit unwieldy even if I only use that once place.
• cageface 6y ago
  Ive been doing CSS in every flavor imaginable for twenty years now. Until Tailwind came along it was always my least favorite part of coding for the web. Tailwind eliminates all that accidental coupling that eventually turns every CSS codebase into a tar pit nobody dares to clean up. Don’t knock until you’ve given it a fair chance.
• laurencei 6y ago
  I'm a "full stack" developer. Largely a backend dev who does frontend as required, including on side projects. I switched to TailwindCSS a long time ago and I have zero regrets. Its so awesome I can switch to a project that is 2 years old, and make a quick layout UI change without having to look at old CSS files to find classes etc. I also can just find a tailwind class name and apply lots of cool stuff that I've normally found difficult to do via "pure" CSS files. But I also feel that this is likely to be a thing that half prefer A, and half prefer B, and there is nothing wrong with either. In this thread is likely to be a 50/50 split between both camps, with different "ideologies" on how the front end should be done. As the author of this article says - give it a go. If you like it, awesome. If you dont, switch back to another tool, there's not a definitive "right/wrong" answer to any of this.
  • stepbeek 6y ago
    I think you’re spot on - development is a big tent and it’s totally cool for this to be personal preference.
    • ricardobeat 6y ago
      I think there's more than personal preference at play here. The hidden benefit that the author missed is that Tailwind's (or any other atomic CSS approach) classes are immutable and all changes localized. This pays off hugely for large [enterprise] projects. In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else. With class-based styles, even when using theme variables, there is always the chance you end up breaking something at a distance by adding a property to an existing class, changing a shared value, renaming a selector or changing it's precedence. If you find yourself in this environment where dozens of people are making changes concurrently, and these issues are a daily occurrence, naturally you'll wonder how you ever worked with CSS any other way. styled-jsx and other approaches can get you similar benefits but extra care is necessary. I mostly avoid Tailwind due to the lock-in, complex setup and slow build, otherwise might have used it for quick prototypes more often.
      • 6y ago
• subsubsub 6y ago
  I'm too old and tired to try to be clever on the front end any more. TailwindCSS is the right answer for big projects and for small. Yes it can get bloated but i'm willing to take that trade off if it means I don't have to do any more css.
  • robin_reala 6y ago
    Huh, my opinion is that it’s potentially the right fit more middle-sized projects, but neither big nor small ones. For small projects, you’re wasting time with a massive abstraction layer when you could be writing a small set of easy styles in plain CSS. You don’t need the weight and complexity of a sizeable framework. And for big projects, it’s technical lock-in and additional maintenance overhead that absolutely doesn’t work if you’re trying to coordinate a microfrontend environment for example.
    • jefflombardjr 6y ago
      How is it lock in if you do something like extract components? https://tailwindcss.com/docs/extracting-components https://tailwindcss.com/docs/extracting-components Or define components? https://tailwindcss.com/docs/plugins#adding-components https://tailwindcss.com/docs/plugins#adding-components
    • papertokyo 6y ago
      In my experience it's exactly the opposite. For small projects you don't have to create any boilerplate styles, resets, and the like...you just start writing code. A lot of frontend frameworks that are popular these days have CLI options to set up Tailwind out of the box at the same time you bootstrap the rest of the files. For large projects, maintenance is easier because you don't have to relearn the CSS architecture each time you (or more importantly, someone else) comes back to work on something after a few months. If you're doing microfrontends, just import the same config file?
• leodriesch 6y ago
  I don't feel like it does vendor lock-in. It only really locks you into using utility CSS, but you can "eject" at any time by throwing out the framework and keeping your compiled file with utility classes.
  • monsieurbanana 6y ago
    And then... you'll keep two wildly different CSS styles for the same project? That doesn't seem reasonable. Vendor lock-in doesn't mean that you can't get out at all, just that it has significant cost. Maintaining both Tailwind and another CSS framework/philosophy/classes in the same project has a significant cost.
    • rjknight 6y ago
      Yes, but this is the same kind of cost as, say, switching from an OO to a functional design, and we don't normally refer to "choosing to use OO" as "vendor lock-in". This phrase is normally reserved for use when there is a vendor that one must pay in order to continue to use a service, not merely cases where there is some difficulty or annoyance involved in changing something.
• fhunt 6y ago
  Me neither, try Tachyons which is what Tailwind wants to be, minimalistic, atomic, great UX.
  • Hoasi 6y ago
    I love Tachyons (CSS version). It saved me hundreds of hours. To each their own: for instance, I used Sass but disliked it. It always seemed to add needless complexity to my projects.
• taphangum 6y ago
  "If you can suppress the urge to retch long enough to give it a chance, I really think you’ll wonder how you ever worked with CSS any other way.” - Adam Wathan The advantage of Tailwind [1] is very subtle over the short term (such as not having to constantly context switch between HTML & CSS files), but dramatically impactful over the long term. Both in terms of time-savings, as well as code quality and ability to work with others quickly. It really is something that you must earnestly try to gain an appreciation for. My initial reaction was the same as the authors when I first came across it. Actually using it on a real life project changed my mind. [1] - https://planflow.dev/blog/the-main-advantage-of-tailwindcss https://planflow.dev/blog/the-main-advantage-of-tailwindcss.
  • jack_riminton 6y ago
    Agree, context-switching is massively overlooked When I'm creating an element having it styled as-I-think, without having to switch to another file is a nice productivity boost Especially if you have some sort of real-time rendering on your local server
• Shacklz 6y ago
  When I started in a project that made use of tailwind, I initially exactly felt the points the author is making here: The HTML is a mess, dev-tools don't play as nice, why would anyone like this? Unlike the author though, I have grown to love it - not having to look at two files to understand what's going on (html/css) really felt like a big boon, especially for "trivial" UIs that just need a bit of flexbox, css-breakpoints and a margin here and there to get going. For more complex stuff, falling back on custom classes is still perfectly fine. Also, the "html becomes a mess" argument was only an initial issue. Once you get used to the tailwind-classes, most of it becomes fairly readable - the examples of the author are, in my opinion, just as unreadable in css, especially if you're not a design-oriented css-geek (like myself).
  • gpspake 6y ago
    The big "aha moment" with dev tools for me was realizing that instead of interacting mainly with the style editor, you transition to interacting primarily with the classname editor with tailwind. Then dev tools is your friend again.
  • bryanrasmussen 6y ago
    >not having to look at two files to understand what's going on (html/css) really felt like a big boon, If I am currently creating the html and the css I don't have to look at both to understand what's going on. I only have to look at both if I am coming into some html and css that was created a while ago. If I have to understand the html and css that was created a while ago and how it all relates I don't do it by looking at different files - I do it by opening up the browser and inspecting. I suppose you have a different way of doing it that I have difficulty envisioning.
• cageface 6y ago
  We often talk about the rule of three in software development. The idea is that you don’t start looking for abstractions until you have at least three instances where that abstraction will be useful. The problem with component based or semantic CSS is that it forces you to define abstractions for everything up front even if n=1. The beauty of Tailwind is that you can still define abstractions when they are needed and pay the price of using abstractions but you can also handle the many one offs every site has in a much cleaner and more direct way.
• brainless 6y ago
  I have been using Tailwind CSS for about a year now, both on my own product and 2 products from 2 different founders I work with from On Deck. Here is what I have to share: 1. Tailwind Makes Your Code Difficult to Read Tailwind CSS, in my opinion, is the easiest to read and understand what is actually happening. Yes I agree there is a learning curve to the shorthand notations but the naming is not bad at all as the author says. A couple days of light use and the system was in my head. Saying this as a full-stack engineer who deals with React + Python and devops. So I do not ONLY look at CSS shorthand notations all day. The example with the really long string of Tailwind CSS classes do not occur with me since such a complex string of classes is probably going into a component that needs customization from React component parameters. So I build the Tailwind CSS class names line by line with if-blocks or similar. 2. Tailwind Is Vendor Lock-in "Once you build an app with Tailwind, moving it to any other CSS framework or library in the future is going to be grueling." - the whole point of Tailwind CSS is not to move to a framework. Your JS components mixed with the CSS are exactly your own branded framework. I am not sure I understand the move argument. Even though all the products I work with are small, we have new frontend engineers helping out and it took them less that an hour to find the right Tailwind CSS class and making pixel-perfect components. This is close to CSS yet comfortable to see and existing project and contribute. 3. Tailwind Is Bloated Purged Tailwind CSS based stylesheets are ridiculously small. Try it out for yourself. (1) 4. Tailwind Is an Unnecessary Abstraction Again, like I mentioned, I was even nervous that new people will not like the abstraction that Tailwind CSS has. But once you see an existing, well setup project, its so easy to check documentation and contribute. The abstraction is super thin on top of CSS. "If it’s not already obvious, @apply completely violates Tailwind’s founding and guiding principles." - no it does not. Tailwind CSS exists to create your own style framework. It is that simple. Once you see patterns, you use @apply to codify them and reuse. That is so convenient. It is a feature in my opinion and a really important one as your project grows. I want to stop here, but I feel that these 4 points are not strong counter points to someone using Tailwind CSS for a year over a few projects now. (1) https://tailwindcss.com/docs/optimizing-for-production https://tailwindcss.com/docs/optimizing-for-production
• DrBazza 6y ago
  On the other hand, I quite like Tailwind because if I'm looking for a CSS option, it's more discoverable than raw CSS, "text-", "bg-" and so on. It's consistent. As for 'it makes your code harder to read', I simply write the classes in HTML, then when done, move them to my CSS file via @apply, and my HTML looks the same as it has always done.
• Aardwolf 6y ago
  How about just giving CSS a tag to vertically and/or horizontally center multiline text in a box, without needing constructions involving multiple elements. Preferably with a simple name like "center" or "middle", though unfortunately those two names are already taken up by things that do not actually put the thing in the center or middle. Original HTML could do it in table cells. What's taking CSS so long.
  • matthewmacleod 6y ago
    Bit of an old meme now, which mostly comes out of misunderstanding the difficulty of actually designing a layout system and the tradeoffs involved. Anyway it's easy and has been for ages: display: table-cell; vertical-align: middle;
    • jfengel 6y ago
      It sure doesn't help that there are multiple "easy" ways to do it. A sibling content mentions flexbox. There's another with CSS transforms. CSS accumulates techniques, each one intended to compensate for defects with the other -- and they interact in obscure ways. Googling will always turn up recommendations for each. You end up with Perl-like "There Is More Than One Way To Do It" -- and you have to know all of them if you want to actually do anything.
    • nsonha 6y ago
      Is `display: table` a css feature made for centering things? No? Not a fan of tailwind, but whoever thinks that is simple misunderstood the meaning of the word, it's not about the number of characters you have to type.
  • frereubu 6y ago
    You can do this already with: <div class="container">This is the text</div> .container { align-items: center display: flex; justify-content: height: 200px; }
    • runawaybottle 6y ago
• AgentME 6y ago
  I never got the point of Tailwind: having an element with utility classnames on it that each add one CSS rule, like class="flex flex-wrap" doesn't seem any better than just having the equivalent inline styles on it. Sure, the Tailwind utility classes are shorter, but the abstraction doesn't simplify anything. It's just some set of aliases you'll need to have memorized, and it's just moving the one-off combining of styles from the inline style property to the class property. It seems like something built to superficially follow the common wisdom of avoiding overusing inline styles. I want to echo the author's recommendation of styled-jsx. I've been using it with React for a few years now and love it. Like Tailwind, the styling is conveniently co-located with your elements, but it's just regular CSS properties with their full power instead of a set of aliases crammed into the class property. It also encapsulates the styles to the component's own elements by default, which is very good at encouraging making encapsulated components. The codebase I'm working on used to have a mess of CSS files, and CSS files for various screens often messed with the internal styling of common components used within the screen which would regularly cause us surprises whenever we updated those common components without realizing how they were abused across the application. Now that we're using styled-jsx, proper component-level encapsulation is enforced by default, and it really helps guide us toward making the components themselves be responsible for their own styling needs, which keeps things much more understandable and more local with less "spooky action at a distance" (external styles modifying the component's internals).
  • splatzone 6y ago
    In my experience, the real convenience of Tailwind over inline CSS is using all the variant classes (https://tailwindcss.com/docs/configuring-variants https://tailwindcss.com/docs/configuring-variants) like hover:font-bold, md:w-full, group-hover:text-gray-500 etc to compose your styles. It's not possible to use pseudo classes like :hover in inline CSS. I've also found the tailwind.config.js very useful - you can load it up with all your custom colours and fonts. It's much easier to refer to text-primary (for your primary brand colour) than remembering a hex code and pasting it all over your markup :)
    • robin_reala 6y ago
• wizzzzzy 6y ago
  I tried the 'functional CSS' approach a few years ago and whilst at first I found it pleasurable to use, I ultimately grew to hate it. The biggest pain-points for me were exposed when returning to older code -- parsing the intertertwined mix of utiltiy class names and html added a level of overhead that I didn't have before. Additionally, later on in projects I'd encouter more edge cases where I need to provide bespoke styling for certain elements. As soon as you need to mix functional with traditional CSS I found the overhead to increase further.
  • ehnto 6y ago
    That is my biggest pet peeve, there are no uniquely identifying class names anymore so in a big enough project it can end up really hard to find what is generating the HTML you need to change. It's part of an overall code quality attribute I refer to as "discoverability" which is tied very closely to clean organisation and maintainability. Can't maintain something quickly if it takes 10 minutes to reverse engineer the code and find it.
    • Kinrany 6y ago
      This is a problem that should be solved by the framework. With React you can look at the virtual tree instead of html.
      • blowski 6y ago
        Exactly. Every time you find yourself doing copy paste for a whole range of elements, introduce a component with its own collection of style classes.
        • ehnto 6y ago
          Yes, that would work well if you are using a frontend JS framework.
          • blowski 6y ago
• technicolorwhat 6y ago
  A great an opinion, which I once held. But when I looked deeply I only saw benefits. I see tailwind as a damn cheat (a good thing), a hyper productivity tool throwing away all the what we learned as 'correct', and just get things done with escape hatches to fallback. - Rapid prototyping with tailwiwnd - Making component frameworks like bootstap? Just use tailwind sass with helpers. You can use a sass approach with including the helpers so you dont polute your DOM. - it is easy to remember and guess which increases velocity. p-1/2 etc.. m-1 p-2 etc etc. Conventions make sense! - Bloat can be solved with purge - Refactoring easy easy if you abstract it away in sass so you can make global style changes. - Protyping is easy, and you can then move it towards a component framework once you've done wiggling around and changing your stuff. - I find css in components hard and painful personally also makes doing broad style refactors a bit more difficult. - I also use css for email and other simple landing pages that dont require html components or react/webcomponents or whatever. I find this a great addition to my life. Its a darn sharp knife, up to you what you do with it.
  • SwiftyBug 6y ago
    Bloat can be _partially_ solved with purge. You still end up with a somewhat larger HTML file because of all the extra class names you have to write. To me Tailwind is worth the extra bytes, which, after all, probably doesn't represent that much of an increase in file size.
    • technicolorwhat 6y ago
      For sure but and even if you find that too much you can just use the helpers in SASS and you can just write your plain old classes and then tailwind is just another sass framework.
• config_yml 6y ago
  It's funny how the author talks about vendor lock-in (which is kind of a non-issue with tailwind, since you can eject anytime) and then suggests styled-jsx as the better solution.
  • technicolorwhat 6y ago
    Agreed. Als TJ made a nice point about this. https://twitter.com/tjholowaychuk/status/1148918177302269953 https://twitter.com/tjholowaychuk/status/1148918177302269953
• natrys 6y ago
  I think it's a fairly compelling article. There is a lot of hand-waving around tailwind; I have never seen so many people collectively play the "I can't articulate why it's good, but after using it for a while I can never go back!!" card about a technology before. But I think author hit the nail on the head about the benefit of tailwind: rapid prototyping, but that's about it. I will use tailwind for my next small project. But I can't deny that it is indeed technical debt, albeit one that I have grown to indulge.
  • blowski 6y ago
    My team maintains around 200 websites on behalf of a design agency. Performance isn't important, and these clients aren't paying much. Let's say a client wants to add a custom page, with some custom design. Where do I add that? Into the global CSS, where now it needs to be maintained? Do I use a body#custom_page selector before everything? I've got elements that I now want to override only on this page. The easiest way is using inline CSS, except I can't inline responsive and pseudo-states. Updating the 5000 line CSS file with a bunch of classes under a body#custom_page selector is hard to maintain. Tailwind solves this problem, by effectively allowing me to use inline styles even for responsive and pseudo-states, and simple variables. CSS is effectively global state. You make a change on one bit of CSS, it can affect any part of the website, so you have to know about the whole website before making changes. And that's impossible when you maintain 100s of websites, especially when budgets are small. I can see why Tailwind isn't helpful in a large company maintaining its own large website. But for small teams managing lots of different websites, it's fantastic. It allows you to localise and isolate the effects of CSS.
    • jfengel 6y ago
      I maintain something much smaller and I'm trying to understand the various use cases, so please bear with me. What's the problem with the #custom_page selector? If inline styles have oddities, why not keep it in separate css files, one per custom page? That would seem to precisely match the cascading style CSS is supposed to handle in the first place. That's a lot of files if you've got 200 related-but-slightly-customized pages, but it tracks the organization of the project as a whole, no?
• hactually 6y ago
  So he hates "vendor lock-in" but recommends styled components in JSX? How on earth can someone end up so cognitively dissociated?
• jefflombardjr 6y ago
  At the end of the day, sure if you don't like it - don't use it. But I don't understand the hate for it, because I have a very different experience with it. --- > 1. Tailwind Makes Your Code Difficult to Read This one is interesting to me. I think devs should take responsibility for writing easy to read code. A framework is a framework. I agree shotgunning classes all over markup is messy, but Tailwind doesn't do that - you do. I would encourage the author to understand the concepts of extracting[0] and defining components[1] within Tailwind. That can make things very easy to read by the author's logic. > 2. Tailwind Is Vendor Lock-in Not necessarily. Especially if components are defined, if anything it makes it easier to change. Because you have a css class abstracted at the same level of your markup. In the world of various competing component frameworks, I would argue the opposite is true. You can just as easily apply tailwind component classes to Vue as to React as to Svelte etc. > 3. Tailwind Is Bloated As others have mentioned purge css[2] > 4. Tailwind Is an Unnecessary Abstraction "Because instead of repeating styles in your CSS, you’re now repeating them in your HTML", "you’re still writing the exact same amount of CSS, disguised as class names" This just isn't true if you use it correctly again see extracting and defining components. > 5. Semantics Is Important. Tailwind Forgoes It. Author recommends BEM and then in the end says "You don’t really need BEM, either". I agree with component scoped css, BEM is less important. Tailwind > 6. Tailwind and Dev Tools Don’t Play Nicely What? Anyone who experiences this should revisit CSS order of precedence. It behaves exactly as expected. I've never had a problem with chrome/firefox dev tools. > 7. Tailwind Is Still Missing Some Key Features So use css? Using tailwind isn't a binary option. You can use both tailwind and css. It's a tool, use it where it makes sense. --- [0]: https://tailwindcss.com/docs/extracting-components https://tailwindcss.com/docs/extracting-components [1]: https://tailwindcss.com/docs/plugins#adding-components https://tailwindcss.com/docs/plugins#adding-components [2]: https://tailwindcss.com/docs/optimizing-for-production https://tailwindcss.com/docs/optimizing-for-production [3]: https://jigsaw.w3.org/css-validator/validator?uri=https%3A%2F%2Fwww.aleksandrhovhannisyan.com%2Fblog%2Fwhy-i-dont-like-tailwind-css%2F%231-tailwind-makes-your-code-difficult-to-read&profile=css3svg&usermedium=all&warning=1&vextwarning=&lang=en https://jigsaw.w3.org/css-validator/validator?uri=https%3A%2...
  • nsonha 6y ago
    Tailwind Is Still Missing Some Key Features > So use css? Using tailwind isn't a binary option then what, you now have 2 set of styles in 2 different places, written in 2 completely different ways, does that sound fun to maintain? I guess still you have to structure your css in some way too? <div class=" w-16 h-16 md:w-32 md:h-32 lg:w-48 lg:h-48 "></div> do you just casually throw these magic numbers everywhere or there is a way to use css variables with tailwind?
• DigitalSea 6y ago
  I wanted to like Tailwind and, I tried to tolerate it for a few months. To me, it always felt like a less opinionated Bootstrap, but arguably a lot more to learn. The same approach of having to remember class names and syntax is no different than Bootstrap. The differentiator of course, is Tailwind has better tooling support and feels less static, but it's still quite a convoluted beast to wrap your head around. There does come a time when Tailwind starts to click, you've memorised some of the class names and you get a feel for it. But, I still found myself consulting the documentation to do things "the right way" ultimately spending hours reading documentation, when I could have written plain old CSS. The maintainability aspect in the long-run is the selling point of a solution like Tailwind. CSS without some semblance of order can wreak havoc on a codebase. These days I am using plain old CSS on a component level inside of Aurelia 2. My components are Web Components utilising Shadow DOM features which scope my styles to the component, but also using Constructable Stylesheets to reuse styles throughout my app. In combination with CSS Variables and Shadow Parts, it's an incredibly powerful workflow that takes a lot of the pain of CSS out of development, it's closer to the metal and feels way nicer.
  • burlesona 6y ago
    Hello! I've been trying to adopt Web Components and have had limited success specifically because (since these are internal components) I want to use my application styles, but can't share them across the shadow dom. Do you have a good writeup or example on the way you're working? I'm googling Constructable Stylesheets, but would love any other pointers, because what you're doing sounds like exactly what I've been wanting to do. Edit: I see Constructable Stylesheets are Chrome-only. Unfortunately that's a deal-breaker for me :/
    • scorxn 6y ago
      Not the parent commenter, but I have an app whose web components inherit from a class with this constructor: constructor(html) { super(); const link = document.createElement("link"); link.rel = "stylesheet"; link.href = "/theme.css"; const template = document.createElement("template"); template.innerHTML = html; this.attachShadow({ mode: "open" }).append(link, template.content); } Global things like vars, default typography, and input style resets go in theme.css.
• tekkk 6y ago
  Well I agree on the premise to some extent, but I don't feel like all the examples and points are as high impact as others. For example, I don't think that styled-jsx is really the solution to the problem - writing the stylesheets inside JSX? Sounds.. strange. From what I can see, Tailwind doesn't offer a solution to the div-soup HTML at times becomes. When I look at five or more nested divs I kinda forget what I'm even looking at. Having semantic names is crucial in maintaining a layer of abstraction that helps to map the HTML inside your brain as entities with specific purposes. I myself use JSX and name my elements as Container, ButtonGroup or TooltipWrapper for example. The other problem I see are the conditional class names - how does Tailwind deal with them? Do you write if-else class names? Doesn't seem very clean. I myself use styled components where I add properties, such as visible={isVisible}, and resolve them inside the stylesheet where the value matters. The benefits of Tailwind, however, seem also evident to me as abstracting away CSS into much smaller number of utility CSS classes does appear to be a very quick way to make decent layouts. It's just that having done plenty of CSS/SCSS I don't find it too time-consuming to write the CSS myself. And also because of the previous points.
• nazbuck 6y ago
  Who cares. Please tell us about more things you don't like
• indymike 6y ago
  This article convinced me to give Tailwind a try.
  • monkey_monkey 6y ago
    Good!! For me (and many others) it's been a game-changer, but I didn't truly appreciate it until I actually tried it. There's a lot of help available, and I highly recommend Adam Wathan's Youtube channel (https://www.youtube.com/channel/UCy1H38XrN7hi7wHSClfXPqQ/videos https://www.youtube.com/channel/UCy1H38XrN7hi7wHSClfXPqQ/vid...) where he has several livestreams of actually building pages using Tailwind. Watching a couple of these went a long way to convincing me that Tailwind was worth trying. (Adam is the creator of Tailwind).
• matthewmacleod 6y ago
  Like many discussions, Tailwind is a topic on which some of us are guilty of not stepping back and realising that others have different views mostly due to their background and the tools that they've used, and that those views are totally valid. For example, I also don't like Tailwind (or, for that matter, Tachyons or any of the similar tools). I find it absolutely infuriating to work on a site that uses it, it is a massive drag on my productivity, and offers quite literally nothing that I want. But here's the thing – I was a front-end specialist for years. I know how to write CSS and Sass, how to build UIs from them, and I have an established set of patterns and helpers for doing so. I used to be a graphic designer too, so doing things like building an application-specific design system is my bread-and-butter. For me, Tailwind is a massive distracting abstraction on top of a thing that I'm already completely comfortable using. Other people aren't necessarily in the same position. It takes a lot of time and work to start thinking in terms of the way that styling works on the web, and CSS is pretty different to many of the languages and tools that developers are used to. If you're a back-end developer who is primarily interesting in implementing a straightforward and functional UI for something, then investing lots of time in the quite different skill set of front-end styling probably doesn't offer a good return. So there are sets of tools out there which make it easy to write simple, organised, and maintainable sets of styles, without having to get right into the weeds. Of course as always YYMV and you might be a CSS expert who loves the consistency of this kind of framework. But I'd definitely back up the idea I've seen some other people mention – there's no obvious right or wrong, or objectively correct answer.
  • paavohtl 6y ago
    I don't understand how Tailwind would make writing CSS easier if you're not an expert. The complexity of CSS is in learning how the layout algorithm works, and how to implement common UI patterns. You're still writing exactly the same CSS rules in Tailwind, just with a different syntax. The complexity remains exactly the same.
    • deergomoo 6y ago
      I'd argue a lot of the complexity in CSS comes from how people typically write it: lumping a bunch of properties into "semantic" classes, then trying to juggle how those all cascade and interact when nested within other such classes. I think we've all lost the will to live trying to "undo" a style cascaded from an element's great-great-grandparent. Of course, you don't have to do that—you could write your CSS classes as ultra-low specificity classes that each only target one property...but I think you'll find that's what Tailwind is :)
• kuon 6y ago
  I understand the author points, and the article is well written. But, I moved to tailwind for different projects and now I use it nearly exclusively. I don't want to argue whenever it is good or bad, but it solves my problems. When you are deep down some html component, being able to style it without having to find the css file is very pleasant. The code is also more maintainable as there is no "domino effect". You change what you want to change, and you are done. As for vendor lock in, tailwind is MIT licensed, I don't see the issue here. Of course if you use X, you are going to depend on X. And if they release a breaking update, just pin the old version. I'm happy with improvement in tailwind 2, but to me the framework is complete, I don't mind it being frozen. Concerning the long lines, I agree, but you can just put newlines between class names. Class name is a cdata list, newlines are ignored: https://www.w3.org/TR/html401/types.html#type-cdata https://www.w3.org/TR/html401/types.html#type-cdata What I do is that I group classes by function, like color on one line, margin/padding on another...
  • ricardobeat 6y ago
    > deep down some html component, being able to style it without having to find the css file is very pleasant Is this a template based project with global CSS? That is not an issue at all if you're using an actual component system. > tailwind is MIT licensed I don't think the lock-in has anything to do with the license, but how hard it is to migrate away from it. You're locked to its build tooling and converting the styles back to anything else is a rewrite-everything-from-scratch proposition. Whereas migrating from say, styled-jsx to styled-components is a lot easier.
    • kuon 6y ago
      > Is this a template based project with global CSS? That is not an issue at all if you're using an actual component system. Yes, I use phoenix live views, which is just HTML templates with global CSS. I know there are tons of "real" CSS component systems, but live views has been really a life saver to me, and I don't need offline apps. Concerning the lock in, I think it makes sense only if the vendor will stop supporting it. I mean, if it works, doesn't change it, even if it means forking the repo and having it sit somewhere. The security and "bugs" are handled by the browser, the CSS framework can just be stuck in times, it shouldn't be an issue. Of course if CSS specs changes drastically, it might be an issue, but it would be for any other CSS solution. Also, we are talking about class names, this is fairly standard, tailwind didn't invent "utility-first" CSS, maybe not a drop in replacement, but I don't see that as a real lock in.
• jspash 6y ago
  I seem to have noticed something about these Tailwind love/hate discussions. And it all boils down to this: Old-school devs seem to like TW for the benefits it gives over other CSS paradigms (Smacss, BEM etc.) It speeds up development over those. Testing and editing in the inspector is simple and easy to put back into the source. New-style devs (SPA ALL TEH THINGS!!) do NOT like TW. They are already dealing with 3 concerns in the same file. Adding another layer of abstraction is unwelcome. Changes seem to multiply and search/replace makes seemingly simple adjustments a royal pain. Then there are the Bootstrap acolytes who won't give up their btn-default no matter what comes along. All I can say is to each their own. But Bootstrap guys(and girls)...it's time to move on. :P
• hmwhy 6y ago
  For me Tailwind CSS solves a cognitive problem: I find that switching between CSS and HTML files reduces my development velocity substantially (maybe I'm getting old). I was always a bit wary of CSS frameworks, and I preferred writing "actual" CSS and used mostly CSS/SCSS before I discovered Tailwind CSS. Interestingly, even before I discovered Tailwind CSS, I was already getting into the habit of using utility classes like "flex", "flex-wrap", because it made a lot more sense *to me* to see those in the HTML. I personally find the examples given in the blog post contrived. Take the "hard to read part", for example, this is how I normally format my HTML using Tailwind CSS: <div class=" w-16 h-16 md:w-32 md:h-32 lg:w-48 lg:h-48 "></div> Even if you are using styled-jsx or any framework that gives you the ability to write "regular" CSS, it still wouldn't beat the example above in terms of readability. As such, the following paragraph just doesn't make sense: > I’m comfortable reading other people’s code, and making sense of their logic and relating their markup to their CSS. Assuming that we are not talking about component-scoped styling here (otherwise the point made would be moot), with Tailwind CSS you can instantly relate CSS to markup without switching between files and hunting down all relevant class names in the example given above; this is arguably also easier when you are not working with the source and just debugging on the front end. > But if I have to look at ~1000 LOC changes in a PR, and most of that is coming from long strings of class names, I’m not going to be happy. It’s also going to be more difficult for me to make suggestions that could eliminate redundant CSS or simplify your markup. I have never dealt with ~1000 line of changes in a single PR, but that sounds pretty broken and there is an abstraction problem that is much worse happening elsewhere and irrelevant to the argument. The last line also sounds like a throwaway without any solid example to prove it: even if switching between markup and CSS files is not taken into account, I can't imagine hunting down redundant CSS would take longer with Tailwind CSS. If the redundant classes are on the same element you can see it instantly; if they are on different elements, it would still take similar amount of work to debug and find them? Assuming that there are no redundant classes, then there isn't much to be simplified because the whole point of Tailwind is to have (managed) complexity in the markup instead of having it in the CSS. I personally would rather have it in the markup, but that's just me and I can't say if it's better or worse. > With Tailwind, you’re forced to interpret semantics on the fly. I find it easy to just ignore class names and focus on content when I need to with the way I structure my code. Maybe a lot of people don't realise that it's okay to, or feel comfortable with, splitting class names and attributes onto multiple lines. Just one more point on being bloated, note that on Tailwind CSS's website they say: > 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. For reference, the blog's CSS is 12.12 KB gzipped. Most of the rest of the post follows a similar pattern that's just out to trash Tailwind CSS. As others have already pointed out, this may end up being a 50/50 thread of personal opinions after all, but it seems that we keep getting more and more of these sensationalised hate posts that are just based on personal preferences...
• colourgarden 6y ago
  One thing I rarely see mentioned in discussions about Tailwind is inheritance - one of CSS's biggest strengths but also biggest weaknesses. With Tailwind, you never even have to think about inheritance ever again! No class can ever be accidentally overridden by another added elsewhere. This is a huge win for stability when working in bigger teams. Sure, scoped CSS also handles this but most developers are not building JavaScript SPAs. They're building monolith applications or WordPress/Magento/Craft/whatever themes where a handful of stylesheets are included via a <link> tag.
• midrus 6y ago
  And so, his recommendation is to use styled-jsx which is pretty much abandoned (despite of what they say) [1] and not even themselves are using it [2] I do think css-in-js solutions are good, but also they're a lot more work, and probably better suited for large teams with a shared design system, etc, etc. Personally, I think Tailwind is great. But I understand some people don't like it and cannot appreciate it because it might not look good seeing many classes and "but this is just inline styles". Ok, not for you. It is still great for some other people. [1] https://github.com/vercel/styled-jsx/issues/688 https://github.com/vercel/styled-jsx/issues/688 [2] https://github.com/vercel/virtual-event-starter-kit/tree/main/styles https://github.com/vercel/virtual-event-starter-kit/tree/mai...
• jfleck 6y ago
  The only thing I really didn't like about tailwind was the danger of changing tailwind.config and the long className lists. I "solved" both of those issues with a simple macro and PostCSS plugin: https://github.com/fleck/class-types.macro#why-use-this-library https://github.com/fleck/class-types.macro#why-use-this-libr...
• frob 6y ago
  Tailwind brings with it the same issues that css-in-js does: the inability to just reload css curing the development cycle. When working with css (or a language that complies to css), any changes to the style are pushed to the browser without a page refresh. With tailwind and css-in-js, changes to style require changes to js/html and therefore require an entire page reload which both slows down my feedback loop and breaks any state I had established in my test app.
  • dawnerd 6y ago
    If you use Next.js it's not really an issue but you're right, that is pretty annoying.
  • fokinsean 6y ago
    > With tailwind and css-in-js, changes to style require changes to js/html and therefore require an entire page reload ah!! I was wondering why HMR wasn't working like I remembered the first time I used React. I think the first time I picked up React I used plain CSS, and the CSS would change on the page without reloading. Now I'm using tailwind and material-ui and thought HMR was just busted. I like tailwind but it doesn't play well with material-ui. Material components always take precedence which is super annoying. I might just end up canning tailwind.
  • werm82 6y ago
    Not sure what your setup is, but I'm using tailwind with create-react-app and craco[1], and the changes show up without needing to reload. [1] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco
    • frob 6y ago
      You can update the tailwind css files as much as you like, but as far as I know, adding or removing class names will trigger a reload.
  • jms55 6y ago
    I used Tailwind in my Phoenix LiveView project, so I don't need to reload.
• dawnerd 6y ago
  Valid points but it's still ultimately down to personal preference and I happen to really like Tailwind. Some people get into this mindset that a project simply shouldn't exist because they, or someone else, writes about why it's bad. Also filesize isn't as big of an issue that the author makes it out to be. https://tailwindcss.com/docs/optimizing-for-production https://tailwindcss.com/docs/optimizing-for-production
  • nobleach 6y ago
    I've seen that happen, and I sincerely HOPE that folks heed this guy's advice, read the words written by Tailwind's creator, and try and understand the problem it's trying to solve. While I can agree that folks do tend to read negative things on the internet and then turn around and say, "see, I heard it was bad, don't use it", I also like the freedom of this guy to break out of the cargo-culting and say, "nope... this is why I don't like it". It gives me some things to pay attention to when I'm auditioning new libraries/frameworks/etc.
  • hmsimha 6y ago
    I haven't actually started using Tailwind yet, but I really disagreed with the first point: > 1. Tailwind Makes Your Code Difficult to Read ... > First, like Bootstrap, it’s semantically obscure because all of its class names are awkward abbreviations ... > I would rather look at some CSS that has padding: 0.25rem or margin: 0.5rem instead of trying to mentally map Tailwind’s p-1 or m-2 to their CSS equivalents. Please the latter is so much easier for me to read, and can (hopefully) be remapped from rem to px in one place, or to use increments of .5 instead of .25, which avoids manually changing potentially hundreds of selectors. Furthermore, using conventions for these kinds of class names makes the knowledge transferrable to another project without having to relearn/rewrite all of these. > Another reason why Tailwind is so hard to read is because it requires you to pan your eyes horizontally rather than vertically. ... When you string a bunch of class names together, you get markup that looks like this <div class="w-16 h-16 rounded text-white bg-black py-1 px-2 m-1 text-sm md:w-32 md:h-32 md:rounded-md md:text-base lg:w-48 lg:h-48 lg:rounded-lg lg:text-lg" > OK, I get that this could be an issue if you're writing markup by hand, but for a large project this seems like a terrible idea. If you're over in JSX-land (or any templating, really), you'd have an array/set for classNames somewhere, and can just join(' ') it. If for some reason you need to have 50 classes, sure, line-separate them. In many (most?) situations you'd want to construct that array/set programmatically anyway, and encapsulate tightly-coupled display logic in smaller building blocks
• swyx 6y ago
  for balance - i wrote Why Tailwind CSS a while ago: https://www.swyx.io/why-tailwind/ https://www.swyx.io/why-tailwind/ Here are my responses to OP's arguments: 1. Tailwind Makes Your Code Difficult to Read true, there is a learning curve. But this is over relatively quickly once you learn that "w" stands for "width" and "h" is for "height", and the screen size prefixes map as you would expect from default to medium to large. as for scanning left to right... the enter key is right there. my VSCode autoformats the classes to break lines just fine. its probably the tailwind plugin doing that. 2. Tailwind Is Vendor Lock-in first of all, "vendor lock-in is bad" is a poor kneejerk reaction. we all buy in to vendors at some point. eg with frontend frameworks. and as far as vendor lockin goes, Tailwind is extremely light - if you want to stop using it, freeze the generated output, and then continue writing css in whatever new way you choose. this is far LESS vendor lockin than alternatives like styled components and css modules, which force you to make specific js and build tool choices. and all of these are open source so this again is an order of magnitude less lockin than anything proprietary, which is where this argument really starts being at all useful. 3. Tailwind Is Bloated how is declaring things on the docs indicative that "its creators have tried their very best to hide this fact from you."? they've just decided on sensible defaults. the bloat only impacts development and builds. This contrasts to the problem that utility css solves, which is bloat inside of hard-to-maintain append-only CSS with lots of duplicates, which actually affects users. 4. Tailwind Is an Unnecessary Abstraction components. use components to repeat stuff. this rant on @apply takes things way overreacts, calm down. 5. Semantics Is Important. Tailwind Forgoes It. counterpoint: naming things is hard. Tailwind names css utilities for you so that you don't have to come up with custom names for every component. 6. Tailwind and Dev Tools Don’t Play Nicely au contraire, tailwind plays VERY well with devtools. https://twitter.com/swyx/status/1265745431448838144?lang=bg https://twitter.com/swyx/status/1265745431448838144?lang=bg (since this video I even learned that you can type in the classname box in chrome devtools and it autocompletes nicely for you 7. Tailwind Is Still Missing Some Key Features then write regular css :)
  • miklosme 6y ago
    > my VSCode autoformats the classes to break lines just fine. My only pain point with Tailwind was the order of classes. It helps with readability if the classes are always in the same order. I just discovered that eslint-plugin-tailwind [0] is solving this exactly. Configuring VSCode to run code formatter and perform ESLint fixes [1] is just an incredible DX. [0] https://github.com/Idered/eslint-plugin-tailwind https://github.com/Idered/eslint-plugin-tailwind [1] settings.json: "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.eslint": true }
• choiway 6y ago
  The problem that I have with Tailwind is that it's not that different than using inlined styles but adds a lot of bloat without a path to clean abstractions.
  • vehemenz 6y ago
    It's similar to inline styles in one way but different in about five or six ways. Putting that to the side, what do you mean by clean abstractions? With Tailwind, all of your abstractions are explicit; the styles are right there on your component, with a more or less 1:1 correspondence to CSS properties. Everything does what it says it does. In traditional CSS methodologies, the abstractions are implicit but hidden. The relationships between the stylesheet and markup are still there, but they cannot be understood without knowing both structures intimately. Which of these is cleaner, and for what purpose? At the end of the day, code is not there to be looked at, it's meant to be deployed and maintained.
  • aidos 6y ago
    The limitation with inline styles is that the moment you need a single variation (hover, responsive, dark mode) you’re forced to move the styles somewhere else. Tailwind solves that, and a bunch of other stuff.
  • kall 6y ago
    The path to clean abstractions is your component framework.
• nfRfqX5n 6y ago
  this is becoming a monthly topic at this point
• ampdepolymerase 6y ago
  > But I can’t imagine that it’s possible to create a tool that does the reverse: converting Tailwind to semantic HTML and CSS. The only thing you could realistically convert Tailwind to is some other utility framework (e.g., Bootstrap) that locks you in with its own syntax and class names. I don't understand what is impossible about this. A standard tree walker and a GUI tool to define the individual components will suffice. Or to make things simpler, have a command line tool that takes in the CSS selector/XPath of the desired tag/component and generate the relevant CSS. There are already browser extensions that can do this. Also, nothing is stopping you from writing semantic HTML. Vanilla Tailwind is an (almost) one-to-one bijective mapping to CSS. It does not define your HTML unless you are using prebuilt components.
  • folkhack 6y ago
    > I don't understand what is impossible about this. Agree, and as someone who's done these conversions both ways I wanted to just say that you don't have to use complex tools to do what you're describing really. Those things are definitely in my toolbox, but simply just going by-hand and duplicating applicable styles from one site to the other with Chrome/Firefox devtools is a breeze. I say this as a developer who embraces/studies CSS
  • SahAssar 6y ago
    Converting non-semantic HTML names/classes to semantic HTML names/classes would require knowing the semantics which is really, really, really, hard. You can probably turn it into "big red button" easily but knowing that means "cancel-account" is hard.
    • ampdepolymerase 6y ago
      But the semantic HTML part is absolutely not related to Tailwind. Aside from the component library, Tailwind is a CSS framework that operates (mostly) on the class property of each HTML tag. The semanticness of HTML is defined by the tag itself and additional properties like ARIA, data-*, and various other identifiers like those from the RDF schema standards. It is an issue completely orthogonal to atomic CSS.
• patatino 6y ago
  My biggest problem is components, I just need more than a utility class framework for my side project, I do not have the time to implement all the components myself.
  • deleted 6y ago
    [deleted]
  • mgkimsal 6y ago
    Came here to say something similar. I often use bootstrap-vue (and used vuetify on a recent project). The accessibility, documentation, testing, and consistency these projects bring to my vue projects is big. BV uses bootstrap. I can make modifications as/when needed, but I have a whole library of these components that are documented and are styled using bootstrap. Having to rebuild these sorts of things just so I can use tailwind is... hard to justify. I was able to semi-combine both in a recent project, but it seems a little fragile. Is everyone else just building all their components by hand all the time?
    • darkteflon 6y ago
      I’m in this boat and would also love to hear what people are doing. I checked out the Tailwind companion component library, Headless UI (https://headlessui.dev/ https://headlessui.dev/) but it seems like very early days indeed.
• butt_hugger 6y ago
  It's really sad to see novice developers rediscover and revisit arguments from decades ago, but that's really the curse of software development, isn't it? Why does Tailwind CSS even have some kind of brand name? It's just bad CSS. It doesn't need a name.
  • vehemenz 6y ago
    The CSS specification says nothing about how to map styles to classes. So when you say "bad CSS", maybe you mean bad methodology? Bad for what? Bad for whom? You probably weren't alive yet, but the CSS methodologies that originated from the CSS Zen Garden made sense in an era when XML was supposed to take over the world. But it didn't, and there's no sense hanging on to those promises. ps. Media queries were not a thing twenty years ago.
    • butt_hugger 6y ago
      The reason XML didn't take over the world, and we're left with this mess of garbage for a front end, is because of bad developers like you. Mistakes in the past are no reason to continue making mistakes in the future. From your example, the obvious solution would be to write better markup instead of writing worse styles.
    • graydsl 6y ago
      Don't feed the troll
• mattwad 6y ago
  I completely agree with the maker's point that class names are the bane of CSS design. However, styled components have been amazing in this regard. I've tried a lot of solutions over the past 8 years and this is my favorite by far. No extra crap, but you still get reusability and the syntax is like plain CSS. I tried JSS but I can't get over defining styles as JS objects, not to mention made Typescript slow to a crawl. React example: ``` import styled from 'styled-components'; const Button = styled.button` padding: 4px; font-weight: bold; `; const PrimaryButton = styled(button)` background: ${primaryColor}; color: white; `; ```
  • mushishi 6y ago
    Agreed, I also had a pleasant experience with Styled components, a small boon is that Jetbrains has a plugin for Intellij IDEA.
• orthecreedence 6y ago
  I just started using Tailwind for a small project and love it! I thought I'd respond to the author's points: > Tailwind Makes Your Code Difficult to Read I think this is a preference, not a fact. I tend to write 2-dimensional CSS (I know the standard convention is 1D) so seeing a bunch of classes one after the other on the same line doesn't bother me. Regarding the abbreviations being difficult to parse, I don't find it so. And, do you want short class definitions or do you want long and descriptive class names? > Tailwind Is Vendor Lock-in I'm not convinced. Every framework is lock-in. Otherwise there'd be no point. > Tailwind Is Bloated Possibly, but it seems to trim itself down when compiled to production quite nicely. Paired with minification/gzip, doesn't seem like such a big deal. > Tailwind Is an Unnecessary Abstraction I like the promises it gives. "Here are some predetermined boxes your design can fit into, if you need to change them, do it via the config." In other words, you're constraining yourself. I think this is important. Even on teams with designers, the design can evolve over time and you'll have one section of an app looking different from another. Tailwind enforces a set of good practices. Maybe I like this because I'm not a great designer at all, but it seems to me this kind of constraint could have helped many projects I've worked on in the past (ones that had professional designers). Secondly, regarding "What exactly is the difference between using @apply and just using the CSS rules that correspond to your utility classes?" Well, because your utility classes are still subject to the constrains I mention above. The documentation specifically only recommends doing this for places where something is too small to be its own component, but too common to repeat the same class names over and over. Sure, you can misuse it, but I found the documentation obvious how the best practices here. "Because instead of repeating styles in your CSS, you’re now repeating them in your HTML, through class names." I think Tailwind specifically makes sense in the context of components. If you're repeating the same classes over and over again, you're doing something wrong. > Semantics Is Important. Tailwind Forgoes It. I can see both sides to this. The one comment I'll make is that in the cases where I've vehemently stuck to semantics, it has been wonderful to build but horrible to change. Semantics makes a tone of sense, until things start shifting around, and then you've got half of your classes referencing some object that's no longer there, or a thing that used to live here, but now lives there, and only some of the styles moved and some were copied etc etc. When I first saw Tailwind, I thought "wow, this is just inline styles++, how stupid." Now I kind of see the magic behind it. > Tailwind and Dev Tools Don’t Play Nicely This might be true, I haven't really done much devtools CSS debugging with TW yet. > Tailwind Is Still Missing Some Key Features It also defines "dark" but I haven't seen anything about custom themes in general. What if I have more than just a normal mode and dark mode? I'm curious how one would build themes on top of TW. > With frameworks like React and, more recently, Svelte, it’s never been easier to write CSS without leaving your markup, and without resorting to inline styles. You don’t really need BEM, either. This is true, and I'm excited to try and build something more complex in Svelte and see how it goes.
• christophilus 6y ago
  I hated Tailwind until I went whole hog on a project. There are so many nice little benefits to it, and those compound. Maintenance is a huge win. I haven’t accidentally broken styles once since switching to Tailwind. The VS Code tooling is great. The workflow is great. The reduced context switching is great. Using it with Preact is great, and my app’s bundle size is still smaller than just the dependencies on most React projects I’ve worked on, so I think the bloat is overblown. I’m sure there are downsides, but the upsides so far seem to dramatically outweigh the downsides.
• DHPersonal 6y ago
  Tailwind seems best-suited for the HTML panel on a CMS being controlled by a team that only knows the most basic of HTML and CSS, rather than by the dedicated development team. Having a front-end developer code the CSS for the project seems like a better idea than to scatter the design around the site’s HTML. The shortcut of Tailwind on huge projects feels like part of the mindset that now gives us websites with huge download sizes that frustrate mobile users because the team didn’t get the time to code efficiently.
• _nhh 6y ago
  I do disagree with a lot of points in this. Tailwind is noisy, and sure its not a silver bullet but it removes one thing from out todo list: css architecture. We are really bad at this, esp. naming stuff. With tailwind we are just getting things done and it looks great. Recommending jsx styles has at least the same amount of shortcomings as tailwind, the whole post feels like „i dont like and you shouldnt either, because what i use is obviously better.“ :shrug:
  • _nhh 6y ago
    Admitting that the point of vendor lock in I do feel and did not think about that long But compared to bootstrap with custom styles applied I pretty much have the same situation i guess
  • _nhh 6y ago
    Especially the responsive modifiers are a huge enabler. We are actually several month in the making of a very specialized mobile website which is gonna be released as an android and a ios app. Recently we are asked to add a desktop version. I was really concerned about our given deadline and said to the client, it would be possible but would probably take one or two weeks to develop. After telling my colleague that we have to make an desktop version out of the app, we were both concerned. But it turns out that after one day in the making, we did have a fairly good looking desktop version which the client really liked. I am pretty sure that with plain old css and our poor architecture we wouldnt be able to deliver in time.
  • azangru 6y ago
    > but it removes one thing from out todo list: css architecture I thought CSS modules have done that. Unless you are also arguing against a build step.
• wrnr 6y ago
  I like to style my web component using the tag name like - my-component { color: red }, would such a thing work well with tailwind?
  • aidos 6y ago
    You can use their classes to build other class, yes.
• nwmcsween 6y ago
  My issue with tailwind is the absolutely arbitrary naming scheme, I developed something similar to tailwind but the CSS naming was created to be mnemonic and use common property values (based on top 10,000 site CSS property values and few extra). `display: flex` was `di-fl`, `display: flow` was `di-fw`, etc.
  • hifly 6y ago
    are you sure those are easier to remember than the tailwind equivalents ("flex" and "flow-root"?)
    • nwmcsween 6y ago
      Yes because the naming was generated from a programmed ruleset, nothing was arbitrary
• corytheboyd 6y ago
  I had to stop immediately at “Tailwind makes code hard to read” and you’re telling me your home rolled css solution is any easier to read and understand? I would very much argue against that, as a home grown solution comes with zero precedent about how it works, so you have to go reverse engineer it from one or more source files, whereas tailwind is tailwind is tailwind in every file in every codebase. It’s okay if you don’t like something, but if you’re going to publish a hate piece like this you’re going to get criticism like this.
  • kall 6y ago
    I think the author is arguing for using something like styled-jsx, which is the same as vue SFC styles afaik. That stays fairly manageable and readable as well.
    • onethought 6y ago
      But it also is as “visually noisy” as tailwind. So it fails at his first point. Also the tailwind is bloated is disingenuous given you just remove the unused classes as Pty of your build. Bad faith points all around, maybe except the obscure naming in tailwind. But alternatives like Hucssley solve this (name the properties the same as their css counterparts)
  • joshxyz 6y ago
    This lol. &hover, &active, etc.. fuck that.
  • fuzzy2 6y ago
    You assume that whoever reads the code next already knows Tailwind. They do not. Tailwind might be simple, but it is undoubtedly opaque. A CSS class defined in the same application is not.
    • corytheboyd 6y ago
      Tailwind has documentation is the massive difference.
• keithnz 6y ago
  like many others here, I was a bit dubious with tailwind at first, but I've been using it for a year now with vue. I think for me, because I'd often do my CSS in a similar manner where I'd build up utilities, this seemed like a nice standardized and reusable way of what I was doing anyways. It's super fast to do things when you learn it, the optimized css output is tiny, it is really configurable, I find it pretty easy to read and understand what is going on. I understand what is going on with other peoples tailwind projects really easily also. What is weird, is the author, without irony, uses his vendor lockin to react to argue for better ways to do css? ok.... 1, his examples are super simplisitc and 2 that would actually look really simple in tailwind rather than string injected variables. Which if you have to keep using everywhere is going to make your css super bloated.
• edem 6y ago
  A bit tangential, but I started using Chakra UI on one of my projects and I really like it. Performs much better than Tailwind probably because it comes with batteries included and I almost never have to touch CSS in any form.
• brundolf 6y ago
  Semantic vs utility classes is a religious war that will outlive us all, so I'll try to stick to my personal experience and not get too far into the weeds. With that said: this resonates strongly with my experience using utility classes (Bootstrap, not Tailwind, but I think it's close enough for these purposes). On the giant front-end codebase that I used to manage - which didn't use any CSS libraries or utility classes - here are some things I learned: - It's okay to have semantic classes and also bundle commonly repeated styles under reusable classes. Most of our classes were component-specific, but we had maybe four or five cases where a particular set of multiple(!) CSS properties were repeated in all sorts of different semantic contexts, so we encapsulated those as "utility" classes. However, when it was just one property getting used frequently... - We learned that inline styles aren't the devil. It's perfectly fine to do `style="display:flex; margin-left:1em;"`. The only disadvantage this has compared to utility classes is brevity. And in exchange, it's much more readable and carries zero bloat or lock-in. The verbosity also encourages you to move styles to a more meaningful place once the amount reaches a certain threshold. - For consistency in styling/spacing/branding: just use CSS variables. Preprocessor variables work fine, as do native custom-properties. `margin-left: var(--m-4);` works just as well as `class="ml-4"`, with the added benefit that it can be used equally well inline or in a stylesheet (and, again, no bloat or lock-in). Another interesting benefit is that that value can be reused and assigned to other properties; for example, maybe in one spot you want to `padding-left: var(--m-4);`. - Unpopular opinion: your HTML and CSS aren't really separate concerns in most cases. Sometimes you can find repetition that can be factored out, and if so that's great, but the CSS that controls your layout is and always will be intimately tied to the DOM structure it's targeting. Given this, in my experience, you're much better off having hyper-specific class names (most of the time!) and, if you find it helpful, some sort of componentization/scoping system to make sure they stay hyper-specific and don't leak (I didn't find that we needed the latter, though only because we followed very strong conventions). That's just my two cents. In my decade of writing CSS I've come out against utility classes as a formal methodology, though I'm also very comfortable hand-writing CSS and I've mostly worked at small companies, so those factors and others may bias my opinion.
• ookblah 6y ago
  tailwind ramp up is kind of jarring at first, but any verbosity is 100% made up in the prototyping and maintenance phase. i can't tell how much easier it is to just dev my components structure + style and have it reflected instantly vs trying to think of some clever div class then go to the stylesheet and work there. months later when you are re-visiting your widget you have to get back up to speed on exactly how things are structured. with tailwind i can instantly see it and adjust.
  • papertokyo 6y ago
    This is exactly what every "why I don't like tailwind" piece misses, because most of the people writing them haven't actually used it for more than a week (if that).
• captainmuon 6y ago
  I feel like an old man yelling at clouds, but I actually like CSS, with classes, specifity, and the cascade. Maybe the difference is that other people build apps with lots of components. When I write HTML I mostly build web pages - a lot of text, some images, and maybe a menu. I need to be able to tweak properties among a lot of different elements at the same time. E.g. change the font face on all elements in the main area, change the color of all links that are not special links, rotate all titles and underline them, and so on. It's an iterative approach, as I evolve the design in HTML (I don't have a designer team that hands me a psd I just have to copy). To do this with Tailwind, you'd have to use components, and you'd have to add another layer of abstraction to affect the right components together. And I know nobody really uses CSS Zen Garden style themes - but it is great to be able to take a HTML snippet and use it in another project with minimal changes and a different CSS design. CSS has shortcomings - it's missing a way to "include", it could have more complex selectors, it can get unwieldy in larger projects - but it is also does a couple of things really well.
  • sammorrowdrums 6y ago
    I think the styles everywhere thing depends somewhat on how you create components. For example I have used Tailwind with Styled Components so I have isolated CSS for components and interactions, and consistent classes for layout. It really makes maintenance a dream. When you update a component it is clear what CSS is tethered to it, so you don't accidentally leave unused classes around or tweak classes that are used elsewhere with unknown results. The bigger the app, and the more developers the more this becomes useful. Of course for personal sites and blogs and projects many tools are overkill. But I have saved so much time, bugs and effort by moving to Styled Components. Tailwind feels like what I previously used bootstrap for. I can hand write the CSS but I want to be able to quickly switch columns and fonts and alignment in a cross browser, mobile friendly way while writing the HTML on the first pass when working professionally.
  • mattmanser 6y ago
    The irony is, you're the niche case, and from now on, will always be. Almost everything on the web is basically an application, or runs on an app. Anything based on wordpress is an app. On Wix, or Rails, or whatever. They're all apps. Almost no-one has static websites. So your use case, which CSS might actually kinda fit, is the niche that CSS should actually ignore, or at least treat as a 2nd class citizen.
• alex504 6y ago
  "I am fortunate to have only worked with Tailwind CSS in local sandboxes, and not in any production projects or on an actual team of other devs." Does anyone else get frustrated when people post blogs like this without actually using the technology in any meaningful way? I was also skeptical of Tailwind, and disliked it for the first 2 weeks or so of using it, but now I'm not so sure. This reminds me of the phenomenon in outdoor gear where 75% of the reviews are people who bought a tent and set it up in their backyard and for some reason deigned it necessary to write a review.
  • cultofmetatron 6y ago
    so much this! I started tailwind not particularly liking it but intending only to use the grids which I did find really nice. It ended up taking over all of my css needs because it was so pleasant to use once you got into its way of working. And yes, I've handrolled my own and used bootstrap and bulma previously. Tailwind hits a sweetspot for me when I'm trying to knockout components fast.
  • graydsl 6y ago
    We use it in production for about a year now. We never had any issues with tailwind or how the markup looks. In the end you put that into meaningful (react) components anyway.
  • johnfn 6y ago
    Yeahhhh - I feel like if people had to qualify their opinions and comments on tech with in what capacity they've been working on it (professionally, personally, in 100 person organizations, 1000+, etc), then 90% of all internet arguments on this sort of thing would end before they even begun. ("I think all JS-related tech is stupid! Also my main exposure to it has been through looking at the Github page for React once..." oh boy.)
    • zwily 6y ago
      I can’t tell if you’re for or against the idea, but you make it sound great. :)
  • 6y ago
• balfirevic 6y ago
  I'm happy to see the discourse has shifted from "WTF, who would ever think Tailwind is a good idea?" to at least trying to give some arguments against using it :)
• lmarcos 6y ago
  Designer who has to touch PHP code: - yeah, I like having the whole project's code in one big index.php file. No context switching, no need to go through dozens of files (controllers, models, etc.) to understand what the system is about. No semantic naming at all. My productivity is high! The majority of the comments here that praise Tailwind seem to be from people who are actually not " 100% frontenders", but perhaps "fullstack devs" or even "backend devs" that have to touch HTML/CSS from time to time. It's understandable that the practicality of Tailwind attracts people who work occasionally on the frontend.
  • ZephyrBlu 6y ago
    Yeah, the way I see Tailwind is basically "that just sounds like normal CSS with extra steps".
• ArchOversight 6y ago
  The authors proposed replacement requires me to be involved with Javascript deeply. I use Tailwind to style templates that are used for static pages. I don't have JSX components, I don't have javascript at all other than for Tailwind's building... Tailwind is great. I have quickly been able to create a template that reflows based upon the size of the browser, in a manner I haven't been able to do so before, and all in the same place where I am already defining the HTML. If I were to do it with media queries and have to redefine `.thing` in two different places if I made a change to one I would now have to hunt it across the file to make the change in the other four locations for all of the breakpoints I want, that becomes tiresome quickly.
• stevebmark 6y ago
  Utility classes are good, don't worry about that. Utility classes are a required part of any good CSS system. Programming with only utility classes, and patterns like OOCSS and BEM are bad, and we've stopped using these for literally decades. The more important question is how do these libraries work under the hood, which is both little understood and rarely included in analysis. Breaking out CSS files is critical, any CSS created and inserted by Javascript is unforgivable in production. Focusing on what the libraries do in production is the key. And if your tool needs some special DSL to use native CSS features like @keyframes, don't use that tool. Period. The author is right in that CSS is 100% a solved problem, and the answer is component scoped CSS with some global utility classes (which can come from Bootstrap or wherever if you choose to use such a framework). There's nothing better, it solves every need, and doesn't come with any of the baggage of other systems.
• machinelabo 6y ago
  Taiwind CSS is how you get incoherent overall design. Each element is customized to "look" nice but there is no overall architecture and design system. Padding here and padding there, this bold and that bold - visually tuning the entire page to look nice, but lacks a level of design coherency that is achieved best with a classic CSS based approach. You can do it with Taiwind to "remember" standard padding/spacing and Tachyons does it better than Tailwind, but I personally prefer the classic method even though its not as immediate as Tailwind classes inline with HTML. People are allured by the rapid prototyping aspects of Tailwind which is the main bait. It's pretty fast to see results immediately without openining the css file.
  • ithrow 6y ago
    People are allured by the rapid prototyping aspects of Tailwind which is the main bait. It's pretty fast to see results immediately without openining the css file. This an interesting psychological point to discuss IMO, we get lured to things that feel "fast" but actually aren't.
    • philsnow 6y ago
      That sounds just like Duolingo (it feels like you're making progress because you're getting better at the things that it's testing, but unless you try to participate in real conversations in the language, you're not making progress in an actually useful direction)
    • machinelabo 6y ago
      It is actually fast though. Just doesn't produce coherent design over time and creates a huge mess where design langauge is intertwined in symantic layout. Hey, wasn't that the original intent of HTML+CSS? To isolate markup and design?
    • dragonwriter 6y ago
      > This an interesting psychological point to discuss IMO, we get lured to things that feel "fast" but actually aren't. It's not so much “feels fast but actually aren’t” as “fast onramp that makes downstream maintenance slow”. That people tend to be bad at balancing downstream costs against current benefits is well known, and that's even outside the context of business situations where the cost is attached to a role that decision-makers may expect to be out of before the cost is realized, and outside of social contexts like speed-of-this-iteration-focussed development methodologies that structurally encourage discounting future costs.
• rafaelvasco 6y ago
  In my earlier projects I always found myself doing exactly what Tailwind does, manually. As Tailwind does it much more throughly, I'm now 200% productive. I can adjust everything by just stacking classes. For me it's perfect but I can see why some people dislike it.
• mplewis 6y ago
  I tried to use Tailwind to style a project, built in Rails, with server-rendered HTML templating. I found that it was too much work to keep it all straight in vanilla HTML. But I could see Tailwind being a great fit if I started a project using, say, Vue components. In that world, Vue helps remove some of the repetition by hiding it in higher-order components.
• brightball 6y ago
  Tailwind was a breath of fresh air for me. https://www.brightball.com/articles/thank-you-tailwindcss https://www.brightball.com/articles/thank-you-tailwindcss
• sandgraham 6y ago
  Why is it that Tailwind causes such emotional reactions in people? Functional CSS has been around a long time now. When functional css ideas were introduced it presented a novel solution for scoping issues, naming issues and bloat issues. I remember discovering basscss and tachyons around 2015. The paradigm immediately felt like a huge improvement in my workflow. The iteration was so much faster than what I was used to with Bootstrap, BEM, or SCSS- I felt like I could design in code for the first time. My favorite workflow for web design became loading basscss in a CodePen, with almost no idea of the outcome I wanted and iterating towards something. What’s kind of amazing is that it allowed for these sorts of quick sketches and improved maintainability in large projects. It also led me to my first inkling of a design system- through the use of composable and constrained styling primitives. A lot of the ideas introduced with those libraries now saturate the frontend ecosystem. And keep in mind, functional CSS, or at least the principles behind it have evolved a lot since 2015, particularly when it comes to components and CSS-in-JS. The original creator of basscss has gone on to create a number of equally impressive projects that advance the main ideas: styled-system, rebass, basically everything from @jxnblk. I haven’t used Tailwind or any other functional CSS philosophy over the past few years since I find primitive and composable styling components, CSS-in-JS, themes, and CSS variables offer even better workflows for building the applications I work on. When Tailwind initially made a splash I was already pretty into what I consider this next phase of styling libraries- so I was a bit confused why people were so excited about it when basscss and tachyons had been around for years. Looking through the docs it seemed like they had taken basscss and tachyons and layered a bit of Bootstrap on top (in the form of nicer visual defaults and some component patterns). Outside of the core functional principles, I don’t like the idea of Tailwind as much as I do basscss/tachyons. I think Tailwind tries to put too much of your styling in atomic classes. Part of what makes basscss great is the small API and the constraints it introduces on reusable patterns. I don’t want all of CSS to be represented as atomic classes- just the stuff I reuse 90% of the time. It also seems like a bit too much tooling when one of the main advantages I saw in the older libraries were that they were just plain CSS- you could use them on pretty much any project, regardless of build tools or architecture. I used to start with basscss on a project and then add my own layers of patterns on top- extending the system as needed. That said it still offers a lot of the good stuff, combined with great documentation and more thought put into component patterns. It’s a great starting point, especially if you don’t want to or can’t take on runtime costs for CSS-in-JS (this is also evolving but still a concern). Its success isn’t a fluke or a result of misdirection as the author of this critique alleges. Reading through Adam Wathan’s original post on functional css (https://adamwathan.me/css-utility-classes-and-separation-of-concerns/)- https://adamwathan.me/css-utility-classes-and-separation-of-... he describes the exact same trajectory in CSS thinking I went through as a frontend developer through the 2010s. It’s a great read and I think speaks to the level of consideration put into the library. If I were to try a new project today using functional CSS I’d definitely give Tailwind a shot.
• poletopole 6y ago
  No one will see this comment buried under 200 others, but if you made it this far checkout basscss. It's the only css framework that ever has made sense to me. Devs keep recommending Tailwind to me and I honestly don't understand what they see in it, I feel like I'm taking crazy pills.
• yowlingcat 6y ago
  The problem with this invective is none of the points really stand alone if the first point happens to based on an incomplete understanding. Unfortunately, that seems to be the case here. Using Tailwind purely at the HTML level is not the only way to use it, and in fact, this is only supposed to be used at the prototyping stage. it's a pretty standard part of the Tailwind workflow to extract class combinations into helpers that can be reused. If utilization doesn't even get to this depth of use of the tool, can one really consider the usage the tool to be anything more than an abuse? Frankly, Tailwind was a gamechanger for the way I do vanilla CSS. It makes it really fast for me to prototype, straightforward for me to refactor, and I end up with CSS and HTML that is straightforward and easy to maintain. It is what I always wanted Bootstrap to be, which is the Rails of CSS. Now, there are certainly valid critiques to be made of Tailwind, just as there are valid critiques to be made of Rails. But in my opinion, many of those critiques are red herrings that boil down to abuses of a very useful tool. I always have to ask myself in these situations if the problem is the tool itself (if used properly) or an abuse of the tool. True, before I learned how to use Tailwind and grokked /why/ people used it, I was suspicious and leaned towards the former. But that's exactly why I wanted to force myself to use it and figure out what everyone else was excited about, even if I didn't feel the same. Of course, once I learned it a little bit, I felt the same way I did about Rails, which is that it's an extremely useful tool for a lot of jobs. It did not get popular by accident, or because "everyone is an idiot" -- it got popular because it solved a very real problem significantly better than its competition. I would hope the author eventually opens their mind a little bit to try and figure out why that is the case. They just might experience the same a-ha moment that I did.
• nraf 6y ago
  Does Angular natively solve at least part of the problems that Tailwind / CSS-in-JS with the way it scopes it's CSS? With Angular, it's generally quite simple to figure out where the CSS for a component lives (it's literally right there in its own file alongside the component). Sharing common values (e.g. colors, borders, paddings, etc) across classes was the biggest issue we faced, so I can see Tailwind being useful there. In our project, we've somewhat solved it through a mix of sensible base styles and classes ('btn'), custom classes (e.g. `clr-primary--500`), CSS variables (e.g. `--clr-primary-500`) and SASS mixins / functions. It also makes it really to switch out themes dynamically, switching b/w dark and light modes for example, just requires switching up the CSS variables.
• shadowfaxRodeo 6y ago
  The author didn't touch one of the biggest issues of Tailwind. It ignores the Cascade part of CSS. Even after optimizing Tailwind. You still end up with way more css than you should have. Add all the classes in the HTML and you're sending users a massive amount of data. Instead of writing: main > * + * { margin-top:1rem } you write `mt-100` a thousand times.
  • criswell 6y ago
    There's `space-y-N` which does exactly this, `space-x-N` for horizontal.
  • Scooty 6y ago
    What do you do with that snippet when you realize some elements arbitrarily need more or less spacing than others because the designer decided it looks better? Repeating yourself isn't the end of the world, and on occasion DRY is worse (look up incidental duplication).
  • tvphan 6y ago
    Mate, there is a `space-y-1` helper class.
• pier25 6y ago
  I agree with most of the points in the article except the mention of using CSS in components. IMO CSS in components only really works in some situations when the component is very small and there isn't much CSS. I love Svelte, it's my main framework these days, but after many years in React/Vue/etc of trying in-component styles, I've gone back to good old SCSS files. It's a bit tedious to manage Component.svelte and Component.scss but there's such an elegance to writing pure SCSS. Not only your component files become much simpler, just markup and logic, but you can use SCSS as it was intended. With vars, mixins, third party utilities like Bourbon, etc. The separation of concerns feels awesome. Like going back to the ZenGarden of yore.
• eyelidlessness 6y ago
  Having just built a project with Fela, I'm curious if anyone experienced with it have a take on how it compares. I immediately rejected Tailwinds because I do actually prefer to write CSS. The end result in the HTML is about the same (garbage pile of classes, biggest difference is they're meaningless).
• knlam 6y ago
  Look, I don't like Tailwind as much as author but I think author make several weak points about tailwind weakness (apart from the hard to read part). Here is the better argument about why you should not use tailwind: https://sancho.dev/blog/tailwind-and-design-systems/ https://sancho.dev/blog/tailwind-and-design-systems/
• quark_frog_223 6y ago
  If pure CSS is like cement - form it however you like, but you need to do it over and over again, and Bootstrap is like those colored wooden building blocks children used to play with - you get your standard shapes and that's it, but most easy to use, than Tailwind is like Lego - you can't form freely like with cement but have enough freedom to build creative designs based on *given* standard building blocks. That's how Tailwind won me over. Sooner or later most design-devs (devs doing design as well) end up using some kind of utility classes. Using Tailwind from the start saves some serious amount of effort and provides a standard across projects and teams.
• sepehr500 6y ago
  I have used Tailwind on multiple large production sites over the years and seen pretty hard core CSS devs learn it. Every time they start off with skepticism. One week in they love it. To address your points, 1. Tailwind Makes Your Code Difficult to Read Not sure why the styled-jsx examples at the end are easier to read. Tailwind is semantically obscure like any language you don't know is semantically obscure. Also with the intellisese VSCode gives you, learning is super easy. 2. Tailwind Is Vendor Lock-in Vendor lock-in is a really strong word for what is going on here. Would you say React is vendor lock in because switching to another lib is hard? I worked at a company where we switched all of our CSS modules to Tailwind, and it actually cleaned up the code quite a lot. 3. Tailwind Is Bloated It's actually the opposite. Large companies use atomic css approaches because it keeps your CSS bundle small. Especially with purgecss, you can get bundle sizes super small. I even saw a company switch from CSS modules to Tailwind to reduce they CSS size for AMP. 4. Tailwind Is an Unnecessary Abstraction @apply is the equivalent of composing functions together in any other programming language. Also @apply lets you keep using the scales and color palette you set in tailwind. 5. Semantics Is Important. Tailwind Forgoes It. Naming things is hard. It's a problem in regular programming, and CSS is no different. Needing to name less things makes life easier, especially when you component system name is already descriptive. 6. Tailwind and Dev Tools Don’t Play Nicely Usually I just click .cls in dev tools and check or uncheck styles as needed. Or if I start typing a style dev tools intellisense helps me. 7. Tailwind Is Still Missing Some Key Features pseudo elements are being discussed. As for it not being possible because of bloat, see above (PurgeCSS)
• sekmet 6y ago
  Tailwind is amazing! Zero regrets using it daily!
• NiceWayToDoIT 6y ago
  Some of those arguments are kind of reasonable, until author defeated purpose by recommending `styled-jsx`. I am just trying to imagine working in a team 1 dev + 1 designer...
• whatarethembits 6y ago
  As someone who's been familiar with tailwindcss for a while, it's undeniably huge benefits first hand AND also having worked with other popular CSS frameworks on production codebases this thread is a reminder yet again of cautious you have to be of comments on any public forumn. So much confidence and denial based on trivial details that would've been cleared up with barely a week of usage. Why comment at all (especially with so much confidence) when you clearly don't have experience of something? How many other topics have I been influenced on that I don't know much about, by unfounded confident opinions based on absolutely nothing?
• blacktriangle 6y ago
  I'm not a huge Tailwind fan either, but this author is missing something major in his obsession about long lists of utility classes. The @apply directive is there to convert utilities into semantic classes, and eventually that's where you get on a Tailwind project. Where Tailwind is different is the development process. One problem with CSS is that before you can do anything, you have to come up with a class, ie some abstraction. You then start using that class all over your code until over time you realize it is the wrong abstraction. What Tailwind lets you do is get going without having to create any abstractions. Then as time goes on you see the repeated patterns in your code and can use @apply to refactor those into the correct abstractions. So you end up in the same place as traditional CSS, but the trip is much smoother. The author's complaints about pseduoclasses and break point are spot on though, and he only lightly touches on pseudo elements which are another huge black eye for Tailwind.
• AltruisticGapHN 6y ago
  Use bem like convention for your css so that all your custom classes are "flattened". See eg. SuitCss naming conventions. Lint with postcss-bem-linter so classes follow PascalCase component names typical in React or Vue. Also lint for a optinal namespace (prefix eg. ais- used in Algolia Search). Then import tailwind after yours, that way any simple flattened class can be overridden by tailwind utils. So now you can have component say .ns-MessageBox feature a default text color, or font size or anything, (optinally using @apply in the scss stylesheet) and you can override any good defaults, as well as handle layout & spacing in the template eg. <div class="ns-MessageBox text-red mb-4">…</div> Likewise then you can also set a good default stylesheet for plain html headings, lists, etc. Because selector "h2" can be overridden by utility. So your headings lists etc can also have sensible default bottom margins padding and whatnot. You have to look at the design templates to determine good defaults, then you dont need to be so verbose with tw in templates. Then you can also keep your entire color system in Sass if you prefer, take advantage of Sass functions. It’s very flexible. A good ruleof thumb is to use tailwind in templates for all the space around components, main layout and spacing of all individual components. Those are the things that tend to bring really confusing and complicated css selectors with pseudo selectors to target first/last elements, which is hard to maintain, hard to read for other devs, much better handled in templates.
• AltruisticGapHN 6y ago
  The author doesn’t understand value of utilities and composition, regardless of the css framework. Unsurprisingly then, recommends awful css in js approach. Granted the value of composition is most appreciated when you do the frontend of component based apps. You can use sass, big picture architecture of the styles across app, and also benefit from a shared language with the rest of the team and write less css for mundane things that composition solves very easily (eg. a heading with less margin than default, a messagebox with different font and whatnot, dont create hundreds of classes or modifiers when a few utilities can do this). Sadly most devs dont understand css precedence enough to figure out how to easily combine custom css and tailwind approach. (use bem style convention, keep specificity as low as possible, ideally 1 )
• uxamanda 6y ago
  I ended up creating my own utility classes for projects instead of adopting Tailwinds. My issue with Tailwinds from a design standpoint is that it allows for too many combinations, which is the issue with plain CSS. Having less choices makes things more consistent and IMO easier to read. For example, a font style in our project includes the family, weight, line-height, alignment, and size in one class. This is called something like `Font16RR`. Responsive sizing is handled in the class itself (so, it may be 20pt on large screens, even though it is called "16"). We also have utilities for a small set of spacers, margins, colors, and layouts. These are defined in parallel with the UI designer, so we both call them the same thing and we agree it's a "big deal" to add a new one. This has reduced the number of styles in a large legacy app dramatically, making everything look much more consistent. This has the added benefit of being very easy to provide different themes which was a requirement of the project. I admit that this system requires other front end developers to either 1) Internalize the design system or 2) Receive specific mockups and copy them verbatim. Would love to hear the perspective of anyone who has worked on whitelabel software and had to manage multiple themes and/or worked with very strict design systems with Tailwinds.
• mpcannabrava 6y ago
  I skipped to the "what should you do instead" and the code examples the guy gives are laughable. Would rather have that in your code or a few utility classes in your components?
• XCSme 6y ago
  Personally I'm not a fan of tailwind BUT I always end-up creating my own utility classes (eg. .font-bold, .flex, .flex-center) and use them in combination with normal classes, just like modifiers. So I do something like <div class="button text-center">. I am not sure if I could actually include Tailwind and just use their utility classes for my needs, in combination with the normal CSS usage, or that would make things confusing.