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
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.
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.
Just LAST WEEK I learned that my favorite web framework (https://phoenixframework.org/) 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.
At the beginning, it's going to feel like a drop in velocity. If you only copy and paste raw code and do not make components, then it will feel like a lot of work to change the accent color from blue to yellow (unless you're really good with regex).
If you want a more Bootstrap like experience, look into something like DaisyUI. It gives you a high level primitive similar to Bootstrap, but built on the philosophy of Tailwind in regards to ultimate customization using utilities.
If/when you get more comfortable with the tailwind primitives, you can easily make your own component abstractions that work for your needs.
I made a Chrome extension called SnipCSS that is made for not-good-at-ui devs.
Instead of using a framework, I just rip other sections of website designs I like using my tool. The paid version even scopes the snippet and gets all responsive styles.
Theming abilities are on the roadmap and with AI being able to adjust my snippets eventually - I really don’t see the need for extremely verbose frameworks like Tailwind. But I could be wrong, I’m probably biased after having worked on it for a couple years.
This is only 1 perspective (which is correct in most cases but not always).
It can also produce massive HTML (not CSS) making it worse than pure CSS solution.
Even when used as expected, per-page, you end up with unnecessary html and css, because tailwind can't combine the classes used from other pages. For one to be able to use tailwind as efficiently as site-covering custom made CSS, you'd need to collect the HTML or CSS Classes for the whole site and compile the CSS from that, but tailwind is waaay too slow for that to even work - not to mention, node.js can't even handle that amount of classes in memory (4GB Default).
I'm very well aware of this because I tried to make it as efficient as possible.
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.
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.
The "default" (no css) look of HTML pages with black on white Serif text with default paddings / margins / spacing...must also have been picked at the time to make web pages look pretty (in a generic sense) out of the box? Just that we have now evolved in our sense of visual design tastes / whats possible has changed over the decades, maybe.
There is a persistent misconception that Tailwind competes with Bootstrap, but they just exist at different levels. Bootstrap provides components, but Tailwind is just a faster way to write CSS.
Components are just one part of Bootstrap nowadays, it also has helpers/utilities, the (css) grid system and flex, themes (light/dark) support w/ css vars.
Probably not granular enough for Tailwind fans though.
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.
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.
Every time I've had to work with Tailwind, it felt like a chore and it was an unpleasant experience.
In a recent thread someone explained Tailwind was best used with component frameworks, and that made it make a lot more sense and I could see the appeal.
It’s actually one less layer. My layout and styling are finally together, and well documented. I don’t mean in the same file like a .vue file. I mean they are TOGETHER.
> if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.
this comes up on every tailwind post and it isn't true. tailwind encourages you to not repeat yourself by making reusable components (or fragments etc) instead of reusable classes. that way if I want to see how the button both looks and works I only have one place to look
even if you don't do this, with tailwind you encode your design system (colours, spacing) etc in the config file so even copy pasting everything will get you something consistent
I don't feel this point is strong because when you look at some of the most popular Tailwind components or templates in the ecosystem, such as the one made by the Tailwind people, the Tailwind code is still pretty crazy.
I think your last point has legs, for sure. It makes sense that some other language will compile to wasm and make some app development more straightforward, but I don’t think the end result will be that different.
The web platform is not going to move away from current paradigm without an overwhelming shift in priorities or needs. Wasm still generates html and outputs it on the screen.
My biggest reason to use tailwind is maintainability. Having everything right in front of me with only the tiniest of abstractions, makes it really simple to refactor and maintain. I can confidently delete “CSS” and know it has no side effects. I can cut and paste a block of html and it will render EXACTLY the same. I don’t have to worry that Steve used a generic sibling selector in a CSS file 3 years ago that is screwing with my layout/design.
Is the HTML more bloated than if I had written “normal” css? Yes, but I think it’s worth the trade-off. It’s important that we can agree that their are trade-offs and then it’s up to each project to decide if those are worth it for their use case.
I’ll also mention the actual CSS file is crazy small as well since the tool only generates classes that are actually used in your project. No more ever-growing css that other people are afraid to delete for fear of breaking some legacy page!
> Wasm still generates html and outputs it on the screen
Sure it can. More usefully to my point though, it can also use any of a number of C++/Rust/etc. UI libraries to render directly to a buffer or canvas, which is in my opinion a better long term solution for true applications (vs websites).
When you do that you get total layout control with no need for CSS or worrying about browser defaults.
As a random example here is the Rust egui library demo app running in a browser using WASM (no HTML): https://www.egui.rs/#demo
The speed and “native application” feel are hard to replicate in JS/HTML, as they are just not great tools for the job or rich desktop (or desktop-like) applications.
In my understanding it somehow abstracts the process of styling a website or whatever and make it easy for people who for any reason don't want to write CSS.
Although I have the sensation many people find hard to write CSS and even despise it (I've read people here in HN who seem to think we should've kept doing layouts with HTML tables and don't agree layout is the job of CSS!) I definitely agree having dozens of classes in your HTML is messy and weird.
It’s all stuffed in classes because that’s the limitation given and this information belongs in the markup.
The above is much cleaner to me than: div.class(“primary”). I need to go find primary. What is the parent class. What happens if this isn’t a div now etc. what happens if the parent isn’t a div?
Tailwind just spells it out for you right alongside the layout so that you have all the information in one place.
For me personally, I was able to do things in tailwind I could never do in raw css, but I bet I got better at css as a result.
The docs are also incredible for tailwind. As good as mdn is, you need to already know what you’re looking for.
It's much easier in Tailwind for me to see locally what's going on with that styling. If I lived in this code all the time, or I was good at structuring CSS, then maybe the first would be more appealing. But I'm a shit at CSS, it always turns into an unmaintainable mess, and I look after a lot of different projects that I might not touch for 6 months. So Tailwind's approach is easier for me.
Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.
> Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.
Why copy the attributes? Just override the one you want to change. You can even use style="…" if you're sure that it's just one link.
In tailwind you'd probably use a named color such as `primary` or `border-primary` or something like that, so you still have the ability to change it in one place. I don't really like tailwind myself, but I don't think that's an issue
1. Given the example actually provided here, do you see an opportunity to do that?
2. Suppose you change the example to use named colors. Where does this name-to-color-value mapping live?
****
> I've noticed that moving the goalposts is extremely prevalent on HN, which makes for pretty frustrating conversations (or just reading). And then sometimes it's a tag team. E.g.:
> Person A writes their comment. Person B1 offers a rebuttal. Personal A offers their response. Person B2 offers a second rebuttal that abandons the premise behind B1's rebuttal, and may actually be at odds with it. Person A ends up either deflated or looking defeated.
> It's like the cross product of a Gish gallop and a DDoS.
One example is if I was using react it would be used to encapsulate a react-router Link and an anchor tag in a component, and use props to differentiate between inbound and outbound links.
In React at least, often you can live with One Component = One File at least for simple components. Adding separate CSS files, as the OP says, causes context-switching.
This is not true in svelte, where a component file can have both a root tag for the component, and a <style> tag that the framework/compiler automatically scopes to this component (and a <script> tag for the code, since you don't have the JSX inversion-of-control principle).
You can utilize the Functional CSS approach to eliminate the redundancy of architecture and behavior across various instances (JSX and CSS). Furthermore, it offers superior performance when compared to OOCSS.
As stated elsewhere, if you're using a component based UI, this isn't a problem. You're also free to mix regular CSS with Tailwind.
As for the "git gud" school of CSS, should we also abandon React, Svelte and the like and revert to hand-cranking DOM manipulation like it's 1999...?
Sure, if you're manually editing a large volume of .html by hand, Tailwind is bad news, but given the plethora of static site builders out there (brief shout out to Astro which is excellent), manually authoring individual .html pages seems like masochism.
Sounds like a boring Friday afternoon job, or something I could give to a junior contractor. It's also something that doesn't happen very often on the kinds of projects I'm working on.
That misses the point. This is still worse than seeing all your styles in the place where they apply. SASS/LESS just make it faster and more succinct to write styles in css files rather than in the components in which they live and even more importantly—on the actual ELEMENTS that they apply to.
The tailwind version is actually horrible, don't do this: you are supposed to style all the links in the same way, as with the css example, not style each link in it's own way; or you will get a link red, another one blue, another one yellow, and your ux will be crappy and your code unmaintainable
Horrible.... for you. For me, it's lovely. My UI productivity and satisfaction has massively increased with Tailwind, and I've been using it for 3 years now.
That isn’t a Tailwind feature though? That’s been like a basic feature of CSS frameworks for 10+ years. Even Bootstrap was going this route way back when.
Who rolls the basic boring CSS classes like border-red or border-primary by themselves? People have been doing it for free for over a decade.
My solutions to the problems you raise, in order of preference:
1. Not worry about it, it probably won't happen on the projects I'm working on. YAGNI.
2. OK, it's happened. Get some coffee, make all the changes. Can I use a regex? Make the changes incrementally? Delegate it to a junior?
3. This is going to change a lot. Let's make a re-usable component, a named colour like 'primary' (in Tailwind config), or re-usable class like .button-default. The right solution will depend on the requirement.
In styling, I'd rather have 1000 obvious changes than 1 difficult one. The risk of having the wrong shade of red is not high enough for me to worry about abstracting it.
I appreciate that good, full-time CSS devs have much better solutions for this, but those solutions involve being good at CSS as a starting point. I don't have that luxury.
I think the framework is meant to be used by other frameworks and not by humans.
It is an unpleasant chore if you use it by hand and I have given up on it but I can see that if it's just used in components and then html is not written by hand but made dynamically it could work better.
It's basically a CSS framework for JS frameworks and not for writing HTML.
> So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule.
Changing the CSS to apply site-wide changes sounds great in theory but after working in front-end since IE6, this almost never happens in practice. You're never certain how the styles cascade and indirectly affect things so you're afraid of changing the core CSS.
Styles isolated to components is a much more scalable approach in my opinion and then it doesn't really matter whether you use Tailwind, CSS-in-JS or scoped CSS (Vue etc).
Its hard keeping track of different usernames on here.
From my perspective, "almost never" and "won't actually happen" aren't that different. Both indicate that the probability of success is very low. It seems to be, if the probability is already really low, is not worth extending effort maintaining it.
Let's solve that by switching to a different abstraction that proves to be more useful. In this case, isolation-by-component instead of isolation-by-class.
I'm not the person you're replying to, but I'm in a similar position, and while I'm not in love with Tailwind*, it's successful because it's oriented around components rather than classes. In every project I've worked on, it has been far easier to manage the complexity of components over classes, because components link style and structure together, which usually end up very tightly coupled anyway. This limits the scope of the CSS you're writing a lot, making it a lot simpler to understand what any individual declaration is going to do - you know exactly where it's being used, you know exactly the HTML structure it's operating on, you can see exactly what it will do as a result.
* I use it a lot at work because it's very easy to get something written, but I find the pseudo-CSS DSL irritating if I need to write more complex queries. Something like CSS modules requires a bit more boilerplate to use, but you end up writing real CSS queries, which I find more natural. But this is personal preference.
I do use tailwind and I find it terribly convenient for some things, but this argument still seems to mostly stem from too many people doing css who are not great at designing css and are doing things they really should not.
How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes? Of course I can then build more solutions around that. Or I can accept that good css design is hard, just like any good software design is hard.
> You're never certain how the styles cascade and indirectly affect things
Then your DOM is too complex. You're formatting a text document; that shouldn't get you in a position where you lose track of what cascades where. If it is you have a bigger problem than styling.
I agree with you. As a developer I like the separation of style and content. We also gain better readability when the code says "<div class="product-price">199</div>" than a long list of tailwind classes.
CSS styles are also more reusable across different web sites. I can to some degree see that you can increase re-usability when using shared React components, but then you just create technical debt for those who want to test other frameworks
It seems to me that Tailwind is only a semi-scalable solution for those who use React components or similar. But as mentioned above, that causes problems when you want to make other webapps in another framework
As soon as you have recurring product prices, you’re encouraged to use @apply to group those classes. In practice, however, you’re using components of some sort anyway, whether in Frontend or backend code, so this isn’t really an issue.
It’s a completely viable solution for certain situations, say, having a .button class. The things mentioned in that twitter thread have nothing to do with that.
I was commenting on "As soon as you have recurring product prices, you’re encouraged to use @apply to group those classes. ". It's certainly technically possible to create a CSS class. But AFAIK the recommendation is loudly and clearly to use components https://tailwindcss.com/docs/reusing-styles#extracting-compo..., and for good reason.
I follow, but even that part of the docs acknowledges the use cases solved by @apply. No denying it’s a powerful gun to shoot your foot with, but it has its merits. Especially in the OPs context of some bespoke e-commerce CMS, which might not even have a frontend pipeline more sophisticated than grunt or something.
Can you explain something about why you prefer the separation of style and content? From my perspective all that it accomplished is making me modify two files (html template and CSS) instead of one.
There are several advantages of separating CSS and code from my point of view.
- I generally dislike inline CSS styles, and the benefits of Tailwind is not enough to overcome that.
- Reusability across systems. At least in mature businesses, they often have CMS systems, different frameworks etc. Using Tailwind kind of encourages everyone to use the same internal React component library.
- Easier to read PR and git logs. Adding a single tailwind class to a component may mark the entire line as changed, and you need to figure out what has changed (including checking the code, because you don't know if that also changed).
- Designers can make changes in CSS without having to learn React.
For getting designs up and running quickly, it really is great.
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.
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.
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.
So I still have to componentize my presentation layers to do tailwind "correctly", but instead of writing CSS in readable multiline chunks in a language every developer already knows, I need to use this cryptic one liner in any order that literally nobody can read?
What in the hell is wrong with this industry? Sometimes clever ideas aren't all that clever. Sometimes they're just dumb.
This might surprise you but most industry web development today is using components powered by a framework, and Tailwind fits in perfectly to the close coupling of styles to components.
But in components with scoped styling, you're better off just using css directly. Create a class that has all the styles you want, then use it in the HTML - nicely and cleanly separates css and HTML code.
Because they're not both style info? Html is a markup language, it applies semantic structure to your content, CSS styles html.
Classes are a tool for selecting markup to style. Sure, you can create a class for every single CSS rule you write, but just because you can doesn't mean you should.
In that case you end up with fifteen different variations of that button, class names like "button-cta__hero__overlay" and a smattering of !importants to defeat the cascade you can't chase down
CSS classes are great for that until you need to reuse HTML and/or JS, at which point you're back to square one. People are moving to components because they solve these 3 things at once.
> 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.
I'm not a frontend developer and don't really know much about these frameworks, but how is this different from just using style="actual css"? This just feels like inline styles reinvented for whatever reason.
Yes it's like inline styling, but the difference is that with Tailwind your build has just 1 CSS class with { display: flex; } used across your HTML, rather than inline styling or decoupled stylesheets with hundreds of instances of {display: flex}. If you use a framework like React, Angular, Svelte, it makes sense because your styles are usually coupled to your components anyway.
Also speaking from experience — you have to have a lot of bespoke CSS and virtually no design system / internal consistency to run into that limit (a.k.a the Movember 2013 brand refresh).
And finally, when you did run into the IE selector limit, you could just split the style sheet in two (fairly trivial if you were using Sass), because the selector limit was per stylesheet.
With inline styles you can’t do media queries (e.g., so your site can look good on both phones and desktops) or pseudo selectors (e.g. :hover).
Also, though it’s lower-level than something like bootstrap, it does have a design system. Bootstrap is like building a model from a kit, plain css is like building a model from scratch, and tailwindcss is like building a model from lego.
It's exactly the same but denser. There's no benefit that Tailwind brings that you can't get from writing your own cleaner CSS files. It's like a cult.
Styles? Doubtful. Naming components? We have to do that anyway with how JavaScript/TypeScript frameworks work these days. Tailwind is a different way of doing it that introduces unnecessary abstractions. To me, that makes it worse than writing vanilla CSS. With CSS you don't have additional dependencies and build processes. It's just CSS.
Personal choice obviously, but I work with frameworks and components if I'm doing frontend stuff, so having things as a single name for something that is consistent across everywhere I use it makes it easier for me.
I think Tailwind is more accessible to many[*] less experienced or CSS-oriented developers. Big generalisation, I know, please don't yell at me, but many of us can get 99% of Tailwind's value with UI libraries supporting:
1) style encapsulation,
2) colocated presentation/content/behaviour and
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).
[*] 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.
What's up with the colocation argument? Colocation of markup and business logic makes a lot of sense.
Colocation of presentation? Why do you even need that? Presentation is abstracted into CSS by design.
Having presentation decoupled allows you to abstract around visual elements on a page at their instead of having to sufficiently wrap everything in divs classes just to the right level to make the CSs classes work.
Your overall structure is going to be vastly different whether you use flex or grid. And if you don’t want to write overly clever CSS you’re wrapping your dt/dd pairs in divs or you put dummy elements into your sections to control where the anchor links scroll to etc. And don’t get me started on non-hierarchical layout relationships.
HTML is not flexible enough and CSS is not expressive enough for this theoretical separation to hold in practice. You would need a translation layer between pure content and layout for this to be true (like XSLT).
I never suggested decoupling html and CSS, that is always going to be coupled through selectors.
What I suggested was decoupling presentation (actual CSS rules) from structure, the blocks of html.
What I'm discussing here is if CSS rules should be inlined in html, whether through tailwind pseudo css or style tags the result is the same.
Further caveat, the article mentions that switching to a CSS file is a context switch. Put it in a style tags next to your html for all I care, colocation is great as a general rule, inlining CSS in html style attributes is not.
This is settled thinking at this point: inlining CSS results in short term benefits to productivity at the cost of long term costs due to brittle presentation that is expensive to change.
And given how low the cost of extracting reusable css classes is these days, I don't think tailwind will ever win.
Yes, it defines the structural bounds your CSS is able to manipulate. It doesn't dictate how it needs to be manipulated other than a rough idea about what things will render out in what order. (I'd hardly call that presentation)
The key point here is that CSS exists precisely because html markup isn't enough on its own to style itself. If it was, CSS wouldn't exist.
The idea that something like tailwind can come in with a bunch of fine grained CSS classes and solve this inate complexity is laughable at best and wildly unprofessional at worst.
It just shows a complete lack of understanding about what html is and isn't and why CSS even exists in the first place.
Fwiw, I get it. Tailwind is a neat shorthand script you can use to pump out trash you'll never look at again. For the rest of us doing actual work on things that we'll need to modify 6 months from now I'd much prefer something readable that I can actually have a hope of modifying even if a teammate wrote the thing.
I believe I'm convinced that if an abstraction is leaky then it's garbage.
For instance, if I really needed to know say, jvm assembler to code Java then Java would be garbage as an abstraction layer because it would simply be creating problems where they need not be.
Java however is clean, which makes it useful. I don't need to know the next level down. C is clean. JavaScript is. PHP is.
Tailwind is not. Many frameworks are not. They promise benefits but deliver complexity and programmers get invested into the system and then can't see the reality because it's a classic cult effect of giving emotional salience to a lie.
Eventually it collapses and a new one is formed.
And for some unknown reason, this. Shit. Does. Not. Stop.
It's really exhausting. Been programming nearly 30 years. So sick of it.
It would be like if I did say medicine and every 3 months or so the medical community started tripping over itself by believing in the latest weird quack with orgone energies and magnets and started writing prescriptions to their patients about chakras or astrology and then being shocked, like actually genuinely surprised when it all collapses.
Why do people run around like a bunch of frenetic teenagers to manufactured hype cycles in programming? Can we please fucking stop. Honestly.
I don't view Tailwind as an "abstraction" in the same way that you might say Java is an abstraction over the JVM. If I'm writing Java then I'm only thinking about how Java works, not about the implementation details of the JVM. But when I write Tailwind I'm still very much thinking about the underlying CSS properties. Tailwind just gives me a much more convenient way to add the CSS styles that I already know, with significant reduction to my mental overhead.
It hadn't occurred to me that people might be learning Tailwind as if it's a replacement for having to learn or understand CSS. If you treat it that way then you're bound to have a bad time, much like people who treat git as a series of commands to be memorised without any understanding of git's underlying data model.
I'll also admit that I've only ever used Tailwind on small-to-medium sized solo projects, so I don't know how it would hold up on a big team. But then the CSS has been an agonising, unmaintainable mess on every big collaborative project I've ever worked on even without Tailwind, so what is there to lose?
> But then the CSS has been an agonising, unmaintainable mess on every big collaborative project I've ever worked on
That's the other thing, tools are a really poor shortcut to competency and in practice just reflect the same level of mastery that caused the initial headache except with a different set of tools.
This isn't pure. Some things are genuinely less insane than others.
As an analogy, higher quality brushes, paint and canvases will make you a better painter but buying new brushes isn't going to be part of becoming the next Monet. Consumption isn't going to get you there.
The real competency as you point out, come at higher level coherency, which frankly takes about 5-10 years to get any good at. It's a cognitive mastery that's mostly independent of tools.
People want to seek out better tools as a proxy for the hard earned talent. It might get you further but at some point, knowing what you're doing is the only way to go.
It sucks. It's hard. It's frustrating. It's always changing and it's also unavoidable.
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.
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.
>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.
Don't you just have to worry about making sure your update is propagated to all the right class lists? Seems like trading one medium problem for 30 small ones.
Well for example if you have a style on anchors on a site. If you update the general style (even it its in a class) you have to worry about everywhere that thing is used and whether it will break it. They are all completely coupled.
I mean there are techniques to avoid that like BEM and co, but they rely on you and your colleagues following them, and in my experience are a huge ballache.
Its also sometimes hard to track styling issues down, looking through all of the properties etc. And if you get into SCSS and mixins it slowly gets out of control.
On the flip site with Tailwind, it's all there in front if you and easy to change. If you need to repeat something often, you can just create components / partials with reusable parts.
You really don't have to do that. It is a pseudo-problem. Specificity and flexibility can also be managed easily in CSS only. Without naming everything. Linting can be used to enforce real good practices. Without any overhead costs.
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.
* 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.
* The fact that you can see immediately how an element is styled. No hidden, detached or indirect styling whatsoever.
Surprised to see your comment as the only one mentioning these points. Not having to make up class names (and groups of class names – ”-container”, ”-inner”, anyone?) that are anyway only used once is the greatest liberation I’ve had in my 20+ years of web development.
For styles that are reused a lot I just create small & composable components (which are also defined by the Tailwind classes so they match distances & colors). But there are typically just a handful of these in a project.
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.
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"`:
These refer to customizable variables and breakpoints that everyone using the library and having done css would know and you can probably click on your IDE to get to their definition.
Personally I think that's way better than putting padding & margin in your own css classes.
It actually cuts down a lot on the custom css you need to write and also helps having a uniform design.
You're just using someone else's padding and margin classes. At least when you write your own it makes sense instead of Tailwind's alphabet soup bloat.
This is exactly the problem. Humans write code for humans, not for tailwind specialists and bots. It should be clear and easy to read unless there is a valid reason for weird code (optimisations, hacks that don't work otherwise etc). Tailwind introduces yet another convention where it is absolutely pointless to do so.
But isn’t BEM or a custom system of CSS variables strictly worse in this regard? Instead of knowing what class=“mb-4” means in Tailwind, they now need to know what class=“news-button” means in your specific application.
I already know CSS, I don't want to learn another convention. I've learned Bootstrap, Tailwind, Foundation, Tachyons, Chakra, Bourbon...at each moment in time they were to be the "last" new CSS library we'd ever use.
How many components in your application actually need the exact same layout tweaks in every use instance?
There are some properties of CSS that are more static across screen sizes. Colors, borders, backgrounds, font-size (debatable!), animations, and maybe even some high level layouts (12 column grid, etc).
The rest of CSS is minute positioning via padding, margins, and widths. Often you need to customize those details to use slightly different values dependent on context within the application itself. This is where utility classes shine.
You absolutely don't have to name everything in CSS. Naming components is sufficient. And you already need to do that. Using good HTML markup provides you with 80% of the styling hooks you need in a component. Specificity management and flexibility can be baked in too.
As for the media queries being hard/tiresome to write, don't we have IDE auto-completion for this exact purpose?
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.
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.
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.
Purely from experience — largely, design system or development projects at large organisations are lead from a PMO, design or product teams — with technology often seen as down-stream (at least, in terms of development, there is of course technology architecture/advisory along the way.)
That means that the design/product requirements come first. The moment Tailwind's limitations meet design requirements, it'll take a back-seat.
It's basically the same reaction you'd encounter from saying "we'll build it in Bootstrap." If a company is investing in a new product or service, no one wants to be the guy that says "sorry our framework won't let us do that design" — at least, not in first year or two of a product life-cycle.
Tailwind's advantage — speed and accessibility for a range of developer backgrounds — isn't the same priority for large organisations vs. startups.
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.
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.
But this is how all victories work, whether it's a war or a sports competition or market share. You get to be the undisputed champion for a while, until eventually someone else comes along and beats you, or circumstances change so that your victory doesn't matter so much any more. "But Tailwind was only the dominant CSS framework for most of a decade" is not much of a criticism.
That is the point. Tailwind is just CSS. And like the article says, you can copy paste designs from examples.
The key difference between Bootstrap and Tailwind is that Tailwind designs are distributed. So Bootstrap designs feel like Bootstrap designs, while for Tailwind you can keep having new and fresh designs from different sources.
Well also bootstrap "died" in the most honorable way possible, it got antiquated by the CSS standard implementing flex and grids (the original specification was based on XUL though and not bootstrap - https://medium.com/@BennyOgidan/history-of-css-grid-and-css-...)
Kind of the same with jquery (although it took quite a lot of new stuff...)
Yeah the Bootstrap story is hardly one of the frontend world changing tastes, it was the standard forever and everything else at the time was copying it. Some key fundamentals of how CSS is written in the 2020s changed quite a bit as did how people wrote HTML (as the author alludes to using smaller component UIs with build systems replaced big HTML files and big CSS files). It was good time for a rethink IMO.
Components UI systems are not going away, even as we move back to static heavy sites and minimizing JS where ever possible.
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.
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.
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.
Hard disagree. As a web developer who has to work with the CSS monster daily, having to memorize property names between CSS versions would be a particular kind of nightmare.
558 comments
[ 5.5 ms ] story [ 321 ms ] threadThere 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
https://npmtrends.com/sass-vs-tailwindcss
> It replaces a generation of sites built with Twitter Bootstrap.
Jquery was handling element selection, manipulation, behaviors, futures/promises, ajax calls etc.
Somebody came along in each of those categories and “specialized” such that jquery was left as the bloated old choice.
Bootstrap was awesome, but as component based libraries like react/vue etc came around, I don’t need component level css helpers as much.
And then tailwind helped fill in the gap of being quite a bit more explicit and granular.
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.
Just LAST WEEK I learned that my favorite web framework (https://phoenixframework.org/) 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.
If you want a more Bootstrap like experience, look into something like DaisyUI. It gives you a high level primitive similar to Bootstrap, but built on the philosophy of Tailwind in regards to ultimate customization using utilities.
If/when you get more comfortable with the tailwind primitives, you can easily make your own component abstractions that work for your needs.
Instead of using a framework, I just rip other sections of website designs I like using my tool. The paid version even scopes the snippet and gets all responsive styles.
Theming abilities are on the roadmap and with AI being able to adjust my snippets eventually - I really don’t see the need for extremely verbose frameworks like Tailwind. But I could be wrong, I’m probably biased after having worked on it for a couple years.
I'm very well aware of this because I tried to make it as efficient as possible.
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.
My experience is that this is only true your CSS is written by a one man army.
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.
The "default" (no css) look of HTML pages with black on white Serif text with default paddings / margins / spacing...must also have been picked at the time to make web pages look pretty (in a generic sense) out of the box? Just that we have now evolved in our sense of visual design tastes / whats possible has changed over the decades, maybe.
CSS + Tailwind will be my go-to stack for all my new projects.
How do you get a basic Tailwind design running? It seems like you need a Bootstrap equivalent on it anyway.
Probably not granular enough for Tailwind fans though.
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.
Every time I've had to work with Tailwind, it felt like a chore and it was an unpleasant experience.
You can use Tailwind on top level and it is easy. But as soon as you have complex components with sub-elements, the styling gets really complicated.
It was easier to add component specific classes and define the css within the component. You call then the component with the classname.
this comes up on every tailwind post and it isn't true. tailwind encourages you to not repeat yourself by making reusable components (or fragments etc) instead of reusable classes. that way if I want to see how the button both looks and works I only have one place to look
even if you don't do this, with tailwind you encode your design system (colours, spacing) etc in the config file so even copy pasting everything will get you something consistent
https://tailwindcss.com/docs/utility-first#maintainability-c...
The rendered output is crazy, yes. But this argument applies to every JS framework ever created.
Authoring the code is best encapsulated by components. If you look at the source files available for their paid templates, they are all componentized.
Maybe the issue is that the giant pile of JS mess has created such a disaster that adding Tailwind doesn’t feel like making anything much worse.
I can buy that.
For what HTML is for (documents, web pages, etc.) CSS makes sense and Tailwind seems crazy.
If you’re trying to code an application, for now perhaps React + Tailwind and a mountain of NPM dependencies does actually make sense.
Really I think going back to application coding via something like WASM surely has to replace all that though.
The web platform is not going to move away from current paradigm without an overwhelming shift in priorities or needs. Wasm still generates html and outputs it on the screen.
My biggest reason to use tailwind is maintainability. Having everything right in front of me with only the tiniest of abstractions, makes it really simple to refactor and maintain. I can confidently delete “CSS” and know it has no side effects. I can cut and paste a block of html and it will render EXACTLY the same. I don’t have to worry that Steve used a generic sibling selector in a CSS file 3 years ago that is screwing with my layout/design.
Is the HTML more bloated than if I had written “normal” css? Yes, but I think it’s worth the trade-off. It’s important that we can agree that their are trade-offs and then it’s up to each project to decide if those are worth it for their use case.
I’ll also mention the actual CSS file is crazy small as well since the tool only generates classes that are actually used in your project. No more ever-growing css that other people are afraid to delete for fear of breaking some legacy page!
Sure it can. More usefully to my point though, it can also use any of a number of C++/Rust/etc. UI libraries to render directly to a buffer or canvas, which is in my opinion a better long term solution for true applications (vs websites).
When you do that you get total layout control with no need for CSS or worrying about browser defaults.
As a random example here is the Rust egui library demo app running in a browser using WASM (no HTML): https://www.egui.rs/#demo
The speed and “native application” feel are hard to replicate in JS/HTML, as they are just not great tools for the job or rich desktop (or desktop-like) applications.
Although I have the sensation many people find hard to write CSS and even despise it (I've read people here in HN who seem to think we should've kept doing layouts with HTML tables and don't agree layout is the job of CSS!) I definitely agree having dozens of classes in your HTML is messy and weird.
div.height(maxVH).color(primary).hide()
It’s all stuffed in classes because that’s the limitation given and this information belongs in the markup.
The above is much cleaner to me than: div.class(“primary”). I need to go find primary. What is the parent class. What happens if this isn’t a div now etc. what happens if the parent isn’t a div?
Tailwind just spells it out for you right alongside the layout so that you have all the information in one place.
For me personally, I was able to do things in tailwind I could never do in raw css, but I bet I got better at css as a result.
The docs are also incredible for tailwind. As good as mdn is, you need to already know what you’re looking for.
Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.
Brittle.
> Suppose we want to change just one link? Would it be better to make a new class with all the same attributes except the color and apply that to the specific link.
Why copy the attributes? Just override the one you want to change. You can even use style="…" if you're sure that it's just one link.
2. Suppose you change the example to use named colors. Where does this name-to-color-value mapping live?
****
> I've noticed that moving the goalposts is extremely prevalent on HN, which makes for pretty frustrating conversations (or just reading). And then sometimes it's a tag team. E.g.:
> Person A writes their comment. Person B1 offers a rebuttal. Personal A offers their response. Person B2 offers a second rebuttal that abandons the premise behind B1's rebuttal, and may actually be at odds with it. Person A ends up either deflated or looking defeated.
> It's like the cross product of a Gish gallop and a DDoS.
<https://news.ycombinator.com/item?id=23117242>
Then again if your styles are abstracted to a component, your CSS framework is irrelevant!
Maybe it's some sort of lock-in feature.
This is not true in svelte, where a component file can have both a root tag for the component, and a <style> tag that the framework/compiler automatically scopes to this component (and a <script> tag for the code, since you don't have the JSX inversion-of-control principle).
In practice however I see a lot of copy paste in tailwind html so it doesn't work quite as well in reality.
As for the "git gud" school of CSS, should we also abandon React, Svelte and the like and revert to hand-cranking DOM manipulation like it's 1999...?
Sure, if you're manually editing a large volume of .html by hand, Tailwind is bad news, but given the plethora of static site builders out there (brief shout out to Astro which is excellent), manually authoring individual .html pages seems like masochism.
```
```https://webkit.org/blog/13813/try-css-nesting-today-in-safar...
Who rolls the basic boring CSS classes like border-red or border-primary by themselves? People have been doing it for free for over a decade.
And when the designer change his mind and border-red should not be used anymore?
And what if you have small changes, e.g.
```
<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">Button 1</button>
<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-3 px-4 rounded">Button 2</button>
```
1. Not worry about it, it probably won't happen on the projects I'm working on. YAGNI.
2. OK, it's happened. Get some coffee, make all the changes. Can I use a regex? Make the changes incrementally? Delegate it to a junior?
3. This is going to change a lot. Let's make a re-usable component, a named colour like 'primary' (in Tailwind config), or re-usable class like .button-default. The right solution will depend on the requirement.
In styling, I'd rather have 1000 obvious changes than 1 difficult one. The risk of having the wrong shade of red is not high enough for me to worry about abstracting it.
I appreciate that good, full-time CSS devs have much better solutions for this, but those solutions involve being good at CSS as a starting point. I don't have that luxury.
It is an unpleasant chore if you use it by hand and I have given up on it but I can see that if it's just used in components and then html is not written by hand but made dynamically it could work better.
It's basically a CSS framework for JS frameworks and not for writing HTML.
Changing the CSS to apply site-wide changes sounds great in theory but after working in front-end since IE6, this almost never happens in practice. You're never certain how the styles cascade and indirectly affect things so you're afraid of changing the core CSS.
Styles isolated to components is a much more scalable approach in my opinion and then it doesn't really matter whether you use Tailwind, CSS-in-JS or scoped CSS (Vue etc).
…so let's solve that by making it completely never happen?
From my perspective, "almost never" and "won't actually happen" aren't that different. Both indicate that the probability of success is very low. It seems to be, if the probability is already really low, is not worth extending effort maintaining it.
I'm not the person you're replying to, but I'm in a similar position, and while I'm not in love with Tailwind*, it's successful because it's oriented around components rather than classes. In every project I've worked on, it has been far easier to manage the complexity of components over classes, because components link style and structure together, which usually end up very tightly coupled anyway. This limits the scope of the CSS you're writing a lot, making it a lot simpler to understand what any individual declaration is going to do - you know exactly where it's being used, you know exactly the HTML structure it's operating on, you can see exactly what it will do as a result.
* I use it a lot at work because it's very easy to get something written, but I find the pseudo-CSS DSL irritating if I need to write more complex queries. Something like CSS modules requires a bit more boilerplate to use, but you end up writing real CSS queries, which I find more natural. But this is personal preference.
How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes? Of course I can then build more solutions around that. Or I can accept that good css design is hard, just like any good software design is hard.
How will you track that in `.hero-text__sticky-container--primary` vs `.text-with-image__card-primary`?
And then it's still hard, because good css design is hard. Tailwind is not making that easier.
Then your DOM is too complex. You're formatting a text document; that shouldn't get you in a position where you lose track of what cascades where. If it is you have a bigger problem than styling.
CSS styles are also more reusable across different web sites. I can to some degree see that you can increase re-usability when using shared React components, but then you just create technical debt for those who want to test other frameworks
It seems to me that Tailwind is only a semi-scalable solution for those who use React components or similar. But as mentioned above, that causes problems when you want to make other webapps in another framework
- I generally dislike inline CSS styles, and the benefits of Tailwind is not enough to overcome that.
- Reusability across systems. At least in mature businesses, they often have CMS systems, different frameworks etc. Using Tailwind kind of encourages everyone to use the same internal React component library.
- Easier to read PR and git logs. Adding a single tailwind class to a component may mark the entire line as changed, and you need to figure out what has changed (including checking the code, because you don't know if that also changed).
- Designers can make changes in CSS without having to learn React.
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.
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.
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 rarely think this. It's usually “I want a button that looks like all other buttons on my site”. Vanilla CSS is great for that.
So I still have to componentize my presentation layers to do tailwind "correctly", but instead of writing CSS in readable multiline chunks in a language every developer already knows, I need to use this cryptic one liner in any order that literally nobody can read?
What in the hell is wrong with this industry? Sometimes clever ideas aren't all that clever. Sometimes they're just dumb.
Classes are a tool for selecting markup to style. Sure, you can create a class for every single CSS rule you write, but just because you can doesn't mean you should.
I'm not a frontend developer and don't really know much about these frameworks, but how is this different from just using style="actual css"? This just feels like inline styles reinvented for whatever reason.
And finally, when you did run into the IE selector limit, you could just split the style sheet in two (fairly trivial if you were using Sass), because the selector limit was per stylesheet.
media queries and pseudo-elements are impossible, just off the top of my head.
Tailwind's patterns for device responsiveness are actually the most intuitive I've tried
Also, though it’s lower-level than something like bootstrap, it does have a design system. Bootstrap is like building a model from a kit, plain css is like building a model from scratch, and tailwindcss is like building a model from lego.
style="border-radius: 5px; border: 1px solid #2563eb; background-color: #3b82f6"
Personal choice obviously, but I work with frameworks and components if I'm doing frontend stuff, so having things as a single name for something that is consistent across everywhere I use it makes it easier for me.
It's not for everyone, and that's cool.
1) style encapsulation,
2) colocated presentation/content/behaviour and
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).
[*] 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.
Colocation of presentation? Why do you even need that? Presentation is abstracted into CSS by design.
Having presentation decoupled allows you to abstract around visual elements on a page at their instead of having to sufficiently wrap everything in divs classes just to the right level to make the CSs classes work.
HTML describes layout, not just content.
Your overall structure is going to be vastly different whether you use flex or grid. And if you don’t want to write overly clever CSS you’re wrapping your dt/dd pairs in divs or you put dummy elements into your sections to control where the anchor links scroll to etc. And don’t get me started on non-hierarchical layout relationships.
HTML is not flexible enough and CSS is not expressive enough for this theoretical separation to hold in practice. You would need a translation layer between pure content and layout for this to be true (like XSLT).
What I suggested was decoupling presentation (actual CSS rules) from structure, the blocks of html.
What I'm discussing here is if CSS rules should be inlined in html, whether through tailwind pseudo css or style tags the result is the same.
Further caveat, the article mentions that switching to a CSS file is a context switch. Put it in a style tags next to your html for all I care, colocation is great as a general rule, inlining CSS in html style attributes is not.
This is settled thinking at this point: inlining CSS results in short term benefits to productivity at the cost of long term costs due to brittle presentation that is expensive to change.
And given how low the cost of extracting reusable css classes is these days, I don't think tailwind will ever win.
The structure of your HTML is as integral a part of the presentation as your CSS is.
The key point here is that CSS exists precisely because html markup isn't enough on its own to style itself. If it was, CSS wouldn't exist.
The idea that something like tailwind can come in with a bunch of fine grained CSS classes and solve this inate complexity is laughable at best and wildly unprofessional at worst.
It just shows a complete lack of understanding about what html is and isn't and why CSS even exists in the first place.
Fwiw, I get it. Tailwind is a neat shorthand script you can use to pump out trash you'll never look at again. For the rest of us doing actual work on things that we'll need to modify 6 months from now I'd much prefer something readable that I can actually have a hope of modifying even if a teammate wrote the thing.
Umm... How? You have to know CSS and be quite proficient to understand how to map it to Tailwind. I don't understand this claim at all.
I believe I'm convinced that if an abstraction is leaky then it's garbage.
For instance, if I really needed to know say, jvm assembler to code Java then Java would be garbage as an abstraction layer because it would simply be creating problems where they need not be.
Java however is clean, which makes it useful. I don't need to know the next level down. C is clean. JavaScript is. PHP is.
Tailwind is not. Many frameworks are not. They promise benefits but deliver complexity and programmers get invested into the system and then can't see the reality because it's a classic cult effect of giving emotional salience to a lie.
Eventually it collapses and a new one is formed.
And for some unknown reason, this. Shit. Does. Not. Stop.
It's really exhausting. Been programming nearly 30 years. So sick of it.
It would be like if I did say medicine and every 3 months or so the medical community started tripping over itself by believing in the latest weird quack with orgone energies and magnets and started writing prescriptions to their patients about chakras or astrology and then being shocked, like actually genuinely surprised when it all collapses.
Why do people run around like a bunch of frenetic teenagers to manufactured hype cycles in programming? Can we please fucking stop. Honestly.
It hadn't occurred to me that people might be learning Tailwind as if it's a replacement for having to learn or understand CSS. If you treat it that way then you're bound to have a bad time, much like people who treat git as a series of commands to be memorised without any understanding of git's underlying data model.
I'll also admit that I've only ever used Tailwind on small-to-medium sized solo projects, so I don't know how it would hold up on a big team. But then the CSS has been an agonising, unmaintainable mess on every big collaborative project I've ever worked on even without Tailwind, so what is there to lose?
That's the other thing, tools are a really poor shortcut to competency and in practice just reflect the same level of mastery that caused the initial headache except with a different set of tools.
This isn't pure. Some things are genuinely less insane than others.
As an analogy, higher quality brushes, paint and canvases will make you a better painter but buying new brushes isn't going to be part of becoming the next Monet. Consumption isn't going to get you there.
The real competency as you point out, come at higher level coherency, which frankly takes about 5-10 years to get any good at. It's a cognitive mastery that's mostly independent of tools.
People want to seek out better tools as a proxy for the hard earned talent. It might get you further but at some point, knowing what you're doing is the only way to go.
It sucks. It's hard. It's frustrating. It's always changing and it's also unavoidable.
I grok flexboxes and responsive design through Tailwind more than I ever did in those years.
I could certainly learn more pure CSS but there's no need at this point. I am happy and productive in my ignorance.
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.
Don't you just have to worry about making sure your update is propagated to all the right class lists? Seems like trading one medium problem for 30 small ones.
I mean there are techniques to avoid that like BEM and co, but they rely on you and your colleagues following them, and in my experience are a huge ballache.
Its also sometimes hard to track styling issues down, looking through all of the properties etc. And if you get into SCSS and mixins it slowly gets out of control.
On the flip site with Tailwind, it's all there in front if you and easy to change. If you need to repeat something often, you can just create components / partials with reusable parts.
We share a base layer in HTML, CSS, JS, but the incentives, requirements, job environments, team sizes, couldn't be more different.
I wonder about other languages and ecosystems. What would be a similar situation for e.g. C? Is there such a thing?
With the 2 combined you can save a ton of time and still having a decent responsive design
That’s why it won.
Heck people can even come together for a web framework let alone one tiny paid CSS tooling.
* 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.
* The fact that you can see immediately how an element is styled. No hidden, detached or indirect styling whatsoever.
For styles that are reused a lot I just create small & composable components (which are also defined by the Tailwind classes so they match distances & colors). But there are typically just a handful of these in a project.
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"`:
I've seen Perl code that was more readable than this.
I don't know Tailwind but with Bootstrap it would be m = margin, y = y axis, b = bottom, sm/lg = screen size, 4/5/6 = size
Personally I think that's way better than putting padding & margin in your own css classes.
It actually cuts down a lot on the custom css you need to write and also helps having a uniform design.
If you don't want those specific breakpoints in your project, you can override the defaults in `tailwind.config.js`.
This is exactly the problem. Humans write code for humans, not for tailwind specialists and bots. It should be clear and easy to read unless there is a valid reason for weird code (optimisations, hacks that don't work otherwise etc). Tailwind introduces yet another convention where it is absolutely pointless to do so.
There are some properties of CSS that are more static across screen sizes. Colors, borders, backgrounds, font-size (debatable!), animations, and maybe even some high level layouts (12 column grid, etc).
The rest of CSS is minute positioning via padding, margins, and widths. Often you need to customize those details to use slightly different values dependent on context within the application itself. This is where utility classes shine.
As for the media queries being hard/tiresome to write, don't we have IDE auto-completion for this exact purpose?
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.
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.
That means that the design/product requirements come first. The moment Tailwind's limitations meet design requirements, it'll take a back-seat.
It's basically the same reaction you'd encounter from saying "we'll build it in Bootstrap." If a company is investing in a new product or service, no one wants to be the guy that says "sorry our framework won't let us do that design" — at least, not in first year or two of a product life-cycle.
Tailwind's advantage — speed and accessibility for a range of developer backgrounds — isn't the same priority for large organisations vs. startups.
The key difference between Bootstrap and Tailwind is that Tailwind designs are distributed. So Bootstrap designs feel like Bootstrap designs, while for Tailwind you can keep having new and fresh designs from different sources.
Kind of the same with jquery (although it took quite a lot of new stuff...)
I feel like Tailwind won't get that
Components UI systems are not going away, even as we move back to static heavy sites and minimizing JS where ever possible.
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.
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.