> The more features that get added to Tailwind, the more you have to know about CSS before you can use those features. Right? So why not just bite the bullet and learn to use CSS without the additional tooling (and weird, often lengthy additions to your HTML) that Tailwind and other utility-first styling frameworks require?
This misses the point of Tailwind entirely. The point of Tailwind is to give everyone a common vernacular of CSS phrases so that I can bust out something like "p-2 m-2 border-red" super fast and still be writing code which is immediately comprehensible to everyone else on my team. There's also the benefit that I no longer have to think about class names, which is shockingly large.
Using CSS does not give you that. I don't even address the "learn to use CSS" phrase because anyone who uses Tailwind obviously knows CSS! We do the translation back and forth in our head as necessary.
It's also why I'm not concerned about Tailwind getting more features:
* Tailwind needs to have all the features of CSS, otherwise it's incomplete.
* The notion of Tailwind being "bloated" makes no sense:
* The Tailwind compiler eliminates any styles you don't need.
* Tailwind stylesheets are always going to be much smaller than normal CSS for any decently-sized app.
> Using CSS does not give you that. I don't even address the "learn to use CSS" phrase because anyone who uses Tailwind obviously knows CSS! We do the translation back and forth in our head as necessary.
While I agree, sometimes I feel Tailwind users forget that writing regular CSS is also an option. I have seen examples where developers repeat Tailwind classes for every paragraph, every link. They repeat same typography styles over and over again instead of creating some base CSS. A great example is this checkbox[1] where developers used 71 Tailwind classes to style the input.
I think Tailwind only shines alongside a component system like React where you can just create a new Paragraph tag and reuse that. It makes me very happy because in the end there's way less code for me to read and understand, and changes are obvious, immediate and easy to do.
By "base CSS" are you referring to using @apply? That's generally not recommended from what I understand, with componentization and reuse being preferred over most usages of @apply for this purpose.
I feel us programmers should be open to breaking rules in favor of convenience. I don't see an issue to why you can't use `p:not(:first-child) { margin-top: 12px; }` just because you're using Tailwind (that particular rule gives a margin to every paragraph except the first one which is usually needed in articles). The most productive programmers I have seen frequently disregarded best practices if it suited the situation.
I tried to avoid using @apply but that makes creating variations (e.g. of button styles) REALLY hard — as your code is just littered with class names. Plus if you're adding :active :hover and :focus styles, you have to do it on ALL the variations on all of the pages. It's frustrating and takes a really long time.
I've moved to using @apply in a few generalized classes and I love it, since my class names like "btn" "btn-success" "btn-success-outline" describes what I want, and I can easily go in and change them.
I'm not creating a new component for every tiny thing, like a button or a link, just so I can avoid using @apply...
> I can bust out something like "p-2 m-2 border-red" super fast and still be writing code which is immediately comprehensible to everyone else on my team
Is this somehow not possible if you say “padding: 2px, margin: 2px, border: 1px red solid”?
You would have to adjust for the default units in Tailwind for the padding and margin: "padding: 0.5rem, margin: 0.5rem"
In practice, GP wouldn't use "border-red", they'd use a shade of red (border-red-100, border-red-200, etc). The higher the number, the darker the shade.
These defaults are an underrated feature. The defaults for spacing ensure things look cohesive, and the defaults for color are supposed to harmonize well. They're informed by the book Refactoring UI [https://www.refactoringui.com] to ensure your design has structure. They're designed to make it easy to adjust parts of your design, without guessing, when things look "off".
thing is this is way too easy for developers only focused on frontend development.
for us backend developers also doing database, caching, networking, storage, etc. being able to write "m-2 p-2 border border-red-600" is way easier to remember and doesnt take that much brain cpu cycles that we reserve for more important stuff.
They are not the same. Margins and paddings can be configured to use a different base size (5px instead of 0.25rem). Colors can be configured freely, and with a centralized config. Kinda like inline Strings vs constants.
But there‘s more important benefits (IMO):
- Media queries are done inline and become ridiculously easy to read
- Light/dark mode colors and selectors are done inline
- Gradients are easy as pie and actually readable
- Built in grid system
- Your code is somewhat future proof - if the idiomatic code for a gradient changes, you only need update your Tailwind version
When you declare `py-4 px-2 bg-blue text-white rounded-lg` on five buttons in a row, doesn't this work almost exactly like inline strings when you compare to the semantic classname `button-secondary` that is maintained in one single place much like a constant? And wouldn't you just rely on constants to maintain consistency between components, in other words use CSS variables?
Edit: Hacker News did of course inline it, but that only proves the point.
The same goes for light and dark mode. These are by the way Custom Media Queries [1], but Tailwind has a `@screen` directive much to the same effect.
Gradients aren't much different in CSS nowadays, really, and the "built in grid system" is really just a super inflexible subset of CSS Grid that will run out of luck if you need something other than equal sized columns. If you use it for the core page layout, chances are low that you will want your sidemenu, main content and sidebar always appear in equal width columns. In Tailwind you don't, of course, but it is a wonderful feature of CSS.
Tailwind actually is future proof, but that's only because you remove Tailwind from the list of dependencies and check the generated CSS into your souce code repository. At some point all these websites will need an overhaul of the visual identity and people will realize all over again why presentational attributes were removed in HTML4 along with the introduction of CSS. You can update your Tailwind version, then, but nothing will happen. Fortunately, this "plugin system for custom code generation" can be replaced with a stylesheet.
Tailwind has certain qualities, but the things you mention are not some of them. I like that you can't simply copy the CSS from some textarea in Figma and paste it into the CSS, because that will soon make your website even more unmaintable even if it is vanilla CSS. You are in other words forced to think about the layout, the spacing system, the color variables and the breakpoint behaviors, ironically what the typical proponent of Tailwind would like to avoid. If all of these things are declared in a highly customized Tailwind preset, and if you elect to maintain complex components (eg. with synchronized breakpoint changes) in CSS files via `@apply`, it becomes an effective tool to enforce a "design system". Some might say that Tailwind's own creator advises against this strategy, but that should only encourage you, in my opinion.
Essentially, what he is saying [2] is that you should not use SQL to transform you date from one format to the other because the SQL will break when someone changes the database structure. Instead, you should just hardcode the result of this transformation directly into the database and now you won't need SQL at all. You could argue that this would be retarded since the abstraction layer enables different, future presentations of the data in question and that is exactly what I am trying to say.
My best advise is to go light on presentational attributes, which is what utility classes is, and move your Tailwind into proper CSS as soon as the implementation indicates moderate complexity [3]. Here you can make use of the `@layer components` stuff that bears an uncanny resemblance to semantic classnames, but more importantanly, now your Tailwind can easily break out into real CSS, for example to author your core page design with a Grid of uneven column sizing. Make sure to Use CSS variables for everything including your Tailwind preset so that `12px` are never mentioned in the JSON, but instead refers to `var(--base-unit-or-something)` which can be referenced equally in vanilla CSS. Keep the best of both worlds and Tailwind can add more value than it destroys.
I think you are disregarding Tailwind‘s composability almost completely and still thinking in terms of the document based HTML/CSS model.
With TW, it’s preferable to reuse whole components (JS+HTML+CSS). So in your example, you‘d have a button React/Vue/LiveView/etc component that is reused across the app. Only if _that_ is not feasible, you should fall back on @apply.
If you’re developing in an environment where HTML+JS+CSS code reuse is not possible, then I agree that OOTB TailWind is not that much better. But for a component-based architecture where you want to minimize outside dependencies, TW is IMO ideal. Meaning: React, Vue, Svelte, Elixir Phoenix (incl LiveViews) and many others.
If Tailwind relies on classnames used in the HTML and defined in CSS, then that is the document based HTML/CSS model. The composability you are talking about is a feature of CSS, not the component framework. By stopping short at "utility classes" instead of "semantic" classes that define a complex appearance, you in fact destroy composability in favor of either inheritance (assuming that your component framework allows) or simple copy-pasting. Ironically, Tailwind does feature the concept of classnames that aggregate utility classes to produce a complex appearance, it is called "@layer components", and it is infinitely more composable because you can @apply these things as well.
.my-tab { @apply my-button bg-transparent; }
There is actually a very powerful CSS framework hidden in there somewhere, but they remain intent on appealing to developers who believe that real layout is coded with JavaScript, perhaps it is because Tailwind is a multi million dollar business that relies on selling components to teams that give up on making their own.
Your components don't minimize outside dependencies when they share the same global stylesheet, by the way, they would for example not work in my website even though I am using Tailwind (if highly customized). This shared dependency, or "global variables leaking into my scope" as programmers would phrase it, is the problem that CSS frameworks have been fighting for years, and now it's become a brilliant feature of Tailwind that components can share styles. Welcome to CSS! Now you only need to define your complex layouts via @apply and you can share them as well, that is what composability is all about.
> you in fact destroy composability in favor of either inheritance
I favour composition over inheritance, so I'm ok with that.
> Your components don't minimize outside dependencies when they share the same global stylesheet, by the way, they would for example not work in my website even though I am using Tailwind (if highly customized).
I think you just made the case for using vanilla Tailwind and restraining from customizations to cater to design extravaganza. The days of pixel perfectness are over, and designers can and should IMO get used to making compromises. Form follows function, and using vanilla TW can get you more "form" in the same amount of dev time.
Having said that, wouldn't you just have to merge the two Tailwind configs and generate a new CSS file? Apart from color naming clashes (which can't be avoided in any system) I don't see any issues there.
You seem to imply learning Tailwind and CSS take the same effort, but I don't have that impression. Tailwind makes CSS tolerable for people who don't use it a lot. Its classes and defaults let me be productive very quickly.
It's not perfect and I don't like that it's yet another config file and more npm madness, but at least it's not CSS.
i know lol, the tailwind docs actually show the css equivalent side by side.
thing is, i despise writing the long ass version especially when im working with flexbox, grids, borders and everything else lengthy that i cant cram up in one liners
Only if you are coding in notepad. With any coding text editor that would be completed, with any ML model (Copilot and co.) this could take less than 5 keystrokes.
By the way, not entirely related, but when testing Copilot when it was free I noticed it was amazing at generating styles for something based on a class name. To the point I felt more productive and more in control than when using Tailwind, Bootstrap, MUI, or any other CSS "framework".
OP seems to miss the point that most everyone - or at least everyone I know - that uses Tailwind already knows CSS to a large degree. In addition, everyone I work with would rather spend time writing code than messing around with CSS and trying to name classes (great point you make, and I fully agree)
As a frontend developer I don’t understand this sentiment. I’ve learned to style websites using CSS, so has every other frontend developer, learning CSS is part of the craft, and if you skip it, you don’t know frontend development. Writing CSS is a big part of the job of a frontend developer.
Now if you are a hacker and are hacking together a website, that is fine. You don’t need to be a frontend developer to write a website, and if that is the case, use tailwind by all means. However in a team that maintains a webapp, you should expect there to be a frontend developer, and you should expect them to know and write CSS, if they are the only person on the team that knows CSS, then probably they will take some authority on that, and I would expect them to assert some authority on every code that contains some styling. If a contributor doesn’t know CSS, and writes a poor CSS code, that should be fixed during peer review. A team that is happy-go-lucky with their styles is surely not going to by writing a well crafted web-app.
What I understand about Tailwind is that it is _meant_ for those frontend developers who understand CSS, and you're essentially writing CSS when you use Tailwind - as opposed to a component library like bootstrap or material ui.
This sentence:
>Now if you are a hacker and are hacking together a website, that is fine. You don’t need to be a frontend developer to write a website, and if that is the case, use tailwind by all means.
Would make more sense IMO if you replaced the word "tailwind" with "a component library"
> Tailwind stylesheets are always going to be much smaller than normal CSS for any decently-sized app.
Instead the HTML content grows larger because of the long class= attributes. It is a bad tradeoff, because CSS gets loaded once and cached, but HTML gets loaded on every page load.
I don't understand why Tailwind proponents can't seem to see this, and tout "smaller CSS files!" as a benefit. You're still declaring the styles for every element somewhere. The client has to get those bytes somehow. That doesn't get to go away.
(And if it's just about "m-2" being shorter than "margin: 0.5rem" or whatever... I can't believe that after gzip that matters one whit.)
One of the signs of something being bloated is, when you need some compiler or "tree shaker" or <insert other fancy term here> to throw out the stuff, that you included in the first place, but are not using.
Something like "p-2 m-2 border-red" making sense relies on some imaginary grid or table layout being used. Web design should catch up at some point and get rid of that way of thinking. Websites are not bound to be aligned according to some grid. On a website things float and take as much space as needed and as available. There is no inherent need for inventing an imaginary grid. Yet so many "design systems" cling to that outdated notion. A website is not a sheet of paper in a magazine! It is like we still haven't left bootstrap behind us, or even table layout behind us, because web designers not actually knowing CSS.
Actually look at https://web.dev/state-of-css-2022/ (linked here on HN a few days/a day ago). CSS is easier to use than ever before! Now we can even specify our own specificity groups!
Once tailwind covers all needs for features of CSS, what will we have gained? We merely built another wrapper layer around the thing, that we should actually understand and learn. In my experience this will only lead to people thinking, that they should build something on top of tailwind, because they want something simpler, stacking yet another layer of abstraction, instead of actually learning CSS. At some point some sanity will return and do away with the whole stack of abstractions, because it indeed has become too bloated. (Note also, that no one will want to maintain your website based on tailwind, once the hype is gone and tailwind looks outdated.)
This kind of mentality of adding layer upon layer without watching out for the associated costs or realizing the power of already existing primitives is responsible for the tons of bloated websites we have today. For shipping megabytes of JS unnecessarily, instead of letting us enjoy the advantages of faster connections, like we should be able to.
About naming CSS classes: Surely not always a simple thing. Ideally the web design people would work together with the web development people and talk about their metaphors or abstractions on the website. Then find names for that and style accordingly. "How will we call this kind of thing here, with a picture and a label underneath and a rating? – Lets call it a product box." Or whatever else. They would build a common vocabulary and that would inform naming of CSS classes of the website. Additionally of course one would use a prefix, to avoid any name clashes with any other stylesheets.
There’s no imaginary grid here, m-2 and p-2 are just setting margins and padding. The 2 is a point in a table of sensible defaults for those values. You are free to set your own scale or just use your units of choice if you like. The defaults are well thought out though, and usually work well.
The whole point of Tailwind is that the worry about naming CSS classes goes away for most part. It turns out you can safely skip the vast majority of those granular naming decisions and conversations - that’s a massive amount of saved time and brain cycles for everyone.
If you’re using eg. BEM you have to come up with all these granular names for subcomponents that really no one cares about apart from you (the frontender I mean). If you’re not using BEM or similar and going for longer selectors in the main, then you have a coupling issue between the structure of your CSS selectors and the structure of the HTML that may make maintenance in the future harder.
It’s more like “i.e. shall we inline all our variables” / avoid naming things at all.
Adding a name for something is a weighty task that’s orthogonal to the task at hand. If you can avoid the name without losing understandability then it’s a win.
The other side of that coin is that if you add a name it has to be worth the effort.
In CSS, a number of techniques developed over the years in response to the maintainability challenges of even well thought out, traditional good practice CSS in large projects. These techniques (eg. BEM) required class names for almost every element you need to add styles to. This was to avoid long selectors that a) are hard to understand, even for experienced CSS developers and b) are tightly coupled to and generally not co-located with the HTML.
Tailwind gives us away to avoid those having to choose those names, which just took a long time and lots of conversation if you wanted to get them right.
Yes, it’s literally in the HTML so it’s coupled, but it’s co-located. The maintenance story is much simpler than with BEM and much much simpler than with trad CSS. Lower effort for a better long term result - it’s a win.
There is a downside to not naming things: All the concepts are in your heads and not in the code. It's not self-documenting at all. No one names that div or section or whatever tag via a readable class name, so any future reader will not know, that that might be a concept bound thing in the site. Styles are just applied until it works, which leads to a mess. New web dev comes in and gets told "That font is too big!". New dev opens the inspector, looks at HTML element soup. Hurries to the code, replaces some styling on that level of nesting in the HTML, but does not understand the concepts of the site at all, nor that there are probably 10 other places, that now need change.
A well thought out class name would have helped understand, that new dev is actuall editing something, that is part of a group of things, which all have something in common.
Naming things is hard, but finding good names is worth gold. Avoiding the hard parts is not going to be the solution to all problems. We would all be working in some kind of modern version of lambda calculus, if naming wasn't important. There are good reasons, why we name things. To convey meaning and convention. Not naming things hides these and makes them implicit, instead of explicit.
There is a line to be drawn somewhere. If you set your naming level too high, then it's not clear what you're doing in the details. If your naming level is too granular, then you start to lose clarity because you can't see the wood for the trees.
Regarding the problem of a developer new to the codebase being told to change the text size in a specific place; Tailwind works well in this specific situation.
At the beginning of your project, you will have chosen a (or accepted the default) text size scale. The new developer will probably choose the next largest step in the scale and step back. The new size will be in harmony with the rest of the project because it matches the scale. If this specific element is repeated elsewhere in the project, then it will be part of a component and all instances of that component will receive the change.
The right place for a considered name in this example is at the component level.
And controversial opinion - it will have just as as short a shelf-life as coffee-script. Once the CSS spec advances, there will a lot of posts with titles like: "Why you don't need tailwind" or "Learn how to get rid of the tailwind bloat", "Migrating back to Core CSS", "Back to clean, semantic HTML", etc.
The difference between Tailwind and CoffeeScript to me seems to be more in the underlying language.
JS (and programming in general) is actually quite complex, and you can't hide that complexity under a shiny veneer and hope it goes away.
CSS on the other hand is not complex at all. For that reason, it's a lot more plausible that you can make big strides by simplifying the language down to its core essence.
The occurrences have become fewer and farther between, but in such cases I'll configure my own utilities until the project catches up. The syntax for adding utilities is lightweight and embeds directly in config, ref. https://tailwindcss.com/docs/plugins#adding-utilities
> The more features that get added to Tailwind, the more you have to know about CSS before you can use those features. Right? So why not just bite the bullet and learn to use CSS without the additional tooling […] that Tailwind and other utility-first styling frameworks require?
This is an incredibly silly argument because Tailwind has always required you know CSS, or at least understand how it works. The selling point of Tailwind is a more convenient and co-located way to write styles—the utility classes map pretty much 1:1 to CSS properties after all.
Covering more CSS features with Tailwind classes does not make Tailwind inherently more complicated, it just adds a way to express more CSS that you need already know about.
But tailwind fans keep saying that you don't need to learn css. Even in the comments here, people have said they use tailwind so they don't have to learn css because they're not a designer.
Also the biggest reason to use tailwind is apparently because naming css classes is hard...
I can't speak for others but I'd imagine you are talking about two different things. There's "learning css" in the sense of learning all the syntax & semantics. Tailwind does not help you here at all. Then there is "learning css" in the sense of using it decently. Meaning proper spacing of elements, good typography, etc.. A design system if you will. This is where tailwind steps in by providing very reasonable defaults for a lot of things.
The advantage of tailwind over a full design system is that it is piecemeal, you only pay for what you use. It really makes a lot of sense when combined with a component system like React because you get re-usability at the component level instead of the style level. I like this a lot, but it may not resonate with everyone.
Oh, the design system aspect of tailwind is GREAT.
The idea of utility classes is super helpful.
I was actually pretty into tailwind at first for these reasons.
There were some issues, most of which were fixed with the JIT.
That said, most of the hate for tailwind is due to the 'community'. People saying to just take the best parts are the minority of opinions you see on tailwind.
This is a genuine question: are Tailwind fans really saying you don't need to learn CSS? I'm a huge Tailwind fan and I've not seen people say that. I actually don't even know _how_ you could use Tailwind without knowing CSS!
There's layers to 'knowing css'. There's I've been working w/ it for 20 years, but can I create flexboxes without google? nope. Do I learn every new feature/nuance? probably not.
It's like you can know how to unclog a toilet or change a faucet, you're no plumber, you don't know what a plumber does, but you can do enough for 80% of your needs, and when you can't you either call the plumber or you pick up a plumbing book or go to google/youtube.
I don't think you need to be a CSS expert to use tailwind, that's why I stuck w/ bootstrap for so long, but I also think you need to maybe think more about the underlying css so at least be willing to keep more CSS knowledge in your RAM or SwapFile in your brain, but there's things like daisy-ui that sort of wrap TW in bootstrap like niceties so you can kind of have both worlds, and come with nice themes to boot.
If you just copy the utility classes (for example from tailwind ui) and don't touch the css file, you get what you see in a reliable fashion. I guess that might qualify as working without knowing CSS for some, in the crudest way possible.
It's not hard to use tailwind without knowing css. Google answers your question 90% of the time. The other 10% you read about the appropriate css and then translate that to tailwind.
I think everyone using tailwind probably 'knows css', they've used it, they can test stuff in chrome via inspect, and they know the basics. Most do not know flexbox inside and out, or every different ways to make grids, etc.
Personally, I usually just look through component sites for something like I want, then modify it to my needs. 95% that works, sometimes I go build it out myself.
I'm fullstack, but more backend and that's where I'm most comfortable so the less I worry about design the better it is for my sanity, except I do like dabbling w/ the js layer in vue, alpine, or react.
I'm a Tailwind fan. I love it not because I don't know CSS, but because I'm not very good at using it. Tailwind is easier to use than CSS for knocking up a quick site.
I know plenty of CSS, and the more I know, the gladder I am to use Tailwind to express it.
It's nice that some folks are using Tailwind to shortcut a need for more comprehensive learning, but let's not misrepresent that for one moment as being a fundamental purpose. The organising principle of Tailwind is to refactor styles at the abstraction level of on-page components, not supplying an off-the-shelf design system for front-end novices a la bootstrap/material design.
I probably going to get quartered here but I am one of those users. I have basic understanding of css, but prefer to use Tailwind because I can't be arsed to write css. I detest css and consider the worst part of web dev.
I don't think people who made css were webdevs at heart but typographists or artists, and as a result css feel unnecessary convoluted.
What the tailwind model does is having you not think of selectors or the cascade most of the time. I don't know what that would have to do with being a designer or why naming css classes should be harder than naming any other kind of class.
I also think the listed sentiments would not be strongly reflected in actual tailwind dev polls.
Just like CPUs don't need tooling - you simply write some Assembler to execute on them.
I find organising CSS files to be pretty hard, and I've been using it since 2001, predominantly as a backend dev who needed to churn out a decent enough front end. Tools like Compass, SASS, Bootstrap, LESS have helped with all of that. Tailwind is the best integrated version of all that tooling that I've worked with.
I've used a lot of tools for writing "CSS" over the years: pure CSS, CSS modules, SASS, LESS, BEM,... I think when using Tailwind, you have to know the "real" CSS anyway, but the most important thing that Tailwind offers is the consistency.
So you need 1-unit padding? `p-1`. Double that? `p-2`. Still not enough? `p-3`. More? `p-4`. I don't have to think and do math in my head like 0.25rem, 0.5rem, 1rem,... and IMHO, it's a big enough win for me to keep using Tailwind CSS.
The features that were introduced in recent versions are just about supporting more CSS features to be more complete and not about feature-bloat.
That doesn't seem like a big enough win when CSS variables exist and offer far more readable options (as you're the one naming them). On that front, I reckon majority of Tailwind developers use far fewer variables than they believe, so it's not some gigantic monumental task where you have to set up a million different CSS variables.
This is the problem with Tailwind, it doesn't offer enough nor does it move faster than CSS to justify its existence. The only real use case for it seems to be solo developers that do not have the time or resources to set up their own baseline set of variables, or those that use it with a component library that's based on TW.
I think you need a reality check on who actually uses Tailwind. Very large cops and sites use it because it improves the dev exp and increases performance through smaller file sizes. Further I’m not sure what you mean about not moving fast enough, they just added container queries.
I'm working at a small company with about ten employees - realistically max three or four people will work on the styling although a few more will have eyes on it.
We already get massive benefits from it that I wouldn't get as a solo dev. If someone else writes a bunch of new components that make up a new menu and I need to grok them quickly and then start working on them quickly, Tailwind brings the time I need to spend understanding the styling down to nearly zero. It's a massive timesaver for teams of any size.
Yes, you can get some of the benefits with other systems like CSS variables. But not nearly to the same degree, and you'll also need to organize a bunch of CSS/SCSS files besides you main code.
With Tailwind we have something like five small CSS files across a large monorepo that contains several apps.
Yes, and you'll find many of those very large corps are questioning why they're using it now. Which is a great thing, many businesses should be in constant reevaluation of why they rely on certain tooling.
Personally doubt the better performance, I have yet to see a case where that is true unless they were comparing it unevenly to some behemoth like Styled-Components. When you compare it to SASS the performance difference ceases to exist. Same with "improves the dev exp", I don't see how this is the case at all especially when you have to install an additional extension to get full proper support in your IDE of choice. You are still working with variables, if you are on a tiny team/solo, it makes sense to use Tailwind defaults but on a large team where your design team should be creating their own? What use does Tailwind have then when the utility classes are just going to be overwritten? You're still creating the components yourself.
I suggest you double check those performance claims. The CSS might be smallish, but you're usually moving the weight to non-cached HTML which is re-downloaded on every page view. I helped analyze the impact on a very large website (billion+ pageviews) and it did not look very good.
What you are saying is: "tailwind class names are cumulative and so verbosein the HTML tag that it negates the benefits of smaller CSS and eat the bytes saved?". Am I reading that right ?
And this does make a difference when your entire layout is done with Tailwind. Consider that the HTML, unlike the CSS, might typically not be cached, and that the server is now also charged with emitting higher loads of data. Consider also that all these utility classes are all loaded in the CSS on the front page even if some or most of them is used on everything except the front page. The performance win is not as unquestionable as Tailwind would like to suggest.
Funny, I had the exact opposite experience using Tailwind: my design tools gave me measurements in pixels or rems, and I had to do math to convert them into Tailwind units.
I'm not sure about libraries that could compile and extract to static css like linaria, but Tailwind is 100% compile time only, all CSS are generated and there isn't any runtime overhead.
So why not just bite the bullet and learn to use CSS without the additional tooling (and weird, often lengthy additions to your HTML) that Tailwind and other utility-first styling frameworks require?
Because I'm not a designer :)
(EDIT: there seems to be some confusion by what I mean here. What I meant is that knowledge of plain CSS does not enable me to create clean designs like Tailwind does.)
Really though a huge benefit of Tailwind is their UI package https://tailwindui.com/ which I routinely use
Aside from that, I also like how their components are all very lightweight normal HTML. Compare to Material UI, etc. which are so heavy that you can't even use them with many 3rd party libraries because they're more than just CSS.
Often times, third party components accept some class lists, which fundamentally means they are only compatible with simple CSS libraries like tailwind rather than component libraries.
Anyway I get the concern but I also feel like the concern is still very, very far away from becoming reality.
Then you're using the equivalent of bootstrap or bulma. You're not really doing anything benefiting from utility classes.
And if you're going to use tailwind utility classes, they're mostly one for one with a single css property, so you're learning something that is functionally similar to, but not css.
If you pull prebuilt tailwind components and that's it, then, yes, you aren't doing anything different than bootstrap, except for a somewhat different default look.
The advantage to the tailwind approach is that all the utility classes are right there, ready to be adjusted. It's designed to expose all the "buttons, dials, and levers" needed to customize in whatever direction you want to go.
(Not that bootstrap don't have customization options too, but the barriers are higher and the directions you can move in are less flexible.)
I honestly do not expect a designer to write css, primarily because they should focus on aesthetics - not writing efficient css. I as a web developer am well suited to write that css, and can do so quite easily.
If the (print) designer is expecting pixel perfection, but knows nothing about css, and hands me an illustrator file, I'm walking away. You likely have things that are either unimplementable, or overly complicated. Examples would be 'this image should be 3", but you made it 5" on my laptop and 2" on my 4k monitor.'
If a (normally print) designer hands me a figma file but can't pull it off themselves, rock on. They likely have some idea of whats possible and what's dumb to try and do.
But honestly, if you're full time web designer specifically, I expect you to be designing in the browser, with some occasional help.
I don't like massive long class names on my DOM elements. And I don't think it makes the code look/read nice. Tailwind is so close to CSS that I'm often left scratching my head as to why people don't just write CSS - it will look nicer too.
because the cascade part of CSS is error prone and because naming stuff is hard. Functional lib like tailwind or tachyons solve both those problem as far as I am concerned.
This feels like a weak argument. Yes, naming things are hard - but we name classes, variables, dom elements & everything else every day. There are also really good naming patterns for CSS out there too (BEM, etc.).
Because, if we're talking about css-in-js, then they'd need an external dependency anyway to handle hover/etc.. states. TailwindCSS lets you inline that.
So you need either to keep styles inline, which has a lot of drawbacks, or figure out a name for every single thing.
Tailwind is essentially inline styling done right + a set of constraints to keep your design consistent even if you are not a designer. Pretty sweet setup if you ask me.
My heart sank a bit when reading the phrase, "absolutely massive amount of new stuff" in Tailwind's release note. I agree with the article that this may be the inflection point where I return to just using Sass. (So far I've been using both.)
But Sass has been recently introducing seemingly unnecessary changes in syntax, making their documentation incompatible with existing compiler implementations - and I'm getting tired of trying to catch up.
I'm thinking of moving to PostCSS with a small subset of features, like nested selectors, to stay close to the CSS specs and hopefully one day we can do without any preprocessor.
---
Edit: The author of the posted link has an in-depth article on Sass, with much of which I heartily agree.
Recently I had to develop a somewhat complex vuejs web app that works well in both desktop and mobile
And most importantly I had only 7 days to develop it. And I just breezed though the frontend development thanks to tailwind which I won’t be able to do had I used a different framework like bootstrap or vanilla css
I think developers can select the features they want to use, and if they don’t want to use the new features they can just use the existing ones and leave the new ones alone.
For the moment I don’t find a reason to skip tailwind
> And I just breezed though the frontend development thanks to tailwind which I won’t be able to do had I used a different framework like bootstrap
That’s interesting because I had the exact opposite experience with Tailwind. We were in a hurry to but Tailwind’s lack of standard component classes meant we spent a lot of time trying to find components to do basic things, we even paid for Tailwind UI but we found the experience really weird that all you get is code samples that you just paste into your code and tweak?
We ended up going with bootstrap because there’s plenty of open source libraries that have all the components and it’s easy enough to tweak the bootstrap theme to look how our marketing and branding needed.
Where we needed more customization, bootstrap has a lot of nice utility classes too now.
Tailwind is a lot of fun when you end up with spaghetti code and classes littered all over the place. Sometimes there are 20+ classes on 1 div, it's insanely hard to maintain.
I love tailwind for small things but when I have to maintain it, it's pretty awful.
I've had the total opposite experience. I've found that any sort of CSS scheme that tries to be clever or have any meaningful amount of re-use becomes an unmaintainable nightmare over time. Tailwind keeps the bits and pieces of the utility classes as close to the content that they are styling as possible, and that _drastically_ reduces the complexity of maintenance. You use the reusability scheme you already have- typically components in some sense, React or templates or whatever- instead of attempting to layer another one on top for just your styles.
In fact, maintainability is by far the #1 reason I use Tailwind. IMO it's actually quite a bit more clunky and slow for the initial styling process.
Bootstrap a great for breezing through frontend development in my experience. The only issue is your site looks very much like a bootstrap site... which is completely fine for many kinds of projects (In fact, you might as well grab one of those decent bootstrap templates and breeze through even faster).
I've been using tailwind for cases where a bootstrap site isn't OK. I can't breeze through so fast, but the site can look and act exactly as I need it to without fighting the framework.
It seems straightforward to just bite off what you need from Tailwind- the new features won't inhibit you from continuing to write flex and padding interfaces. I don't even think that a selling point of TW is not needing to learn CSS. It's easier a lot of times and cleaner to refrain from adding new files with conventions you have to come up with to do something that takes 4 characters with TW
I've always found the "Tailwind as CSS shim" attitude compelling, and like most shims will successfully pave the way for its own gradual superfluousness (a good thing imo).
Looking at the Tailwind 3.2 feature list I don't necessarily disagree that some of these look like feature creep, but I think this article falls flat because it asserts a premise that I just don't think is true:
> the idea behind Tailwind, like every other utility-first CSS framework, is to make styling easier, especially for front-end developers who dislike getting under CSS’s hood.
> The more features that get added to Tailwind, the more you have to know about CSS before you can use those features. Right? So why not just bite the bullet and learn to use CSS without the additional tooling
Tailwind is not an alternative to learning CSS, or "getting under CSS's hood", and I don't think I've ever seen anyone promote it as such. Tailwind is explicitly very low-level. It's an alternative way to write CSS, not an alternative to knowing CSS. All of its class documentation starts with the exact equivalent CSS declarations for a reason.
Exactly. Tailwind's utility classes correspond 1-1 with CSS attributes more or less. Then you have variants to help you target things like hover and focus states as well as pseudo elements like before and after. But Tailwind does nothing to hide away CSS in that you still have to understand flex and grid layouts, padding, z-indexing, margins, etc.
What Tailwind does give you is a way to build on top of a design system. The Tailwind config gives you a pretty good default design system in terms of spacings (padding and margins), colours (palettes and shades), etc. And you are free to modify or make your own design system, but once you do your design is much more likely to be consistent.
You can of course achieve the same design system with css custom properties (aka variables), but you have to be much more cognisant of using them. With Tailwind the design system is the default and you have to go out of your way to use custom values.
True, you don‘t need to know them, but they’re in the ever-growing documentation. I guess I’m thinking about teams which are onboarding devs who are new to Tailwind. It was a lot easier intro two years ago than it would be now, and I’m uncertain of how much brainpower and time it now truly saves for those to whom it’s a totally new experience (and reading job).
To be fair, like with any other form form of knowledge, there's a "minimal viable" amount, and a "complete grasp" amount. TailwindCSS adding to the latter is not the library becoming more complex. In order to know 2020's tw's feature set, the amount of stuff to study remained the same.
Tailwind is a utility library. Utility libraries typically do not require reading their documentation from cover to cover before starting to use them. Instead, you just hit the docs when you need help solving a specific problem.
> The more capabilities that get added to Tailwind, the more complex Tailwind becomes. It may not yet be near a tipping point, but that’s a danger for which the Tailwind team will have to be on the lookout.
Tipping point of being too complex?
For what?
Doing more harm then good?
Is that the argument?
I am not a Tailwind fan, I don't use it, but I think, it did not reached the tipping point (of being useful) just at the 3.2 release.
I wouldn't say that the article or tailwindcss are good or bad. I would just point out that the difference between good and bad product management is the feature creep. Did tailwind css do a bad job at product management? I don't know, but some new features are useful to me.
@supports(backdrop-filter: blur(6px)) {
.card {
background-color: rgba(0,0,0,0.75);
// Why would you not also be using backdrop-filter here anyways?
}
}
It's more verbose if you have one property sure... but if you do two, tree, or more, all in the @supports rule, it's a big difference.
I want tailwind as a DSL or IDE feature to write CSS. That’s mainly what I like about it. I don’t mind css but it’s repetitive to style a bunch of nodes.
The author may have a point. Some people will be: "well, just don't use those features then". But you are often not the only dev on a project. And some devs just love using the shiny new stuff even if it does not make any sense.
Oddly, the sentiment I see most often in HN threads about website complexity is that a simpler look is better, but perhaps your experience is different. I definitely have done more complex things in 25 years of web dev, but I simply choose not to do so now.
Otherwise, I will let your reply stand for itself.
It's a little better, but definitely something I'd expect more from a backend developer than a frontend developer.
Simpler is better, but you still need to do well on the things you keep.
The whitespace on the navbar isn't great, the logo looked stacked on and doesn't fit well, don't use gradient backgrounds on content, the note color doesn't match with the background, the bottom section is too vertically long, you could simplify, or move it to use horizontal space instead, and the black bar for "Previous" looks out of place.
What I like:
- Title is strong and centered
- Date is very easy to find (especially for technical blog posts, they can tell you if it's outdated or not)
- Good choice of fonts
Interesting, and thanks for the compliments within. Perhaps you could point me to two or three other personal sites/blogs whose styling you *do* find pleasing or appropriate, so I'd have some idea of the standard(s) to which I should be adhering? Since I've seen many sites with designs not that different from mine over the years, it would help me to know where else I should be looking for look-and-feel guidance, instead. Thanks.
I’m always amazed at how sadistic frontend developers are to themselves. I saw Tailwind required some config file and compiler and noped right out. I guess they have to keep up with the backend folks screwing around with the million different DevOps and cloud bullshit.
I generally try to keep the number of config files and compilers minimal. I suppose that's considered blasphemous these days, since every simple web app has at minimum 20 different config files in the project root. I prefer solving actual problems related to my domain.
The point of Tailwind is that it curates the useful subset of CSS into a nice DSL. Not unlike Typescript and type systems. I'll learn about any of the stuff that makes its way into Tailwind release notes and Tailwind docs. Anything else about CSS I will happily never learn about.
This is why people could say "Don't learn CSS, just learn Tailwind". Tailwind is the only decent way to use and to learn CSS.
This misses the point of Tailwind entirely. The point of Tailwind is to give everyone a common vernacular of CSS phrases so that I can bust out something like "p-2 m-2 border-red" super fast and still be writing code which is immediately comprehensible to everyone else on my team. There's also the benefit that I no longer have to think about class names, which is shockingly large.
Using CSS does not give you that. I don't even address the "learn to use CSS" phrase because anyone who uses Tailwind obviously knows CSS! We do the translation back and forth in our head as necessary.
It's also why I'm not concerned about Tailwind getting more features:
* Tailwind needs to have all the features of CSS, otherwise it's incomplete.
* The notion of Tailwind being "bloated" makes no sense:
* The Tailwind compiler eliminates any styles you don't need.
* Tailwind stylesheets are always going to be much smaller than normal CSS for any decently-sized app.