I find Tailwind's claim that you can "build modern websites without ever leaving your HTML" to not be entirely correct. Instead of context switching from my `.html` to a `.scss` file, I just end up context switching to their documentation website to find the syntax they used.<p>It's internally inconsistent, so you can't guess what the Tailwind class name is for styling, while you can do this for CSS on the majority of properties. In Tailwind, font weights are just `font-bold` for `font-weight:bold`, while font variants drop the `font-` prefix part, and become `ordinal` instead of `font-variant-numeric:ordinal`. That's not an isolated example, it does the same with text-color versus text-decoration, and text-decoration-color adheres to neither of those systems.<p>It's quite close to learning an entire new styling language on top of CSS. It may be the case that putting everything into the HTML is more efficient from a productivity point of view, but I don't think Tailwind's specific implementation achieves that.
I work every day with web projects, and the notion "Tailwind won" in any capacity sounds like a thunder from a clear sky.<p>If we see more articles to that effect and this is not an outlier, it means the Tailwind cult is in its "red dwarf" stage, where the community becomes smaller, but denser and more convinced than ever that the entire world is a copy of their small bubble.<p>That's good, it means in a few years Tailwind will be considered a dead tech. Tech bubbles are so weird. It's like the tulip mania or the NFT craze. It all makes sense when you're in the bubble. While those outside are looking at it, and seeing what is clearly mass psychosis.
I love tailwind, and I've been writing CSS professionally since CSS2.1. I have often debated with many developer friends why it has performed so well, and this article really missed some big reasons:<p>1. It's works extremely well with the current component-focused UI frameworks (react, svelte, etc). Subsequently, the verboseness that is often a complaint isn't an issue at all, but a feature.<p>2. Does everything out of the box, and very easy to customize.<p>3. And, most importantly, it allows for easy art direction. Does one button need to be a slightly different size or color for this one specific element? Chuck an extra modular class on it. No need to build a complex cascasding or edge cases. (Shout out to `tailwind-merge`)<p>Point 3 for me speeds up production work immensely. Also, not being in JS has shrunk bundle sizes by a small amount, which is always welcome in this era.
If css had a strong opinion and better syntax for responsiveness by screen width, css frameworks were way less popular. Tailwind, bootstrap and co. aren't used to avoid writing css. It's used because writing
`class="my-4 mb-sm-5 mb-lg-6"` is so much faster and easier then doing this with a bunch of media queries and a class name, that has to be unique, because css is a global scope nightmare.<p>I mean, just look at it. You have to write all this crap in css just to achieve `class="my-4 mb-sm-5 mb-lg-6"`:<p><pre><code> :root {
--breakpoint-sm: 500px;
--breakpoint-lg: 800px;
}
.foo {
padding: 1rem 0;
}
@media (min-width: var(--breakpoint-sm)) {
.foo {
padding-bottom: 1.5rem;
}
}
@media (min-width: var(--breakpoint-lg)) {
.foo {
padding-bottom: 2rem;
}
}</code></pre>
For getting designs up and running quickly, it really is great.<p>Being able to think "Hmmm, I want a rounded button, with a border and a blue background" and just typing class="rounded border border-blue-600 bg-blue-500" and it's done.<p>With lots of UI being components now, it doesn't really matter that it is verbose - I actually find that helpful. And even if you want to have a class that you use all over the place, just use @apply and create a custom class that you can use anywhere.<p>One place it can be hard to use, is if you have a specific design system - then yea at that point you either work with Tailwind and modify the config to match, or you just go with standard CSS - but at that point it probably makes sense.
I never got how is "context switching" such a problem. I mean, can't you have like, two files opened side-by-side in different IDE panels? Is it really that hard to "look jump" from one another? This justifies the amount of overhead added by a library like this?<p>If I can be blunt: I find this "argument" to be lazy as **. Sorry but "context switching" is just a fancy name for "having two files opened at the same time", which shouldn't be a problem, no?<p>PS: And almost all the other stated advantages of this approach seem to be as low value as this one considering the implied costs.
I think Tailwind is more accessible to many[*] less experienced or CSS-oriented developers. <i>Big generalisation</i>, I know, please don't yell at me, but many of us can get 99% of Tailwind's value with UI libraries supporting:<p>1) style encapsulation,<p>2) colocated presentation/content/behaviour and<p>3) a more minimalist mindset/habits when building UIs (e.g. relying on simpler styling hierarchies, native DOM elements, semantic HTML instead of div soup).<p>[*] not all, it doesn't mean that it doesn't make "senior" (whatever that means) devs more productive or that if you're using Tailwind you'll lose your 10x dev of the month badge. But, CSS is a misunderstood yet very flexible language which means it can be used or abused in a huge variety of ways.
In terms of skillset, I’m mostly a backend guy (of 20 years or so). I know my way around HTML and CSS, and I have a decent eye for design, but it’s not my primary focus.<p>I recently started a writing project, and found myself unhappy with choosing a standard blog theme, and decided to build my own.<p>For this purpose, Tailwind has been incredible. I don’t have plans to become a front end dev, and investing significant time in improving my CSS skills is not a good use of time for what will be a fairly small project. It gives me more flexibility than frameworks like Bootstrap while still offering a lot of the productivity benefits. It lets me explore concepts and ideas that I otherwise wouldn’t have the skills to play around with.<p>This thread reads like most $language/$framework/$os holy wars. There is an awful lot of hatred over a perceived lack of “purity”, or because of the perceived superiority of other approaches. Like most of these technology debates, the extreme binary positions really miss the value that can be found in the middle. Tailwind has been great for getting ideas out of my head to see how they look, and for staying focused on the content that I’m planning to write instead of getting stuck learning about browser edge cases.<p>If I start focusing more of my time on building UIs, I’ll invest more deeply in CSS.<p>I’m also fairly convinced that many of the negative comments filled with disgust at the resulting syntax have never tried it. After about 10 minutes, the conventions start to become obvious, and I can write visual elements mostly at the speed of thought. This is really quite enjoyable.<p>I’m also not suggesting it’s the right tool for every job. But the lack of nuance in much of the discussion here is pretty disappointing for the HN community.<p>I personally feel that the future of the (useful) web depends on more people choosing to do their own thing. Tools that lower the barrier to entry and simplify content creation will always be important.
This is a good list. I would also add:<p>* It removes the burden of having to come up with class names, and the mental overhead of deciding whether to create a new class or rely on the C in CSS. When writing plain vanilla CSS there's always a sense of friction and a need for careful planning (often resulting in me procrastinating it). That whole process is eliminated with Tailwind and I can just start styling the element immediately.<p>* The fact that you can see immediately how an element is styled. No hidden, detached or indirect styling whatsoever.
Gray beard's 5c: Tailwind is a farce and a catastrophe.<p>It's as modern as the style parameter is, and it's as reusable as a moving a dirt pile from one corner to the next.<p>You're not learning anything valuable by learning Tailwind. Learn CSS, that will stick with you for the next 20 years.<p>It amuses me when a library is implemented 'with tailwind', which means it's totally useless to the people _not using tailwind_, and excruciating to clean up.<p>Go ahead, downvote me to hell, I'll see you in 5 years.
Silly premise and vapid article. Tailwind 'won' in the same way Bootstrap 'won', i.e. it was popular for a time. $10 says Tailwind will be the Bootstrap of 2027.
Wordpress, React, many others win too and nobody would say, that these are superior to anything else.<p>Like in WordPress or React you can fiddle with Tailwind too. People like to fiddle.<p>You can make things easy, or fiddle, what did people do? Correct, fiddle.<p>Why you think so many huge overbloated frameworks have soo much success. Fiddle.
Fiddle is the key to everything in development.<p>You fiddle hours and hours until it works, you feel like the greatest dev on the planet.<p>You fiddle it, you write a blog post over your fiddle and how fun it was, other read it and fiddle too.<p>It work and they feel great too. Fiddle continues.
Those who appreciate local styling as opposed to global would likely enjoy the Locality of Behavior article by the author of HTMX.<p>Link: <a href="https://htmx.org/essays/locality-of-behaviour/" rel="nofollow noreferrer">https://htmx.org/essays/locality-of-behaviour/</a><p>Discussion on HN: <a href="https://news.ycombinator.com/item?id=31454886">https://news.ycombinator.com/item?id=31454886</a><p>I personally find it easier to have information spelled out locally at the "call site".
As a primarily backend person, I like it that our frontend uses tailwind due to the copy-and-pastable aspect. I can nab an element from another part of the site and adapt, or take an element from <a href="https://tailwindui.com/" rel="nofollow noreferrer">https://tailwindui.com/</a> and know that it will paste in and look exactly as intended. It doesn't look good, or particularly inline with the style of the rest of the site but is good enough as placeholder UI before frontend/design can come in and tidy it up.<p>I do constantly shudder though when reading a list of class names like this:<p>> fixed inset-y-0 right-0 z-50 w-full overflow-y-auto bg-white px-6 py-6 sm:max-w-sm sm:ring-1 sm:ring-gray-900/10<p><a href="https://tailwindui.com/components/marketing/sections/heroes" rel="nofollow noreferrer">https://tailwindui.com/components/marketing/sections/heroes</a>
NGL tailwind is really nice to build new things and is absolutely amazing to create MVPs and small projects
...<p>but once you got to the point where you open a file and see 20+ classnames stacked in every div, which makes them unreadable, its just a mess. Love-hate relationships with this tool, but the idea is very good and this article mentions biggest selling points - its easy and very fast to use.
Even putting aside the architectural considerations, one way that standard CSS has failed, is that the naming of properties is inconsistent and increasingly difficult to remember and work with.<p>I find that using tailwind's flex "aliases" (which is almost what they are) is more intuitive than using the god awful standard CSS property names.<p>CSS standards should not just look at adding stuff, but making new versions, like newer APIs where they take a good look and rename all the properties to make them more consistent.
There's a good article by the author of tachyons.css which is similar to tailwind, but never got that much attention:
<a href="https://mrmrs.cc/writing/scalable-css/" rel="nofollow noreferrer">https://mrmrs.cc/writing/scalable-css/</a>
Food for thought:<p><a href="https://csswizardry.com/2018/11/css-and-network-performance/" rel="nofollow noreferrer">https://csswizardry.com/2018/11/css-and-network-performance/</a><p>Progressive rendering of CSS is a great boost in performance. Tailwind can't benefit from this technique I think and as such, imposes an added cost on our users.<p>Correct me if I'm wrong!
According to NPM download stats, it has 6 million weekly downloads, the exact same amount as Styled Components. Emotion also has around 6 million. So that's 12 million for CSS-in-JS, as opposed to 6 million for Tailwind, so how did it win?
The whole "Why _____ won" is the same as specific politically affiliated news channel trying to sway future voters by stating some inflated Exit Poll numbers in favor of the party they are trying to portray as winning the election. Same reason why you see every new graduate you see has been affected by the whole MongoDB/NoSQL, React propaganda.
I believe the primary reason that sets TailwindCSS apart is its inclusion of pre-defined margins, paddings, and colors. Starting with these built-in defaults is much simpler than having to consider all these design elements from scratch.
I always felt slightly dirty after writing a bit of inline CSS (`style=”color: red“`) instead of a proper class, yet at the same time it accomplishes the goal and it was fast. So this is basically Tailwind, right?
Won what?<p>There are far better ways of writing CSS than Tailwind… take a look at Stephanie Eckles, Andy Bell and others work on how little CSS you actually need for great designs
Realistically speaking, with CSS, you don't even need to use one single class inside your HTML. Every element is a child of another, up till <body>. The C in CSS is just that, CASCADING.<p>I find it ridiculous to attach so many classes to your HTML elements. I think it is obvious Tailwind gained popularity because people just didn't want to learn CSS. And I don't blame them, it took me years and I am still learning new ways to achieve things. In a way, CSS's flexibility is also its beauty: you can achieve the same thing multiple different ways.<p>You can do A LOT if you know CSS. With tailwind you can do what others have thought of you might need. This is the antithesis of programming. Programming is supposed to help you break the limitations of tools.
It's ironic that "costly context-switching" is listed as one of the primary reasons, as this normally is considered a "feature".<p>Modern front-end development heavily embraces small components, composability, clean abstractions, reusability, higher order state, decoupling of error logic, testability, and so on.<p>The natural consequence of this paradigm is that when your PM says "hey, can you make a small change to this online form?", you'll be context-switching between many files.<p>The idea that you currently can do "application logic" in your HTML/JSX is a gross misrepresentation of reality.
Folks, while we are at it, what is the best way to learn proper front end for a hobbyst? I'm a decent programmer and work with databases and backend technologies. I want to be able to build simple front ends for the stuff I work on. I've been meaning to dive into D3, but the tutorials for basic front end stuff assume I'm really starting from scratch. But what I'm blocked by is 1) what is a nice workflow for development 2) how can I build effective frontend 3) how to setup everything.
Won what?<p>For anyone who has been in web dev for long enough I can assure you there's nothing cleaner and more maintainable than avoiding CSS frameworks.
I used tailwind for several personal projects, then realized I was spending way more time than I used to styling things.<p>I switched back to bootstrap for personal projects, where I make a few tweaks to the global theme, then write zero css and very little styling besides things like margins and alignment. It's way easier and enjoyable for me, though I admit that my apps all look pretty generic.
It takes some time to get used to it (basically, memorizing most import class name schemes). But this is the first time I can open an old project I haven't seen for a year and directly start changing the styles of stuff without the fear of breaking anything or having to read into how the CSS is managed again.<p>I also like that it lets you build anything and does not have a default look.
Lol, who ever said it won? Paid HTML components? Get over yourself.<p>Heck people can even come together for a web framework let alone one tiny paid CSS tooling.
I feel most people who hate Tailwind never had to deal with the problems it is trying to solve.<p>It does things in a brain dead way to protect you from other people’s idea of cleverness.<p>Also in corporate settings apps and sites don’t follow sensible rules, you think you’re gonna have a few sensible classes for a few different components?<p>Well marketing decided that they need 50 small variations of just one component, of course it makes no sense to you, but that’s the requirement so shut up and do it.<p>If you’re not using Tailwind you end up with 50 exceptions and your normal CSS quickly becomes unmaintainable.<p>Tailwind is the mad solution perfectly suited for a mad world, and only people who hate it are those who don’t have to deal with madness.
I don't dislike Tailwind. I think it is a great tool if used correctly, but the majority of projects I've used it on, other devs eventually tend to overuse the @apply rule and end up just creating lots of custom classes. This literally defeats the entire purpose of Tailwind and I feel like that feature alone is what is most wrong about the library. If you're going to use their classes to write your own, you might as well write vanilla CSS. There's literally no upside to using Tailwind and it's actually a huge hindrance, as you now have to remember the rules of CSS plus all the Tailwind utility classes.
I strongly disagree with the <i>usage</i> of context-switch here. If you're writing HTML + CSS or writing HTML + Tailwind classes that's the same context. Maybe my experience with CSS is partly to blame - I can see a design and have both the HTML and CSS in my noodle at the same time because they are coupled. The phrase will lose all meaning if we're comfortable with, "Anytime I look at a different file" as a clean definition for context switching. So If I ctrl+click to read a function that I've imported or I'm checking out the type definitions for a parameter - <i>that's</i> context switching??<p>To me, this would be like saying writing a function in a React component and then writing the HTML for that same component is context switching. It just doesn't stand up to scrutiny. The tasks are related and in a similar headspace - even if they aren't connected 1:1.
Specific to the article:<p>> <i>Switching to a CSS file to change styles is a costly context switch</i><p>It is?! I have an IDE with more than one pane. CSS-in-JS exists if you <i>really</i> don't want to switch (albeit with its own problems)<p>> <i>you can just copy and paste a list of classes or an HTML block into your application</i><p>Well <i>back in my day</i> we called these "inline styles" and came with their own problems. CSS is copy-pastable as well, and easily composed with classes.<p>> <i>Compare this to [..] CSS build systems like Saas</i><p>Tailwind requires a build step! Frankly, I haven't seen a sizeable webapp without a "build step" for incorporating even plain CSS<p>> <i>The best way to write the least amount of CSS is to just compose basic styles</i><p>This feels like an argument <i>against</i> Tailwind? Utility classes are helpful but will never be enough to replace CSS entirely without <i>long</i> lists of classes on every element
CSS is moving so fast these days, can Tailwind keep up?<p>I see loads of comments in here using things like `.mb-sm-3` (I presume it's `margin-bottom: 3` for small screens?) as an example for how readable the classes are, but with CSS introducing logical properties I wonder if Tailwind's syntax needs to update to accommodate those changes? Using logical properties, this same example would render to `margin-block-end: 3` and already you're moving away from the easy-to-remember shorthand Tailwind created. If Tailwind's syntax needs to update, isn't that a pain in the ass to maintain?<p>This is just one example, but CSS is introducing loads of new stuff every few months it seems and I would hate to be limited by the constraints of a CSS library when browsers are capable of achieving so much these days. I enjoy learning CSS, not Tailwind.
In the start-up space, Tailwind is to product UI as Bootstrap was (or still is) to marketing-focused landing pages. It almost serves as a litmus test as to whether you work in a start-up like environment or an enterprise environment.<p>If you are in a design or product function in a enterprise company in non-tech industry, you steer clear from Tailwind. But, I appreciate its usefulness for developer's who just don't want to learn CSS or have the time to prioritise building their own design system — that comes with maturity.<p>In any case, Tailwind trades one CSS problem for another and it just illustrates that web development is not different than any other kind of development — it's all about managing compromises in technology and approach, based on your needs and future plans.
I don't get Tailwind. In my book, CSS is here to facilitate the style of multiple webpages by modifying a set of rules, and classes are here to mutualise said rules.<p>With Tailwind, it looks like you design by writing HTML, which is the opposite of what CSS aims at. So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.<p>Every time I've had to work with Tailwind, it felt like a chore and it was an unpleasant experience.
I wrote CSS from scratch since version one. I know why it's called cascading, I have used many preprocessors and generally don't mind writing CSS at all. That being said, all my attempts to modularize my stylesheets looked like a incomplete and buggy version of Tailwind. I could imagine that this is the reason why it's popular. Also people seem to always be ignoring the fact that you can just use tailwind to create helper classes. Nobody forces you to repeat common styles a million times.
Modern CSS has become so simple, thanks to @layer, Flex box, Grid, and it looks much nicer than Tailwind. And, most important, I do not have to learn it, I know it already.
I like Linaria [0] because your IDE typechecks your styles and gives you autocomplete/intellisense when typing styles. With Tailwind you have to look everything up in docs because it's all strings, not importable constants. Leads to a lot of bugs from typos that aren't a thing with type checked styles.<p>[0] <a href="https://github.com/callstack/linaria">https://github.com/callstack/linaria</a>
I see there is a lot of fair critiques about tailwind, many I agree with.<p>But as someone who works on UIs built with react, it's nice to not have then need to leave my JSX components - html, js, and css (via tailwind) are all nicely colocated. Especially nice with the vscode extension that shows the css rules of the underlying css decleration.<p>I agree that fundamentals trump all, but tailwind is a nice css abstraction that hits my use case well.
Tailwind usually makes more sense with React or some other component system. If you are not using components, Bootstrap might still be a reasonable choice.
I am a not-good-at-ui dev, meaning I _can_ build UIs pixel perfect if given some exact design files, but it is incredible hard for me to come up with things on my own. So whenever I build something that is not already defined fully by designers (like: most of the time), I have to use some UI component catalog like bootstrap and start assembling my UI based on the options there, at most I switch a theme file to something more fancy.<p>I basically was squarely the target group of bootstrap, and used it for lots of projects in all versions. I didn't actually care much about their technical progess (float, flex, css-grid, whatever), I just copypaste from the available widgets and add in my data.<p>Just LAST WEEK I learned that my favorite web framework (<a href="https://phoenixframework.org/" rel="nofollow noreferrer">https://phoenixframework.org/</a>) now ships with Tailwind preconfigured by default. I also heard good things about it from trusted colleagues. So, for the next big project I decided to jump in. Still I kind of have concerns: I need "typical components" like cards/tables/grid/... to be only a copypaste away; and I need to allow some designers be able to tweak the overall look and feel, roughly like a theming file where fonts/colors/... are defined at a single place. I hope it will be smooth after all these years of bootstrap and the "muscle memory" of how to compose pages with it.
Once again, the "write once lots of small websites" people and the "maintain huge web apps" people, will be talking past each other.<p>We share a base layer in HTML, CSS, JS, but the incentives, requirements, job environments, team sizes, couldn't be more different.<p>I wonder about other languages and ecosystems. What would be a similar situation for e.g. C? Is there such a thing?
I find it frustrating that web development moved away from encouraging developers to use a collection of consistent visual styles and basic components (like Bootstrap offered - and even Bootstrap itself is moving towards being a collection of utility classes).<p>It's very frustrating to have to make a lot of decisions around standard component styling on each new project.
You can just write your own styles and then use @apply <your Tailwind classes>; inside if you have the right tools. I am not sure what is this commotion about. I think that most of the critique comes from people who have never used tailwind before hence it looks foreign and grotesque to what they already know, i.e. CSS.
Yea Tailwind is so good. Yes you have to enter more class names into your html, but the payoff is you don't need to mess about with CSS at all unless you need something very specific.<p>It also makes it so much easer to progressively update things to a new design, without worrying about 1 change in a CSS file potentially having an effect anywhere.
Next up, improve usability and consistency with tailwind by making component classes via things like <a href="https://daisyui.com/" rel="nofollow noreferrer">https://daisyui.com/</a>.<p>Then you realize you can just use the classes with css and forgo the tailwind Middleware.<p>Then we'll be back where we started.
Relevant post from a Tailwind CSS endorser.<p><i>No, Utility Classes Aren't the Same As Inline Styles</i><p><a href="https://frontstuff.io/no-utility-classes-arent-the-same-as-inline-styles" rel="nofollow noreferrer">https://frontstuff.io/no-utility-classes-arent-the-same-as-i...</a>
Btw Tailwind isn’t a religion…if you don’t want to use it, that’s fine.<p>It has helped a lot of people - myself included - write more and better CSS but I don’t understand the vitriol here. If you want to write vanilla CSS or BEM or Sass or Less, I think that’s great.
I like using Tailwind. There's good reference online to help style pages. I usually find what I need, copy it, and it works most of the time. Since I don't know much about UI, Tailwind helps me get the job done.
I'm using Bootstrap in a Tailwind kind of way, with many utility classes. I don't use it's container system.<p>How do you get a basic Tailwind design running? It seems like you need a Bootstrap equivalent on it anyway.
People on HN (and elsewhere) said bootstrap was terrible when it was the most talked about CSS framework. Now it's tailwind.<p>The top comments will always be negative.<p>Don't give too much weight to this when choosing what tech to use.
For me it won because I view tailwind as vanilla CSS with a nicer syntax (mostly) and sane defaults that makes your website look decent out of the box. With the prettier autosorting plugin, the classes are ordered in a predictable fashion, making it easier to read than one would imagine.<p>It's not a perfect replacement for vanilla CSS and I still fall back down to writing plain old CSS for stuff like box shadows or more interesting grid layouts, and using tailwind modifiers like different screen sizes is less than ideal with having to prefix every single CSS property with the same modifier.
it won because of the disrespect of frontend in the industry,
because people seem to think it's ok if backend engineers write garbage frontend code
if your main argument is that the value tailwind is something you couldn't do with "style" or inline attributes you've missed the point entirely.<p>only thing worse than a comment made out of ignorance is one with that additional amount of hubris attached. this point somehow seems to always float to the top of every tailwind post. not surprising to see it as the top comment.
I don't think the last word has been spoken yet.<p>It's true that, as the OP claims, many developers are not writing HTML/CSS, they are writing JSX (or similar) so maintaining a separate CSS file is a context switch. Point taken, and well made. Also, the original HTML/CSS split made more sense when one was writing documents, not applications, and the author and designer/typesetter were separate people.<p>However, svelte (my current favourite framework) gives you the option of putting a CSS block in a component source file, which is compiled to be local to the component. For example if you put "h1 { color: red }" in a <Warning> component, then effectively what you get is some kind of "h1.warning" rule. It just works in the background how you expect it to, doesn't interfere with anything else, and you don't have the context-switching overhead of separate files.<p>I know that svelte has a lower market share than some, and of course you can use tailwind together with svelte, but the claim that "writing CSS = switching files" is only true within the scope of e.g. React, not in general.