People want painkillers, not vitamins.<p>That's why there is this endless flow of snake oil frameworks like Tailwind and all the others.<p>People see some fancy demos and think "wow, so cool so easy" and "This is the newest framework, so it must be the best" and go for it.<p>Then over time, they get caught in a web of problems that the complexity of the framework produces.<p>Then a few people go for the vitamins route (plain html+css+js) and most go for the next painkiller on the market.
I love tailwind. I strongly feel that most modern CSS solutions are massively overthought. In engineering we have bigger problems to solve than a key/value list that makes a div blue.<p>Tailwind removes the thinking around CSS, naming, preprocessors etc etc, it just lets me write good CSS and focus on components and other engineering problems.<p>I seem to be one of the few people who can read CSS properties horizontally as well as vertically, so I'm all good on most peoples major complaint.
Especially in the HTMX community I'm alwayws wondering why people are chosing Tailwind. I tried it too and had the same problems as stated in the article.<p>Mainly that its polluting the HTML so much. I went the opposite route and am using PicoCSS now which works with semantic tags and can even work without any classes. Feels much cleaner
Disclaimer: I’m extremely newbie in front end, probably less than 6 months of experience combined in the last 6 years.<p>I can’t stress enough how easy it is using Tailwind, it just works! I don’t care about the long ass lines because for how I’m used to format html pages, I’d have to go to a new line anyway, it’s just that now I can understand what’s happening in react components without too many troubles.<p>Another plus is that by checking other people’s html code, I can immediately see their tailwind tags, without searching through files for css definitions, I see how they change their stuff there and I can immediately learn how to replicate their patterns.
Imagine how fruitful saving time is, especially when using framework like nextjs, you can literally launch a prototype in few days of work with these technologies.<p>Don’t get me wrong, I know that you’re not going to build the next Facebook or Microsoft with Tailwind and Nextjs, they have their drawbacks, but their impact on the critical path from the idea to a working MVP can’t be ignored.
This from 2021. No criticism, it is a good post. I was just confused at first and only realized it when I came about the part mentioning the JIT.<p>This is a hill I will die on: Blog posts should have a date at the top.
As a non-web developer with a couple of relatively sophisticated side projects, I've never understood the appeal of Tailwind. It somehow manages to be hideous, verbose, and absolute gibberish all at the same time. If I wanted that, I'd write everything straight into the style tag. I can't understand why Tailwind would be any easier to maintain (and I'm sorry, but you will never convince me that I need a javascript precompiler for my damn stylesheets).
Yeah, it isn't Tailwind that doesn't support web components. It's Shadow DOM that is such a bad abstraction that it breaks the web in innumerable ways and need dozens of new standards to fix its shortcomings.[1]<p>And yeah. That <fancy-component> that is seemingly not an eyesore? It's not because Tailwind is bad and "pollutes HTML". It's because web components hide any and all ugliness from you so that you can <i>pretend</i> they are beautiful.<p>Because in the end there's literally nothing on the web but divs and spans<p>[1] From web component report by people making them: <a href="https://w3c.github.io/webcomponents-cg/2022.html" rel="nofollow">https://w3c.github.io/webcomponents-cg/2022.html</a><p>It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
I use Svelte for frontend develoment, and used all of JS frameworks that came before it. It's very web component'y. I feel Tailwind was partially created by the problems rising from the bad design choices of many modern web frameworks.<p>In Svelte, There is less need to use Tailwind, because HTML, CSS and JS (or TS) are all encapsulated in a single source file. Editing CSS alongside the HTML is easier than bloating the HTML with a class hell. You can use native syntax highlighting, IntelliSense, early compiler error catching and linting plugins of your editor.
Tailwind is an abomination.<p>Of course it's easier to use. Pressing the bold button in MS Word is easier than setting up styles etc, but one makes it easy to create an impossible to maintain mess that could have been made by a primary schooler, and one makes it possible to create a consistent style that looks professional.<p>The only reason I think Tailwind is becoming popular now is it's exposing a bunch of things like rounded corners and drop shadows that are still cool but unlike Bootstrap you can slightly tweak your rounded corners easily. It'll still lead to everything looking the same, then people will probably ditch it and go back to really minimalist styles like HN to look cool again.
The endless roundabout of discourse on which technology choice you should or shouldn’t make is exhausting. As a senior engineer im able to sift through the bullshit on this but as a junior I remember these discussions were draining and also made me feel like shit about decisions I’d made.<p>I guess it drills into a part of human nature where we are always measuring ourselves and our things against others.
Decent arguments. Ultimately, I think your preference comes down to:<p>- Do you care about how your html output looks? - I personally don't, just like I don't care about what my Webpack bundle looks like. Web standards will always be slower to evolve, which is why we build tooling on top.<p>- How do you think web components will be used? - I believe they will be used sparsely, only by libraries. But if you want to replace your frontend framework (I currently don't see why), Tailwind will not work.<p>We've opted to work with CSS Modules (which give you many of the Shadow-DOM advantages), but I would be lying if I didn't see the appeal of Tailwind every day. For me, it's the redundancy of having to give semantic names to elements that are already described by their React component names.<p>Tangentially, developers often are tempted to use classes for things that should be components. CSS classes <i>must not be used for code reuse on a large scale</i>, because CSS and HTML are bidirectionally coupled and you <i>will</i> end up search-replacing large sections of html because the design team wanted the text to align in a way that is somehow impossible without adding a div.
As someone who used to make websites in the myspace days (and has about that much experience with web dev, plus a few static client sites from high school), I gave tailwind a try for my most recent project. I think it saves me a bit of time, and it's easier to get a decent aesthetic quickly. That said, I don't feel it's strictly necessary, and I don't like the HTML bloating either. It makes me want to create classes, at which point it wouldn't be necessary to use tailwind anymore.<p>The author says this about using @apply:<p>> Therefore, it’s simply the truth that CSS files built for Tailwind are non-standard (aka proprietary) and fundamentally incompatible with all other CSS frameworks and tooling. Once you go Tailwind, you can never leave.<p>How true is this? At worst you could use your output.css and at best I'd expect an automated tool that could do this conversion.
I feel the same about javascript:<p>"I think the folks building Tailwind are talented and nice people. But at a pure technical level, I simply don't like Tailwind. Whoever it was built for, it was not built for me."
Most of the devs I've encountered that really like Tailwind have their focus more in the realm of development and engineering of a whole system where the UI is a means to an end. They are not deeply focused into the nuances of user interface design.<p>I can understand and appreciate what Tailwind is all about. It's a standards approach to naming conventions and puts all the details in the markup. Which has its value.<p>I've found a happy balance to be:<p>1. utility classes for layout and structural details<p>2. custom classes for look/feel details<p>3. after x utility classes, its time to combine into a single class<p>x is very much based on situation and intuition not a hard rule.<p>I'm still using LESS because of nested css, and classes can be composed.<p>One benefit of LESS is the style code is decoupled from react/angular components and more importantly the shadow dom.
I hated tailwind with a passion at first glance. I thought it looked horrible and while it still does, I decided I don't care.<p>After a while of using Tailwind at work, I have started to love it. It it just so much more productive and I rarely need to step into css-land anymore. You still need to know and understand how CSS works in order to get the most out of Tailwind.<p>Tailwind is just like CSS but with shortcuts ready there for you to use.
> We live in a world where custom elements (aka <whatever-you-can-dream-of>) are fully supported and enabled by modern browsers.<p>Don't we need to define the custom element <whatever-you-can-dream-of> using javascript first?<p>All my knowledge about custom elements comes from this Mozilla doc: <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...</a><p>If custom elements is the way to go, it sounds like a lot of javascript and coding overhead that I have to take. Doesn't it?
I can't understand why people bother about HTML with long class attributes so much. If you use "btn" instead of a long string of Tailwind classes, you just move the actual CSS properties into a stylesheet file, which you need to switch back and forth to just to change the looks of that button.<p>And having said that, when using Tailwind with some kind of component-centred framework, those classes will be local to a <Button> component anyway, which is <i>exactly the same</i> as some kind of custom component the author praises (that also needs styles within.)
> The problem is that all these tokens are defined…in JavaScript. A CSS framework. Using JavaScript for its design tokens. In 2021.<p>And THAT right there is the core problem of such frameworks.<p>The trinity of frontend technologies, by design, have a clear separation of concerns: HTML structures, CSS styles, JS implements logic.<p>Of these 3, JS is, by necessity, the most powerful, and the one that can change the other 2 the most. So, as programmers like doing cool things, the temptation is always there to just write some JS that grabs the other 2 and does whatever with them.<p>This would, in theory, be fine...<i>if there was a universally agreed way to do this</i>. The problem is, there isn't. We still pretend, and can even implement it in a way, where the concerns are actually separated (thanks to serverside rendering we can even do so dynamically), and we have not one method of violating this separation of concerns, but a gazillion ways, spanning the full range of compatibility from "no problemo" to "are you crazy?".<p>This needs to stop, I say desperately, while being fully consciouss of the fact that it never will, since the genie is already out of the bottle and has been for a long time.
I'd actually love a tool that converts tailwind CSS to regular CSS on save because my biggest issue with CSS is that I constantly have to come up with ids and class names.