From reading the blog post, it looks like they took most of the things that were experimental or first class plugins and graduated then into being native.
Having used it pre-release, the JIT compiler is really incredible. It makes Tailwind a sea-change when compared to Bootstrap and the other, similar, CSS toolkits.
Since I learned to write semantic class names, and to compose using scss or react components, Tailwind feels like it would be a big step back. I get that it would be kind of nice to prototype in, but is anybody here using it for complex apps or UIs?
From reading the previous threads, large projects are where it (apparently) really shines. Personally I didn't find it useful at all, but obviously YMMV.
If you're using components, then it works great. The css is local to each component, and you only have to make changes in a single place. I'm just doing a fairly simple app, but I can see it scaling well to larger projects.
Funnily, I've experienced something of the same, but inverted. I was all in on semantic class names for years, then moved over to Tailwind for a few work projects and couple of years.
Now I'm back working on a project with a team that is staunchly against TW and I'm having a hell of time getting back into the rhythm of naming things. Everything just kinda looks like a box so I'm having to go back to the the designer or team to pull out names for things.
Definitely looking forward to when I can go back to using Tailwind at work and on personal stuff. The cognitive overhead is real.
I work on a large Next.js project that has at least 100 custom made components all using Tailwind CSS. It is, without a doubt, the best way to iterate and make changes. I will never go back to manual stylesheets. Having a separate CSS stylesheet feels like context switching and breaks the flow of development in my opinion.
Super bizarre - I've found the opposite. I really like Tailwinds, it's great for getting up and running quickly if you're a one-person-team but as our team's grown, readability becomes quite a big issue (it's just not as clear as pure CSS/SCSS I find)
For those that don't know, the laundry list of new stuff is probably all enabled by the first item in the list, just-in-time compilation. This means anything they can dream up can be included as a utility class, without bloating the compile time of the 99% of projects that will never use the feature (also without bloating the css package size, but that's not new since shaking out dead classes for prod has been a thing since forever).
Really happy to see this before the end of the year. The JIT improvements and comprehensive arbitrary value support will no doubt come in handy for quick one-off projects or bespoke landing pages.
I'm happy they have also expounded upon some of the more common FAQs on the homepage, including the extraction to components.
Looks fantastic. My only concern using this in a full React project is its lack of interoperability with standard libraries. It seems like for the best experience, you either buy Tailwind UI to use with a tailwind project for anything except the most basic UIs, reimplement the Tailwind UI components yourself, or have a weird mix of css-in-js and Tailwind CSS. Although I love the idea of HTML-native inputs all the way through, I tend to immediately run into issues where using a native interface instead of a JS-based implementation harms the user experience.
Props to the team though - I feel like this is something I'll try out for a marketing site.
You may be interested in Chakra UI (https://chakra-ui.com), which has low-level details (including default theming) basically identical to Tailwind CSS v2 but is built around css-in-js via Emotion.
Shameless self-plug but if you'd like the same idea but that works with native as well and has an optimizing compiler that outputs clean CSS at build-time, try Tamagui (https://tamagui.dev).
I like Chakra...mostly. We have ran into some major performance issues with it all over our application though. The docs [1] make it sound like it's a rare issue, but we're not doing anything particularly wild and it became unusable at a point due to these issues. Now, we have a "no Chakra below this point" rule where certain parts of our application are not allows to use Chakra at all and use TailwindCSS + our own custom components instead.
They do based on what I've seen, you're right. I'm speaking more to the consistency of styling across the project, but if the UI library is separated out from the rest of the project then it shouldn't actually be a concern to compose the components with tailwind-styled elements.
You're right as it probably won't work well with MUI [0] (formerly React Material) and similar options like Ant [1]. But they all accept a theme provider that could hook in to the Tailwind config. Never tried it though.
But a swell of less opinionated offerings [2] [3] [4] (more and more the popular anyways) work well with Tailwind. In fact, when writing your own libs, exposing a className prop makes them painlessly customisable.
Thanks for these ideas! The react-aria seems quite interesting to develop a UI library library using Tailwind-styled elements while accounting for accessibility.
> Although I love the idea of HTML-native inputs all the way through, I tend to immediately run into issues where using a native interface instead of a JS-based implementation harms the user experience.
The way HTML forms (in particular, but also things like tables) are stuck in a not even good for the time '90s level of functionality is an under-appreciated drag on all web development, IMO. So very much wasted effort, wheel-reinvention, brokenness (a11y, especially) et c. for shit that should have been built-in years ago.
> The way HTML forms (in particular, but also things like tables) are stuck in a not even good for the time '90s level of functionality is an under-appreciated drag on all web development, IMO
It absolutely is, but things are changing! Come help us get better form widgets built into browsers at at https://open-ui.org/.
The website's a bit behind, the Discord and GitHub issues are where most discussion happens. We need people who know hte pain points to help us.
Before you ask, as it happens in every Tailwind post, what is the point of this when CSS "promotes" reuse and separation of concerns, have a look at @
5e92cb50239222b comment: https://news.ycombinator.com/item?id=29501650
And let me repeat what every Tailwind fanboy (like me) states every time this project is on HN: don't knock it till you've tried it. Look at the animated example in the front page. You'll never be able to iterate that quickly with CSS.
If you have a hammer... I am able to iterate orders of magnitude faster in Adobe Photoshop. Back and forth feedback with the customer and then the end result gets coded in non-spaghetti reusable, themeable HTML/CSS. Seems you're iterating at the wrong phase.
Depends. I’ve never used Tailwind, so I’ll entertain your aside. If you are mostly doing flat design, truthfully you should be designing in HTML/CSS/JS. This is a failure of setting expectations for designers. If you can get developers to learn Leetcode, get designers to code their designs.
Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms.
You will not iterate faster than what I am suggesting.
Edit:
The reason why we are here, why something like Tailwind and MUI exist, is mostly because we need an abstraction layer to do what a designer does on a whim. You can flick a shadow on and off on a Photoshop layer and mess with the subtlety of a drop shadow with a slider. If a designer makes a fickle change, the developer needs this abstraction to make the fickle change as fickle as the thought that made it. That’s why you have all these quick utility methods. The designer is one layer (no pun intended) removed.
In 2021 (2022 really), it’s shocking the amount of latitude we give designers to still not be able to do CSS. A half competent designer could have a modest style sheet that mostly captures their design instincts, yet here we are, unable to capture their whims and must now have an albatross utility library to have manual laborers capture the translation - all because … they still won’t learn basic shit.
And for what ultimately? These aren’t baroque art pieces, it is ultimately boxes with an aesthetic applied, all very describable with semantic HTML and CSS. But alas, our brilliant artists can’t be bothered. Here, send me your masterpiece so I can transform it for you.
Take the bootcamp on web dev. You are literally the people I want going there. Not the Classics major that needs money because they picked a stupid major. It’s you guys that need it, and deserve it.
> Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms.
This is why all but the very best flat designs (which does not always correlate positively with the size or reputation of the firm turning them out—looking at you, Google) look to me like something I'd have turned out for a quick feature demo circa '05, with everyone at the table agreeing that, however nice the feature, a designer definitely needed to take a pass at it before it was released.
Perhaps. But hard coded colors, hard coded layout (flexbox etc), hard coded margins, paddings hard coded everything right in the markup. Tailwind and those adjectives are mutually exclusive.
Does nobody remember themeing forums software like vbulletin? Designers weren't allowed to touch the markup in the slightest and yet so many amazing themes were made. Why? Styling wasn't hard-coded in the markup. Hell, remember the insanely customized old.reddit subreddits?
All of the things you mention, including colours, are configurable or at least overridable at compile time. It's just not swapping a CSS file like the good ol' days.
Nobody said that it’s a bad experience to use. People say that it’s evil.
And, also, that it is made by and for the JS crowd that doesn’t understand CSS nor the document hierarchy it depends on, while simultaneously considering it unworthy of any learning efforts since it’s a girly making-it-pretty addition to a markup language, not a real professional STEM-grad-grade programming language.
As much fondness as I have for the pure separation-of-concerns CSS Zen Garden style, I have to admit I've yet to actually see it leveraged on a real project. In 20 years of working on the Web. I'm not sure I've ever seen a significant re-working of CSS to re-theme a site without also changing the markup substantially.
In practice, maybe coupling the two doesn't actually do much harm, provided consistency of approach is maintained and it doesn't go quite as far as inlining CSS all over the place.
Any thoughts as to how Tailwind can handle dynamic plugins using Tailwind? Ie it seems Tailwind relies on tree shaking to produce sanely sized CSS. But if you have plugins which rely on Tailwind, you'd have to either ship the full sized Tailwind CSS or they'd have to duplicate CSS and ship with it.
So far with this plugin/extension design i've not found a way to use Tailwind and also retain nicely sized CSS.
> it seems Tailwind relies on tree shaking to produce sanely sized CSS
This 3.0 release has its biggest feature be JIT. If you read the linked blog post, CSS is no longer purged but generated dynamically by reading your source files and generating the TW classes you use. It's not tree shooken anymore
Appreciate the info! I'll have to figure out how the hell this works though lol, i watched the video and am still a bit perplexed, since i'm not using JavaScript. I'll be curious to see how i can hook into it
As far as I understand, the build system just scans for whatever Tailwind class names you use, and then generates them into CSS. Which is why you can't dynamically compose Tailwind class names and insert them into your markup, cause it wouldn't be picked up.
Whether or not you're using Javascript doesn't matter (I guess unless you use the new CDN script which I haven't tried), but it does need to be run in a build system.
If it just uses regex over source material i guess it would be fine, though seems like it might hit a fair number of false positives if it's too loose. Too rigid and it might not work if you don't write your css vars in something that looks html-like.
I've never looked into how accurate it is, but even if you get a few false positives, I'm not too concerned about a few extra characters being transferred in the grand scheme of things.
The creator of Tailwind posted a comment in this thread that the Tailwind website itself, which uses way more Tailwind classes than a normal size would use (for demoing everything), only spits out 36.9kB of CSS.
Some technical thoughts as someone who could care less about fanboyism:
- One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes.
- Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive.
- Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways.
- You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development.
- Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while).
- There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[1] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows.
The main theme to be aware of: proponents of atomic CSS rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[2] vs hyperlocal development workflows interact with your organization's design culture.
What animated example? You mean the youtube video? I didn't see anything compelling in it over CSS. Stuff like "You can now style print media!". The only reason you wouldn't have been able to is because you were using tailwind. This new release is probably an improvement over tailwind v2, but I don't see any improvements over CSS.
It's true that I haven't tried it. And I probably wouldn't, at least until someone can formulate at least a hypothetical advantage.
Hmmm... as a non-tailwind user I just took a look.
Maybe this shows my age, but it kinda looks like an extension of <b></b> <i></i> - you know, that stuff that we moved away from a long time ago...
Isn't this losing the point of CSS - that our "content is separate from its styling"?
I know I know, we often have to adapt our HTML to allow the styling to work properly, but this is only really true for layouts, not for colors / padding / margin / fonts etc.
I understand that we now have people writing React apps and componentising everything, but if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change next time a designer decides to give your webapp a makeover?
> if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change
If, instead, you litter your code with my-brilliant-semantic-class you create a different kind of problem. Requirements change and my-brilliant-semantic-class won't be sufficient. Now the choice is; alter my-brilliant-semantic-class and suffer all of the unintended side effects or abandon reuse and make another-brilliant-semantic-class.
The likely choice is the latter and so applications become masses of ad-hoc, partially finished, inherently flawed styling abstractions scattered hither and yon among directories full of redundant styling artifacts, half of it long dead. How is that a benefit to some future re-designer?
> next time a designer decides to give your webapp a makeover?
I figure the odds of one approach vs the other being the greatest benefit to some future re-designer are about even, and my guess is as good as yours.
One underrated problem with semantic naming and classic CSS is having to repeatedly do one of the two hardest problems in computing, that is naming things, 5 times per minute while you're trying to be creative. You constantly have to context switch between "design/creativity" and "logic/pragmatism" mental modes. It's awful, exhausting and doesn't enable any state of flow. The productivity loss is enormous.
> "the curved sweet yellow food that grows on trees"
You have (some variety of) cavendish bananas in mind. There are red, pink and blue bananas. They're not all sweet. The plants they grow in are not always "trees" but rather large fern like plants.
And then that day arrives when you are required to style some variant of 'banana' you are forced to decide: do I break the world by messing with banana or do I make new-banana?
In my experience the “one-off items” are far more common, simply because every one thing I do reuse will typically have several child elements. Why am I naming the styles that represent the title of a contact card if I never use it outside of the contact card—which itself is probably included by referencing a file called “ContactCard.html” or whathaveyou.
Of course, there’s no right or wrong answer here, and I suspect it very much depends on what type of web systems you are building. I feel the entire debate is basically a special case of the question “do you make websites or web apps”.
You can still call it a banana in Tailwind, but you'd do it with a component in your framework rather than a class name.
If you plan on using bananas multiple times throughout your app, aren't you going to be pulling that out into a component anyway? So define that it's curved and sweet and yellow in that one place, and then insert an instance of it wherever necessary.
I really like Tailwind, and was excited to use it for a new application at our company. However, I find the lack of standard component classes (modal, card, button, wherever) pretty limiting.
This makes it difficult to have open source Tailwind components that can be imported and themed differently for your apps.
Even after buying Tailwind UI, they are basically just code samples that we'd have to copy into our own libraries and maintain.
Again it's a really cool library, but feel the approach is probably better for smaller apps and teams.
Daisy UI might help with this, but seems pretty small at the moment. https://daisyui.com/
Ironically, I had the opposite opinion on clicking the link to the blog.
Sure, a Galaxy Fold is a pretty niche user device, but its genuinely the worst first impression of a mobile website I've ever seen, with everything weirdly scaled to sit in a narrow portion of my screen (other dimensions linked to px values on the video embeds maybe?). Had to load the link a few times to confirm I hadn't just accidentally zoomed out, since if I do zoom in it looks like a normal mobile stylesheet
https://pasteboard.co/V0Cy3etIngpY.jpg
Arbitrary Properties (inline styles) can now use constraints (css vars), media queries, and hover/focus states, the reasons Tailwind said you should use their utility classes instead of inline styles in the first place :)
I used to use Zurb Foundation or Bootstrap for my personal projects but I found these two frameworks required me to use their javascript and their JS does not play nice always. So I moved to Bulma and that has served me well so far. I like not having to worry about CSS (it drives me nuts) and I would like to just focus on building components and functionality.
Kind-of. People usually pick one or the other, but they're not alternatives in the same sense as Bulma vs. Bootstrap vs. Zurb Foundation.
Bulma has opinions about structure and style, and its value proposition is providing out-of-the-box components so you can skip spending brain cycles on that design work. At a high level, Bulma believes projects reuse a lot of design patterns, and those shouldn't have to be rethought each time you need them.
Tailwind doesn't care what you want your project to look like, or how it's structured. Tailwind's value proposition is streamlining you choosing your own design, and removing footguns from that process. At a high level, Tailwind believes cookie-cutter styles are typically less reusable than you hope, that you should instead optimize for tailoring design patterns to each place they're used, and that style reuse is better implemented by e.g., React components than a CSS framework.
Great! but the docs are on the offensive side:
- "Yes, send me all your stupid updates"
- "The new print modifier lets you style how your site should look when animals(in strikethrough) people print it."
Because by definition offensive has to do with how people receive something. I love the library, will continue using and donate, I would prefer the docs not to assume that people that print papers are animals. That's all! Take it or leave it.
i read that as sarcasm delivering a subtle critique on digital consumption in 2021 and how print has been killed by digital media (for most folks). obviously they acknowledge that people still want to read in print, otherwise, why would they bother to add this feature?
maybe i'm reading into it too much, but i don't think they think print readers are inferior.
Speaking as a non-cargo culting developer, Tailwind is evil. It doesn’t understand CSS nor the document hierarchy it depends on, and almost every project that has had a frontend developer touch it has turned into an unmaintainable mess.
Not to mention the tooling overhead. I had to revert countless JSP files due to strange compilation bugs that resulted in classes only sometimes(?) being added.
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
It’s not traditional css and you need to accept that if you want to work with it. It has a load of benefits in a different dimension to css, and personally I think they’re worth the trade off.
My main issue with it is the inability to control the order of precedence with the css rules. It’s mostly fine, but when you have runtime rules around, say, colouring text based on a few different variables, it turns into a bit of mess. Unfortunately because of the way it works there’s no way to implement “last rule wins” at runtime.
I use tailwind with Angular, and we solve this with using [ngClass] to add/remove the class. You could do something similar with plain JS as well, and I imagine in most frameworks. Although yes, that is annoying to have to deal with.
Say you’re balancing a bunch of colours where it’s say mostly black, but you need to change to green in some case and red in others.
In css this is easy because you can say “for this situation I want this colour”. And you can order your rules in a sensible way so the more specific cases trump the general ones.
In tailwind you can’t do that because “text-red text-black” etc is ordered by the order in which the utility classes are added to the page. So you have to make sure you don’t add two conflicting classes.
That case doesn’t seem so bad, but once you get a few different properties to control and a few different scenarios, it gets pretty messy.
There is a dead sibling comment which I will repeat with a bit kinder words, and with a different caveat.
As a frontend developer I don’t like Tailwind for several reasons, it brings the styling into the structure. As a frontend developer Tailwind is at a forefront of what I would consider bad practice and encourages a code style which would be a nightmare for me to maintain.
That said. Tailwind seems to be loved be people who are not professional frontend developers. It seems to be just the right tool for people who are not necessarily proficient in CSS. And perhaps people like me (and the dead sibling) need to learn to let go and allow other people to have the tools which makes it easier for them to do the job which they are not experts at. For that reason I understand Tailwind, even though I don’t agree with it.
I think TWCSS' argument is that we always were bringing the styling into the structure.
Show me a site that has CSS Zen garden style replaceable stylesheets that totally overhaul the nature of the site. It's incredibly rare and almost always not worth the effort. What business says "I want to overhaul the styles of my application but change no structure at all. I'd posit it's near 0.
Even if that's your goal, and I'd argue that it shouldn't be, you can still do that with TWCSS and the @apply keyword. You can write your generalized names then apply whatever twcss keywords you want to them separate from your
document's structure.
If your overhaul amounts to changing a "theme" you can easily do that with twcss. In fact, that's basically the point.
I am a professional frontend developer and I love it.
I like Tailwind because it brings styling into structure. Dealing with external CSS has always been really challenging for me, and I've always heretically used inline CSS.
I mean header files are OK, and professional C developers probably love them, but not having header files is kind of great too :)
I think your comment has a lot of merit. Personally Tailwind has been awesome but I think it's because it makes all these abstractions for you. It also forces less experienced developers to follow this abstraction rather than making their own, which usually ends up as a ball of spaghetti.
I have a similar comment elsewhere in the thread but it applies here too, I think: the main drawback of Tailwind is that it's extremely general. I'd imagine a well abstracted, focused, domain-specific set of CSS created by experienced frontend developers will be much better within that domain.
I have said it many times, but I'll have a go at it again.
The reason why inline styles got it's bad reputation is mainly because we used to have no way of building reusable components.
Nowadays, everyone and their mothers are using some kind of frontend framework that allows you to reuse components, so your inline styles can be mentioned once and used everywhere. It's not a problem anymore.
Pair your tailwind with styled components and you can finally reach the dream of semantic HTML.
I am a professional frontend developer working on a large-scale react application and I love tailwind. I am proficient in CSS, but having colocated html (well, JSX) and css makes so much sense, and the design system really helps fast iteration while also keeping things looking nice.
do you prefer the structure in the styling or the styling in the structure?
i prefer the later. with styling in structure if i make a change in one place, it effects the one thing i intended it to
with structure in styling, if i change one thing, it may impact many other things, some of which i might not intend to and are sometimes unknowable at the time of the change
I usually do component scoped styles (e.g. shadow DOM, Vue’s SFC, React’s styled components, etc.) and the changes I do only affect the component where the changes occurred. So to answer your question, I like structure in styling, but with component scoped styles that structure can be pretty minimal.
If I change the structure I usually have to change the style anyway. And with component scoped styles, I know exactly where I need to do that (usually in the same file, or in a file referenced by the component).
As for shared styles I use the cascade which can penetrate the component boundaries, e.g. font-size, color, but usually --css-custom-properties.
My experience (and the experience of thousands of others) is that in practice, an approach like Tailwind is much more maintainable, even if it's superficially ugly.
At the end of the day it's a lot easier to understand what's happening in a template where you can see all of the styles directly attached to each node instead of having to map things together in your head across multiple files.
For example, for me at least I can't believe how much more difficult it is to look at your average CodePen demo and understand what is doing what at a glance vs. looking at a Tailwind template. With traditional CSS there is just _so_ much indirection in comparison.
Not OP, but I'm not worried about saving how many characters I type. We have autocomplete that fixes much of that problem anyways. I'm more worries about being able to read things others have written or even my own code when I come back to it. I tried Tailwind, and get the praise, but I still find it takes more time to read and understand than CSS. It just seems cluttered, and I couldn't get over that.
I used the JIT version recently on a new landing page with code completion for class names in my IDE and found it great. The distance between what I'm picturing in my head and what I have to type to see that on the screen felt so much shorter and less fatiguing than the standard CSS approach.
With the regular way, to style something that's probably not going to appear elsewhere, I'm having to: come up with class names, annotate the HTML with them, repeat some of this annotating in a CSS file, jump back and forth between files to tweak the styles, use the web inspector to figure out which CSS class is overriding another then jump to the right CSS file to fix it etc.
Tailwind classes are also faster to type and flip between when you're experimenting (e.g. editing "mt-5" to "pb-3" vs "margin-top: 4.25em" to "padding-bottom: 2.75em") and you get less distracted because it has sensible defaults and helpful guardrails (you rarely need all the possible attributes and range of parameter values CSS has available).
I also rarely had the super irritating and common CSS scenario where you edit a style and it doesn't change and you have to go investigate to find out why e.g. something is overriding something, your selector is wrong, and even after all that maybe you undo the edit because it doesn't look good. Plus you no longer have the fear that tweaking a shared class to going to break some completely different page.
I feel that beyond some building blocks, trying to create reusable CSS classes with cascading styles has similarities to using excessive abstraction and deep OOP class hierarchies in regular programming languages to avoid a little duplication.
I also don't have a problem with styling stuff appearing in my HTML files either as long as the right HTML tags are used around the data. HTML files are already full of class annotations and divs that are only there for styling yet this doesn't cause a problem to e.g. browsers, screen readers or crawlers.
The trick with CSS is to write semantic HTML and avoid div, span and css classes. You can of course inline css too (used mostly for optimization to prevent layout shift, but is also fine for elements/classes that are not repeated, such as the top menu, top banner/intro and header/footer)
> The trick with CSS is to write semantic HTML and avoid div, span and css classes
This experiment has failed though. CSS isn't powerful enough to style HTML however you want without having to add a soup of extra divs and classes that are only there for styling. No large website today works otherwise.
HTML is still semantic when it contains styling markup (in the sense that a computer can read and understand the structured data from it) so I'm unclear what benefit is being missed out on. Whether you call a class "home-cta-subheading" or "text-center" so you can apply some styles doesn't make a difference to screen readers, browsers or search crawlers either.
Yes, you should always be using the elements/tags with the most semantic meaning you can. When you need to add divs, spans and classes for styling reasons though, they're going to be ignored by screen readers so there's no problem here.
The example on the Tailwind front page is pretty good semantic wise. Here's my version:
<figure>
<img src="/sarah-dayan.jpg">
<blockquote>“Tailwind CSS is the only framework that I've seen scale
on large teams. It’s easy to customize, adapts to any design,
and the build size is tiny.”</blockquote>
<figcaption><b>Sarah Dayan</b>Staff Engineer, Algolia</figcaption>
</figure>
Now without modifying the HTML, how would I get the author's name only to appear on the right of the author image with the other text underneath? And add a line break before the company name? And make the word "tiny" use a small font?
And if you need to modify the HTML, were the extra tags added 100% only for semantic reasons and not for presentation reasons?
The original challenge includes questions that apply only if the resolution involves HTML modifications, which (contrary to the earlier text viewed in isolation) indicates that such modifications are not invalid in response to the challenge.
It's possible if you substitute "without modifying the HTML" with "without modifying the HTML for styling purposes." That's because the HTML is adversely and unnecessarily bare-bones, missing semantic markup that the CSS could hook into if needed. Specifically:
- There must be a logical reason for wanting to make the word "tiny" use a small font, so that word is missing a tag that represents that prosaic intent. I've used <small>, but depending on how you'd verbalize the word "tiny" (which is what you're representing both with making it use a smaller font and with wrapping it in a semantic tag), you might also wish to use <em> or another tag.
- Similarly, there is missing semantic markup inside the <figcaption> for the person's name, job title and company. Those are semantically separate concepts for each other, but for some reason the example HTML was written without semantically differentiating them. This is much like trying to represent two paragraphs of prose with just a couple newlines, rather than actually wrapping each in a <p> tag. To fix this error, I've added tags as necessary to implement the semantic hCard microformat -- independently of styling.
- I've also added the recommended attributes to the image tag, because it was missing. (And for the sake of the Codepen, I replaced the image's src with a placeholder so as not to hotlink from tailwind's site.)
Given those improvements to the semantic structure of the HTML, here's how you can make the author's name appear on the right, with the quote underneath, with a line break before the company name, and "tiny" in a small font: https://codepen.io/Kerrick/pen/KKXgPYw
> There must be a logical reason for wanting to make the word "tiny" use a small font
> - Similarly, there is missing semantic markup inside the <figcaption> for the person's name, job title and company. Those are semantically separate concepts for each other, but for some reason the example HTML was written without semantically differentiating them.
Presentation/visuals aren't always tied so closely with logic though. "To make it look nice" is a valid reason. As I said, this experiment has failed. All modern website designs use divs + classes everywhere for styling. I agree extra semantic tags would be useful but at some stage you're going to be forcing yourself to come up with semantic reasons to add a tag when there isn't one.
> I've also added the recommended attributes to the image tag, because it was missing.
Related: alt="" is best practice for when an image tag is for presentation purposes only because images don't have to be there for semantic reasons.
I tried it just for the lolz and without changing a single bit of HTML. It's absolutely disgusting and nobody in their right mind should do this EVER! Only tested in Chrome, it might fail in other browsers. And on mobile it will very likely break.
You don't use CSS to move stuff around. If you for example want to place paragraph-1 below paragraph-2 you simply move it in the HTML.
And if you want to add a line break you add <br> in the HTML.
If you want to make a word tiny, you can use the <small> HTML element.
The trick is to keep things simple.
Then when you have mastered the rules, you can break the rules. eg. when you can style semantic HTML however you want without adding div's and CSS classes, that's when you can start adding a little div and class here and there just to keep things even more simple.
Simple code is most of the time faster to load, and easier to maintain.
> CSS isn't powerful enough to style HTML however you want without having to add a soup of extra divs and classes that are only there for styling
Totally this. We say we've come a long way from using tables for layout, but for example you still can't use Flexbox without at least some non-semantic .stuff-container and .radio-with-label junk. Decoupled HTML and CSS have failed in the real world, outside of pet projects.
You've never put a number of elements together in a div, and added a class and styles to that div rather than each individual element? You should try it out.
Take a look at the https://tailwindcss.com/ page and search for "div". Can you replace them all with more semantic tags? If not, can you remove them and still style it the same way?
You need divs all the time for layout (e.g. to group parents/children in the right way for flexbox), to target content for styling (e.g. putting a div around the name of the author to make it blue when you otherwise wouldn't tag it) and to get around CSS quirks (search for "wrapper div" for examples).
The discussion is not about the semantic expressiveness of HTML. There are certainly limitations, but these are limitations of HTML. The discussion is about whether or not "tag soup" (excessive HTML elements) is necessary for styling with modern CSS. I cannot think of an example of where it is.
> Can you replace them all with more semantic tags? If not, can you remove them and still style it the same way?
I looked at on the first four examples, but my responses are yes and yes.
Take the figure example. The first div, which groups blockquote and figcaption, is extraneous and unnecessary for the end styling result. The second div is not extraneous because it exists for a purpose. The purpose of the second div is to place emphasis on the name or make it stand out. Thus, it should be changed to em. The third div is extraneous. With the HTML in place, grid it up.
You have the container (figure) with two columns and two rows. The image sits in the first column spanning both rows. The blockquote sits in the second column on the first row. The figcaption sits in the bottom right-hand corner. Then tweak to get your img and other parts as desired (e.g., width, spacing, font-size, etc.).
> You need divs all the time for layout (e.g. to group parents/children in the right way for flexbox) ... to get around CSS quirks (search for "wrapper div" for examples).
Sometimes flexbox is the wrong tool. Sometimes floats are better. Sometimes grid is better. If you find yourself reaching for extra HTML elements first, you should stop and re-evaluate whether your approach to achieving that layout is appropriate.
On quirks, my experience is that "quirks" are rarely actual quirks. They are usually a limited understanding of HTML and CSS.
Can you link to any complex designs you've worked on that only use semantic HTML elements and minimal divs/spans? Are you saying that any modern website that uses wrapper divs is from lack of expertise?
> Are you saying that any modern website that uses wrapper divs is from lack of expertise?
That's a loaded question. CSS frameworks (or tables, or div based designs) are also used because they save time when iterating, not because of a lack of expertise.
Just open up the inspector on any major website like Facebook, Twitter, Github, etc. How complex is the UI you typically work with? Once you get to a certain level of complexity, it's literally not possible to not end up with the div soup.
Not eparating concerns also fails VERY hard, but that bites you in the arse when you least expect or want it (unlike writing good CSS which takes only patience and studying).
There's a reason why inline styles and important! were to be avoided
Exactly. Also you rely on the development criteria and developers switch jobs and they have different mindsets for architecture. The CSS ends with a soap of architectures and technical debt.
I agree. I think the real crux of the issue is that people find CSS hard, and are embarrassed about finding something that's "just a style sheet" hard, so they flock to more complicated alternatives.
I'm really glad I just powered through that point and let myself feel dumb.
what does semantic html has anything to do with css. Doesn't this make the look and feel of the page easily break on any change on the markup structure and content?
Also does this comment even has a point? Like if we do what you suggest then no need of tailwind?
> I used the JIT version recently on a new landing page
Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability.
Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with several `class="..."` strings across multiple files, possibly with class names in arbitrary order, possibly mixed with logic from other templating languages (be it from Django or JSX or whatever). So you can't just grep to achieve the objective of changing styles in one place to affect all instances of some semantic group.
Personally I think comparing Tailwind directly against traditional CSS as a whole is painting in too broad strokes. There's a lot of CSS methodologies and also a lot of bad practices (e.g. using SASS indentation as namespacing mechanism and then running into the old problem of specificity), and comparatively, there's a lot more than Tailwind in the atomic CSS space, and more broadly, in the compiled CSS space.
Utilities like Bootstrap (e.g. `class="btn btn-primary"`) for example share many benefits of both atomic CSS and "good" subsets of traditional CSS practices (namely, you get memorable short class names, which are also organizable along semantic lines). So there's definitely more shades of gray than just "atomic-css-is-the-best-thing-since-sliced-bread" vs "looks-like-lazy-style-attributes-lol".
I am going to give it a try. The argument against using it is that it defeats the purpose of Tailwind, but I think its useful to start by spraying classes until things work and then moving those classes into e.g. btn-primary once the styles become stable and need universality.
Yes, @apply exists, but is generally discouraged (and the rationales are given right on that page)
> If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you
Approaching it with moderation is probably worth trying though
It's the same as any DRY or optimised code: taking time and effort to make things overly DRY or optimised up front is a waste, building stuff out and then refactoring when you realise it's going to be repeated is a better workflow. With tailwind, that's simple because you take your string of class names, slap an @apply on it, and then use the new classname instead. No, it's not significantly different from just writing CSS then, but it's the workflow that's changed that reduces the friction between prototyping and then refactoring into a reusable design that makes Tailwind nice to work with in my experience (and I'm using it for a large-scale commercial project, not a landing page or static site).
I'm pretty sure the creator's intention is that you basically don't use @apply at all, except maybe edge-cases where Tailwind simply can't be used (for example, I think before v3.0 you couldn't set print styles, i.e. @media print)
The intended method of not repeating yourself in Tailwind is using a framework, and writing the styles in the template of the component.
In the context of component based development, react etc., I believe what you describe is actually very beneficial. Think about a case where instead of doing something <button class="btn btn-primary"> you write an atomic component <MyButton> which uses tailwind internally.
With this workflow:
* There are no global styles that can have an unknown or unexpected impact on the application when modified.
* The component's style is completely encapsulated. It can be placed anywhere in the application without worrying about inherited styles causing problems.
I mentioned downthread about a project called Styletron, which has styled-components-like devexp, but compiles to atomic CSS for the bundle size benefits.
Another variation I've seen is a combination of atomic CSS and Mithril.js' hyperscript selector syntax, which lets you do stuff like this:
I use Tailwind utility classes extensively to create reusable components in a Rails app using GitHub's ViewComponent gem (https://viewcomponent.org)
Occasionally, I'll use @apply directives to DRY up something that isn't easy to encapsulate at the component level, but 95% of the time, I can easily get by with utility classes.
I try to avoid using hyperbolic-sounding language like 'revolutionized,' but Tailwind + ViewComponent has basically revolutionized the way I build user interfaces in Rails.
I had the same concern at first. I remained skeptical during my first couple days working with Tailwind, but came around pretty soon thereafter.
I realized that all of my semantic CSS classes might as well have been inline CSS for all the good they were doing me on reusability. Utility classes are faster to work with, and, as long as you’re componentizing everything, still going to give you consistent styles across your product.
The usage of utility classes only become an issue if you have unnecessary duplication of components. Say, two buttons that should be the same but are implemented in different places.
IMO one of the interesting parts of functional CSS is that we can apply the same tactics we use for organising code to organising the styling.
Also, with separated CSS, and especially with semantic CSS, there is often a fair amount of duplication that happens in the CSS code itself, which we programmers tend to be very forgiving of. Giving Tailwind more scrutiny than we do for our CSS ends up making our code more consistent, less duplicated and better in general.
My experience with Tailwind + ViewComponent has been great as well. I've also had a lot of success with adding Sorbet typing to the view components. I often use Sorbet enums as view component options. The extra type safety in the view layer is very helpful.
We recently started using a combination of tailwind and BEM instead of bootstrap.
It means that we can have our own custom "button button--sm" classes - a single place to change general styling - and on top of that get all flexibility of the tailwind utils for edge cases.
I don't think it's perfect, but it's so far much more flexible than bootstrap, and we don't need to duplicate loads of classes for each similar component.
> Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability.
It doesn't matter, you can have an entire newspaper and perfectly done in functional css with incredible results without having to mastermind any architecture.
Tailwind always looks like a cool evolution of Tachyons [0] to me (with a build step). On the other hand, tachyons is really simple, you just drop it into your project with no build required (or drop the sass in), and I've never really felt like it was missing any features I wanted.
I wanted to love tachyons before Tailwind was a thing. I jumped to Tailwind as soon as it released because it was configurable. The tachyons way of changing the defaults, such as colours or breakpoints, last I checked years ago, was using search/replace or forking the repo and adding your changes. Eh, no thanks.
Tailwind is better in every way, and JIT is a killer feature.
> Tailwind is better in every way, and JIT is a killer feature.
I dunno, the smaller dev build from JIT is great, but it breaks my in-browser design workflow. Only the CSS styles needed are generated, so I can't make in-browser tweaks to see what a different padding/margin/other-property looks like.
I don't know that this solves their problem though. Even with the in-browser JIT, there is no class for the browser to autocomplete. One nice benefit of the old compiler, was every single class was available with autocomplete in devtools. Granted, if you already know the class you want to tweak and can guess the next correct step in the scale, it's fine, but for new code you're writing for the first time, I can see their argument.
For customizing it, we copy the sass files and replace variables for colors and breakpoints. It's not what you usually do with a dependency, but Tachyons is feature complete and has very few (read: human patchable) updates. It's an easy way to have a custom style-guide in sass within a few tweaks.
It's a pretty small and readable codebase, so while there's a downside that you can't upgrade it by incrementing a version, the upside is that you don't have an opaque upstream dependency and you can cut any fluff you don't need (though there isn't much).
Hey great question! I was wondering that as well!
They're both considered 'functional CSS' libraries.
I used Tachyons after spending 5 minutes trying to figure out the build process for Tailwind and Tachyons worked great for the single site I used it on.
Tailwind is more like an editorialized version of all the features available in "vanilla CSS" than it is a UI library. Tachyons is a small, tiny UI library that enforces (ugly) standard defaults.
Also, the naming of classes in Tailwind feels much more natural — the tachyons naming is condensed to the point of being abstruse.
I've had the feeling that Tachyons is a bit abandoned, no? The album component/example [0] has been showing 404 images for a while. The last release on GitHub is from 2018.
CSS frameworks don't ... need? to be state-of-the-art/updated all of the time (I get that), but at the same time, like anything else, once a component/css/etc. library falls behind, it (can) become harder to make it work with other tools.
i.e. it's hard to abandon the bandwagon of constant new releases, as the second that you do, "stuff" sometimes starts breaking. This is of course a very general observation that doesn't apply to everything.
It's more like a series of templates. You copy them into your project and customize them. I used them for a big project and found them to be absolutely fantastic. It's a lifetime license for unlimited projects - the time I saved was very quickly worth the cost.
I wonder what the future of code-splitting with Tailwind will be. With JIT and a large web app, it's easy to ship a massive CSS file even if 90% of the rules are unused on 90% of the pages.
Tailwind author here! Do you have an example of a site using the new engine that is shipping a massive CSS file where most of the styles are unused on most pages?
The Tailwind website is only 36.9kB of CSS and it likely includes more classes than any other Tailwind site on the internet by virtue of the fact that it has to provide visual demos for so many of the classes. I don't think 36.9kB is massive personally, it's much smaller than the CSS of almost every website I've checked.
I want something like this which includes a few ExtJS-like grid (as in data table) and treelist classes for "enterprise" CRUD want-to-be-spreadsheets-when-they-grow-up apps. (point being, everything in a single toolkit)
So much of enterprise IT is little more than glorified form fill-in, and yet so few CSS/JS libraries solidly cover these use cases.
I've been a Bootstrap user for a long time, but I recently made the jump to Tailwind. It's not the revolutionary upgrade I was hoping for, but it's nice evolutionary step in the right direction. It's quite intuitive, but it doesn't get rid of most of the frustrations that come from doing layouts, as those come from the design of CSS itself. `@apply` makes the upgrade worth it though, it's easy to make custom classes from the Tailwind elements.
The one thing I don't like is that the culture around Tailwind seems a lot more proprietary, like you're getting three quarters of a product that you need to buy the rest of, whereas Bootstrap felt like you got everything you could ever need for free.
If you're talking about Tailwind UI[1] — I use Tailwind extensively and have basically never looked at Tailwind UI. It's just useful snippets of HTML styled with Tailwind. It is by no means required to get value out of Tailwind.
I'm not sure what you mean by proprietary culture! Based on the fact that I've pretty much never seen anyone talk about it, I would guess (total guess, no real knowledge) that no more than 1% of Tailwind users have paid for Tailwind UI.
That's what I mean, though. $250 for some styled HTML! I think that's crazy. Compare with Bootstrap, which has basically just as many snippets simply as part of the documentation.
I'm saying you don't need that and almost nobody uses it. There are tons of snippets in the Tailwind documentation. I just scrolled down the side nav and clicked a page at random:
Ok, I can see how if you're used to relying on the Bootstrap examples[1] you would experience the lack of such examples as a big hole in the TW docs. I guess I would argue that those examples don't go very far at all in a real-world application.
I don't think it's crazy. It's a good business model for them and a way to monetize their work on Tailwind.
Spending $250 in order to get a well implemented and well designed HTML and CSS framework for your app sounds like money well spent to me, depending on the circumstance.
If you're an expert or pro at CSS, then yes, that's expensive. But if you have a little budget and need to make some quick progress on a new site, it's a great deal. Hiring someone who can recreate these designs and give you exactly what you want is probably going to cost more than $250.
I paid the $250 and it's an incredible time saver for prototyping & making decent looking, fully responsive internal apps for clients. Based on the number of billable hours saved, it's paid for itself many many many times over.
You have to do literally everything from scratch with Tailwind though, for example I never realised how much work is involved in a simple avatar dropdown / logout component (hidden full-screen button). Tailwind is much closer to raw CSS than Bootstrap. That's not a criticism, it's just a different value proposition.
My favorite thing about Tailwind is all the sites that offer copy-and-paste components, ready to use (since you already have all the CSS, you just copy HTML-and-classes and it looks exactly how you'd expect). Sure, you can pay for TailwindUI, but you can also just browse (free) components from e.g.
Most of the sites I put together this year used an amalgamation of components from those sites for basic structure, and then just get customized to the brand and site function. I hate writing raw CSS and I would also hate writing raw Tailwind.
It seems proprietary because there are ad links disguised as documentation links. You can't click "Components" anywhere on TailwindCSS.com or you'll end up on TailwindUI.com pricing page.
It's fine that they want to make money but it's very confusing for a new user. Ultimately, they might make more money by dropping the shady links if it's turning away enough new users.
I can maybe see how that could potentially be confusing to a brand new visitor, but how is it shady? It's a clearly labeled link that does take you to components made with tailwind. Are they supposed to link to all the freeware out there first?
Gotcha. Yeah, phrased like that, I can see your perspective better (and I even agree!). Maybe a little external site icon and moving that link to the end of the nav could clear that up.
Just started with tailwinds and similiar thoughts. A framework like this without components.
Try daisyui as a tailwinds plugin. It comes with the missing components. It also allows you to replace your 80 character style for buttons with btn btn-primary.
447 comments
[ 0.25 ms ] story [ 366 ms ] thread0: https://tailwindcss.com/docs/upgrade-guide
1: https://github.com/tailwindlabs/tailwindcss/blob/master/CHAN...
https://news.ycombinator.com/item?id=22422873
https://news.ycombinator.com/item?id=28004515
https://news.ycombinator.com/item?id=18084013
https://news.ycombinator.com/item?id=26422286
https://news.ycombinator.com/item?id=25332101
From reading the previous threads, large projects are where it (apparently) really shines. Personally I didn't find it useful at all, but obviously YMMV.
Now I'm back working on a project with a team that is staunchly against TW and I'm having a hell of time getting back into the rhythm of naming things. Everything just kinda looks like a box so I'm having to go back to the the designer or team to pull out names for things.
Definitely looking forward to when I can go back to using Tailwind at work and on personal stuff. The cognitive overhead is real.
Also, you can prototype your stuff and then use the "extract" functionality to create components with nice shiny class names.
Components are a better way to segment semantic pieces of layout. Styling is lower level and having to name each atom of it is an enormous PITA.
I'm happy they have also expounded upon some of the more common FAQs on the homepage, including the extraction to components.
Props to the team though - I feel like this is something I'll try out for a marketing site.
Another less popular one that I have had my eye on for some time is Mantine. It seems very polished and composable.
[1] https://chakra-ui.com/docs/comparison#the-runtime-trade-off-...
Thanks for helping me think through it further!
But a swell of less opinionated offerings [2] [3] [4] (more and more the popular anyways) work well with Tailwind. In fact, when writing your own libs, exposing a className prop makes them painlessly customisable.
0 - https://mui.com
1 - https://ant.design
2 - https://www.radix-ui.com/docs/primitives/overview/styling
3 - https://react-table.tanstack.com
4 - https://react-spectrum.adobe.com/react-aria/
The way HTML forms (in particular, but also things like tables) are stuck in a not even good for the time '90s level of functionality is an under-appreciated drag on all web development, IMO. So very much wasted effort, wheel-reinvention, brokenness (a11y, especially) et c. for shit that should have been built-in years ago.
It absolutely is, but things are changing! Come help us get better form widgets built into browsers at at https://open-ui.org/.
The website's a bit behind, the Discord and GitHub issues are where most discussion happens. We need people who know hte pain points to help us.
And let me repeat what every Tailwind fanboy (like me) states every time this project is on HN: don't knock it till you've tried it. Look at the animated example in the front page. You'll never be able to iterate that quickly with CSS.
Design in the browser with browser technology, it’s just boxes, gradients and shadows for industrial level web design at the moment. You really shouldn’t even be designing in a tool like Photoshop or Figma given the current design paradigms.
You will not iterate faster than what I am suggesting.
Edit:
The reason why we are here, why something like Tailwind and MUI exist, is mostly because we need an abstraction layer to do what a designer does on a whim. You can flick a shadow on and off on a Photoshop layer and mess with the subtlety of a drop shadow with a slider. If a designer makes a fickle change, the developer needs this abstraction to make the fickle change as fickle as the thought that made it. That’s why you have all these quick utility methods. The designer is one layer (no pun intended) removed.
In 2021 (2022 really), it’s shocking the amount of latitude we give designers to still not be able to do CSS. A half competent designer could have a modest style sheet that mostly captures their design instincts, yet here we are, unable to capture their whims and must now have an albatross utility library to have manual laborers capture the translation - all because … they still won’t learn basic shit.
And for what ultimately? These aren’t baroque art pieces, it is ultimately boxes with an aesthetic applied, all very describable with semantic HTML and CSS. But alas, our brilliant artists can’t be bothered. Here, send me your masterpiece so I can transform it for you.
Take the bootcamp on web dev. You are literally the people I want going there. Not the Classics major that needs money because they picked a stupid major. It’s you guys that need it, and deserve it.
This is why all but the very best flat designs (which does not always correlate positively with the size or reputation of the firm turning them out—looking at you, Google) look to me like something I'd have turned out for a quick feature demo circa '05, with everyone at the table agreeing that, however nice the feature, a designer definitely needed to take a pass at it before it was released.
Let designers focus on designing, developers on developing.
The words of an open mind.
Each of those adjectives are very open to disagreement.
Does nobody remember themeing forums software like vbulletin? Designers weren't allowed to touch the markup in the slightest and yet so many amazing themes were made. Why? Styling wasn't hard-coded in the markup. Hell, remember the insanely customized old.reddit subreddits?
FYI I'm a recent Tailwind convert so I agree that Tailwind is good, but your comment is like saying Tesla cars are great because they aren't horses.
I won't argue if one is better than the other.
And, also, that it is made by and for the JS crowd that doesn’t understand CSS nor the document hierarchy it depends on, while simultaneously considering it unworthy of any learning efforts since it’s a girly making-it-pretty addition to a markup language, not a real professional STEM-grad-grade programming language.
In practice, maybe coupling the two doesn't actually do much harm, provided consistency of approach is maintained and it doesn't go quite as far as inlining CSS all over the place.
https://news.ycombinator.com/item?id=29502044
So far with this plugin/extension design i've not found a way to use Tailwind and also retain nicely sized CSS.
This 3.0 release has its biggest feature be JIT. If you read the linked blog post, CSS is no longer purged but generated dynamically by reading your source files and generating the TW classes you use. It's not tree shooken anymore
Whether or not you're using Javascript doesn't matter (I guess unless you use the new CDN script which I haven't tried), but it does need to be run in a build system.
Will be interesting!
The creator of Tailwind posted a comment in this thread that the Tailwind website itself, which uses way more Tailwind classes than a normal size would use (for demoing everything), only spits out 36.9kB of CSS.
https://news.ycombinator.com/item?id=29503769
- One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes.
- Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive.
- Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways.
- You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development.
- Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while).
- There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[1] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows.
The main theme to be aware of: proponents of atomic CSS rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[2] vs hyperlocal development workflows interact with your organization's design culture.
[0] https://en.wikipedia.org/wiki/APL_(programming_language)
[1] https://www.styletron.org/
[2] https://en.wikipedia.org/wiki/Aspect-oriented_programming
It's true that I haven't tried it. And I probably wouldn't, at least until someone can formulate at least a hypothetical advantage.
Not the blog post, the main landing page, ie https://tailwindcss.com/
However, there's definitely a very prominent youtube video on the linked page. https://tailwindcss.com/blog/tailwindcss-v3 That's the one I was talking about.
Maybe this shows my age, but it kinda looks like an extension of <b></b> <i></i> - you know, that stuff that we moved away from a long time ago...
Isn't this losing the point of CSS - that our "content is separate from its styling"?
I know I know, we often have to adapt our HTML to allow the styling to work properly, but this is only really true for layouts, not for colors / padding / margin / fonts etc.
I understand that we now have people writing React apps and componentising everything, but if you litter your code with styles such as "font-semibold" and "font-sans", isn't that just going to mean you have a million places to change next time a designer decides to give your webapp a makeover?
If, instead, you litter your code with my-brilliant-semantic-class you create a different kind of problem. Requirements change and my-brilliant-semantic-class won't be sufficient. Now the choice is; alter my-brilliant-semantic-class and suffer all of the unintended side effects or abandon reuse and make another-brilliant-semantic-class.
The likely choice is the latter and so applications become masses of ad-hoc, partially finished, inherently flawed styling abstractions scattered hither and yon among directories full of redundant styling artifacts, half of it long dead. How is that a benefit to some future re-designer?
> next time a designer decides to give your webapp a makeover?
I figure the odds of one approach vs the other being the greatest benefit to some future re-designer are about even, and my guess is as good as yours.
You don't refer to bananas as "the curved sweet yellow food that grows on trees", you simply refer to a banana as a banana.
Sure, for one off items it might not make sense to name it but when you create design patterns then it's incredibly useful to be able to name things.
Yes it may be hard and require you to think, but just because that is so does not make it bad necessarily.
You have (some variety of) cavendish bananas in mind. There are red, pink and blue bananas. They're not all sweet. The plants they grow in are not always "trees" but rather large fern like plants.
And then that day arrives when you are required to style some variant of 'banana' you are forced to decide: do I break the world by messing with banana or do I make new-banana?
In CSS land however you wouldn't break the world for a different banana, you'd simply add another class for the variant and style appropriately.
.banana { // generic banana styles }
.banana.musa-velutina { color: pink; }
Of course not all decisions are going to be as straightforward, but I do think that there's a lot of value in keeping a website's items consistent.
The work upfront to name things and build out concepts will pay its dividends as you extend a site or build out new ones.
Of course, there’s no right or wrong answer here, and I suspect it very much depends on what type of web systems you are building. I feel the entire debate is basically a special case of the question “do you make websites or web apps”.
If you plan on using bananas multiple times throughout your app, aren't you going to be pulling that out into a component anyway? So define that it's curved and sweet and yellow in that one place, and then insert an instance of it wherever necessary.
This makes it difficult to have open source Tailwind components that can be imported and themed differently for your apps. Even after buying Tailwind UI, they are basically just code samples that we'd have to copy into our own libraries and maintain.
Again it's a really cool library, but feel the approach is probably better for smaller apps and teams.
Daisy UI might help with this, but seems pretty small at the moment. https://daisyui.com/
Sure, a Galaxy Fold is a pretty niche user device, but its genuinely the worst first impression of a mobile website I've ever seen, with everything weirdly scaled to sit in a narrow portion of my screen (other dimensions linked to px values on the video embeds maybe?). Had to load the link a few times to confirm I hadn't just accidentally zoomed out, since if I do zoom in it looks like a normal mobile stylesheet https://pasteboard.co/V0Cy3etIngpY.jpg
https://tailwindcss.com/docs/utility-first#why-not-just-use-...
https://tailwindcss.com/docs/adding-custom-styles#arbitrary-...
Is TailwindUI an alternate to Bulma ?
Kind-of. People usually pick one or the other, but they're not alternatives in the same sense as Bulma vs. Bootstrap vs. Zurb Foundation.
Bulma has opinions about structure and style, and its value proposition is providing out-of-the-box components so you can skip spending brain cycles on that design work. At a high level, Bulma believes projects reuse a lot of design patterns, and those shouldn't have to be rethought each time you need them.
Tailwind doesn't care what you want your project to look like, or how it's structured. Tailwind's value proposition is streamlining you choosing your own design, and removing footguns from that process. At a high level, Tailwind believes cookie-cutter styles are typically less reusable than you hope, that you should instead optimize for tailoring design patterns to each place they're used, and that style reuse is better implemented by e.g., React components than a CSS framework.
maybe i'm reading into it too much, but i don't think they think print readers are inferior.
Not to mention the tooling overhead. I had to revert countless JSP files due to strange compilation bugs that resulted in classes only sometimes(?) being added.
Remember the HN comment guidelines?
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
https://news.ycombinator.com/newsguidelines.html
My main issue with it is the inability to control the order of precedence with the css rules. It’s mostly fine, but when you have runtime rules around, say, colouring text based on a few different variables, it turns into a bit of mess. Unfortunately because of the way it works there’s no way to implement “last rule wins” at runtime.
Say you’re balancing a bunch of colours where it’s say mostly black, but you need to change to green in some case and red in others.
In css this is easy because you can say “for this situation I want this colour”. And you can order your rules in a sensible way so the more specific cases trump the general ones.
In tailwind you can’t do that because “text-red text-black” etc is ordered by the order in which the utility classes are added to the page. So you have to make sure you don’t add two conflicting classes.
That case doesn’t seem so bad, but once you get a few different properties to control and a few different scenarios, it gets pretty messy.
As a frontend developer I don’t like Tailwind for several reasons, it brings the styling into the structure. As a frontend developer Tailwind is at a forefront of what I would consider bad practice and encourages a code style which would be a nightmare for me to maintain.
That said. Tailwind seems to be loved be people who are not professional frontend developers. It seems to be just the right tool for people who are not necessarily proficient in CSS. And perhaps people like me (and the dead sibling) need to learn to let go and allow other people to have the tools which makes it easier for them to do the job which they are not experts at. For that reason I understand Tailwind, even though I don’t agree with it.
Show me a site that has CSS Zen garden style replaceable stylesheets that totally overhaul the nature of the site. It's incredibly rare and almost always not worth the effort. What business says "I want to overhaul the styles of my application but change no structure at all. I'd posit it's near 0.
Even if that's your goal, and I'd argue that it shouldn't be, you can still do that with TWCSS and the @apply keyword. You can write your generalized names then apply whatever twcss keywords you want to them separate from your document's structure.
If your overhaul amounts to changing a "theme" you can easily do that with twcss. In fact, that's basically the point.
I am a professional frontend developer and I love it.
I mean header files are OK, and professional C developers probably love them, but not having header files is kind of great too :)
I have a similar comment elsewhere in the thread but it applies here too, I think: the main drawback of Tailwind is that it's extremely general. I'd imagine a well abstracted, focused, domain-specific set of CSS created by experienced frontend developers will be much better within that domain.
Pair your tailwind with styled components and you can finally reach the dream of semantic HTML.
i prefer the later. with styling in structure if i make a change in one place, it effects the one thing i intended it to
with structure in styling, if i change one thing, it may impact many other things, some of which i might not intend to and are sometimes unknowable at the time of the change
If I change the structure I usually have to change the style anyway. And with component scoped styles, I know exactly where I need to do that (usually in the same file, or in a file referenced by the component).
As for shared styles I use the cascade which can penetrate the component boundaries, e.g. font-size, color, but usually --css-custom-properties.
At the end of the day it's a lot easier to understand what's happening in a template where you can see all of the styles directly attached to each node instead of having to map things together in your head across multiple files.
For example, for me at least I can't believe how much more difficult it is to look at your average CodePen demo and understand what is doing what at a glance vs. looking at a Tailwind template. With traditional CSS there is just _so_ much indirection in comparison.
With the regular way, to style something that's probably not going to appear elsewhere, I'm having to: come up with class names, annotate the HTML with them, repeat some of this annotating in a CSS file, jump back and forth between files to tweak the styles, use the web inspector to figure out which CSS class is overriding another then jump to the right CSS file to fix it etc.
Tailwind classes are also faster to type and flip between when you're experimenting (e.g. editing "mt-5" to "pb-3" vs "margin-top: 4.25em" to "padding-bottom: 2.75em") and you get less distracted because it has sensible defaults and helpful guardrails (you rarely need all the possible attributes and range of parameter values CSS has available).
I also rarely had the super irritating and common CSS scenario where you edit a style and it doesn't change and you have to go investigate to find out why e.g. something is overriding something, your selector is wrong, and even after all that maybe you undo the edit because it doesn't look good. Plus you no longer have the fear that tweaking a shared class to going to break some completely different page.
I feel that beyond some building blocks, trying to create reusable CSS classes with cascading styles has similarities to using excessive abstraction and deep OOP class hierarchies in regular programming languages to avoid a little duplication.
I also don't have a problem with styling stuff appearing in my HTML files either as long as the right HTML tags are used around the data. HTML files are already full of class annotations and divs that are only there for styling yet this doesn't cause a problem to e.g. browsers, screen readers or crawlers.
This experiment has failed though. CSS isn't powerful enough to style HTML however you want without having to add a soup of extra divs and classes that are only there for styling. No large website today works otherwise.
HTML is still semantic when it contains styling markup (in the sense that a computer can read and understand the structured data from it) so I'm unclear what benefit is being missed out on. Whether you call a class "home-cta-subheading" or "text-center" so you can apply some styles doesn't make a difference to screen readers, browsers or search crawlers either.
And if you need to modify the HTML, were the extra tags added 100% only for semantic reasons and not for presentation reasons?
Anyone have good advice on a better way?
> Here is how I approached this challenge
...but you modified the HTML?
The original challenge includes questions that apply only if the resolution involves HTML modifications, which (contrary to the earlier text viewed in isolation) indicates that such modifications are not invalid in response to the challenge.
- There must be a logical reason for wanting to make the word "tiny" use a small font, so that word is missing a tag that represents that prosaic intent. I've used <small>, but depending on how you'd verbalize the word "tiny" (which is what you're representing both with making it use a smaller font and with wrapping it in a semantic tag), you might also wish to use <em> or another tag.
- Similarly, there is missing semantic markup inside the <figcaption> for the person's name, job title and company. Those are semantically separate concepts for each other, but for some reason the example HTML was written without semantically differentiating them. This is much like trying to represent two paragraphs of prose with just a couple newlines, rather than actually wrapping each in a <p> tag. To fix this error, I've added tags as necessary to implement the semantic hCard microformat -- independently of styling.
- I've also added the recommended attributes to the image tag, because it was missing. (And for the sake of the Codepen, I replaced the image's src with a placeholder so as not to hotlink from tailwind's site.)
Given those improvements to the semantic structure of the HTML, here's how you can make the author's name appear on the right, with the quote underneath, with a line break before the company name, and "tiny" in a small font: https://codepen.io/Kerrick/pen/KKXgPYw
> - Similarly, there is missing semantic markup inside the <figcaption> for the person's name, job title and company. Those are semantically separate concepts for each other, but for some reason the example HTML was written without semantically differentiating them.
Presentation/visuals aren't always tied so closely with logic though. "To make it look nice" is a valid reason. As I said, this experiment has failed. All modern website designs use divs + classes everywhere for styling. I agree extra semantic tags would be useful but at some stage you're going to be forcing yourself to come up with semantic reasons to add a tag when there isn't one.
> I've also added the recommended attributes to the image tag, because it was missing.
Related: alt="" is best practice for when an image tag is for presentation purposes only because images don't have to be there for semantic reasons.
https://codepen.io/BlindPenguin/pen/GRMjjvq
I'm off scrubbing my hands with a wire brush and abrasive cleaner.
If you want to make a word tiny, you can use the <small> HTML element.
Here is the CSS for my example
The trick is to keep things simple. Then when you have mastered the rules, you can break the rules. eg. when you can style semantic HTML however you want without adding div's and CSS classes, that's when you can start adding a little div and class here and there just to keep things even more simple.Simple code is most of the time faster to load, and easier to maintain.
Totally this. We say we've come a long way from using tables for layout, but for example you still can't use Flexbox without at least some non-semantic .stuff-container and .radio-with-label junk. Decoupled HTML and CSS have failed in the real world, outside of pet projects.
Can you provide an example? I've never found this to be the case, particularly with modern CSS. Happy to be wrong though.
style is orthogonal to semantics
You need divs all the time for layout (e.g. to group parents/children in the right way for flexbox), to target content for styling (e.g. putting a div around the name of the author to make it blue when you otherwise wouldn't tag it) and to get around CSS quirks (search for "wrapper div" for examples).
> Can you replace them all with more semantic tags? If not, can you remove them and still style it the same way?
I looked at on the first four examples, but my responses are yes and yes.
Take the figure example. The first div, which groups blockquote and figcaption, is extraneous and unnecessary for the end styling result. The second div is not extraneous because it exists for a purpose. The purpose of the second div is to place emphasis on the name or make it stand out. Thus, it should be changed to em. The third div is extraneous. With the HTML in place, grid it up.
You have the container (figure) with two columns and two rows. The image sits in the first column spanning both rows. The blockquote sits in the second column on the first row. The figcaption sits in the bottom right-hand corner. Then tweak to get your img and other parts as desired (e.g., width, spacing, font-size, etc.).
> You need divs all the time for layout (e.g. to group parents/children in the right way for flexbox) ... to get around CSS quirks (search for "wrapper div" for examples).
Sometimes flexbox is the wrong tool. Sometimes floats are better. Sometimes grid is better. If you find yourself reaching for extra HTML elements first, you should stop and re-evaluate whether your approach to achieving that layout is appropriate.
On quirks, my experience is that "quirks" are rarely actual quirks. They are usually a limited understanding of HTML and CSS.
That's a loaded question. CSS frameworks (or tables, or div based designs) are also used because they save time when iterating, not because of a lack of expertise.
https://jsfiddle.net/gx4hk358/
And it's hard to take Facebook serious as an example. They're known to engage in HTML obfuscation on purpose.
https://dev.to/ganderzz/how-facebook-avoids-ad-blockers-4mdc
There's a reason why inline styles and important! were to be avoided
separate files != separate concerns
This is untrue by any measure.
This might have been true in the days before flex or grid, but with those additions, there is no need for extraneous styling divs.
> "...and classes that are only there for styling."
That part is confusing. Classes? As in CSS classes? CSS has no other purpose than styling.
I'm really glad I just powered through that point and let myself feel dumb.
Also does this comment even has a point? Like if we do what you suggest then no need of tailwind?
Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability.
Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with several `class="..."` strings across multiple files, possibly with class names in arbitrary order, possibly mixed with logic from other templating languages (be it from Django or JSX or whatever). So you can't just grep to achieve the objective of changing styles in one place to affect all instances of some semantic group.
Personally I think comparing Tailwind directly against traditional CSS as a whole is painting in too broad strokes. There's a lot of CSS methodologies and also a lot of bad practices (e.g. using SASS indentation as namespacing mechanism and then running into the old problem of specificity), and comparatively, there's a lot more than Tailwind in the atomic CSS space, and more broadly, in the compiled CSS space.
Utilities like Bootstrap (e.g. `class="btn btn-primary"`) for example share many benefits of both atomic CSS and "good" subsets of traditional CSS practices (namely, you get memorable short class names, which are also organizable along semantic lines). So there's definitely more shades of gray than just "atomic-css-is-the-best-thing-since-sliced-bread" vs "looks-like-lazy-style-attributes-lol".
I am going to give it a try. The argument against using it is that it defeats the purpose of Tailwind, but I think its useful to start by spraying classes until things work and then moving those classes into e.g. btn-primary once the styles become stable and need universality.
> If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you
Approaching it with moderation is probably worth trying though
The intended method of not repeating yourself in Tailwind is using a framework, and writing the styles in the template of the component.
With this workflow:
* There are no global styles that can have an unknown or unexpected impact on the application when modified.
* The component's style is completely encapsulated. It can be placed anywhere in the application without worrying about inherited styles causing problems.
edit: formatting
Another variation I've seen is a combination of atomic CSS and Mithril.js' hyperscript selector syntax, which lets you do stuff like this:
There definitely are interesting ways of applying atomic CSS beyond basic Tailwind usage.Occasionally, I'll use @apply directives to DRY up something that isn't easy to encapsulate at the component level, but 95% of the time, I can easily get by with utility classes.
I try to avoid using hyperbolic-sounding language like 'revolutionized,' but Tailwind + ViewComponent has basically revolutionized the way I build user interfaces in Rails.
Although, I'm still a bit nervous spitting utility classes all around. That sounds almost like inline CSS and almost unmaintainable.
I realized that all of my semantic CSS classes might as well have been inline CSS for all the good they were doing me on reusability. Utility classes are faster to work with, and, as long as you’re componentizing everything, still going to give you consistent styles across your product.
IMO one of the interesting parts of functional CSS is that we can apply the same tactics we use for organising code to organising the styling.
Also, with separated CSS, and especially with semantic CSS, there is often a fair amount of duplication that happens in the CSS code itself, which we programmers tend to be very forgiving of. Giving Tailwind more scrutiny than we do for our CSS ends up making our code more consistent, less duplicated and better in general.
It means that we can have our own custom "button button--sm" classes - a single place to change general styling - and on top of that get all flexibility of the tailwind utils for edge cases.
I don't think it's perfect, but it's so far much more flexible than bootstrap, and we don't need to duplicate loads of classes for each similar component.
It doesn't matter, you can have an entire newspaper and perfectly done in functional css with incredible results without having to mastermind any architecture.
http://minid.net/2019/08/12/in-defense-of-functional-css/
Has anyone used both seriously who can compare?
[0]: https://tachyons.io/
Tailwind is better in every way, and JIT is a killer feature.
I dunno, the smaller dev build from JIT is great, but it breaks my in-browser design workflow. Only the CSS styles needed are generated, so I can't make in-browser tweaks to see what a different padding/margin/other-property looks like.
It's a pretty small and readable codebase, so while there's a downside that you can't upgrade it by incrementing a version, the upside is that you don't have an opaque upstream dependency and you can cut any fluff you don't need (though there isn't much).
Also, the naming of classes in Tailwind feels much more natural — the tachyons naming is condensed to the point of being abstruse.
CSS frameworks don't ... need? to be state-of-the-art/updated all of the time (I get that), but at the same time, like anything else, once a component/css/etc. library falls behind, it (can) become harder to make it work with other tools.
i.e. it's hard to abandon the bandwagon of constant new releases, as the second that you do, "stuff" sometimes starts breaking. This is of course a very general observation that doesn't apply to everything.
[0] https://tachyons.io/components/collections/albums/index.html
https://getbootstrap.com/docs/5.1/examples/
Is there anything similar for Tailwind CSS?
Rest cost $
https://daisyui.com/
https://windicss.org/
1. https://shuffle.dev/editor
2. https://shuffle.dev/components/tailwind
3. https://shuffle.dev/setup
The tool is paid, but we have many free components/layouts more than Bootstrap docs.
The Tailwind website is only 36.9kB of CSS and it likely includes more classes than any other Tailwind site on the internet by virtue of the fact that it has to provide visual demos for so many of the classes. I don't think 36.9kB is massive personally, it's much smaller than the CSS of almost every website I've checked.
So much of enterprise IT is little more than glorified form fill-in, and yet so few CSS/JS libraries solidly cover these use cases.
The one thing I don't like is that the culture around Tailwind seems a lot more proprietary, like you're getting three quarters of a product that you need to buy the rest of, whereas Bootstrap felt like you got everything you could ever need for free.
I'm not sure what you mean by proprietary culture! Based on the fact that I've pretty much never seen anyone talk about it, I would guess (total guess, no real knowledge) that no more than 1% of Tailwind users have paid for Tailwind UI.
[1] https://tailwindui.com/
https://tailwindcss.com/docs/divide-width#add-borders-betwee...
[1] https://getbootstrap.com/docs/5.1/examples/
Spending $250 in order to get a well implemented and well designed HTML and CSS framework for your app sounds like money well spent to me, depending on the circumstance.
If you're an expert or pro at CSS, then yes, that's expensive. But if you have a little budget and need to make some quick progress on a new site, it's a great deal. Hiring someone who can recreate these designs and give you exactly what you want is probably going to cost more than $250.
* https://tailblocks.cc
* https://blocks.wickedtemplates.com
* https://tailwindcomponents.com/
* https://merakiui.com/
* https://www.tailwind-kit.com/
* https://www.tailwindtoolbox.com/
Most of the sites I put together this year used an amalgamation of components from those sites for basic structure, and then just get customized to the brand and site function. I hate writing raw CSS and I would also hate writing raw Tailwind.
Tailwind is just a different way of writing CSS styles. Not a bunch of premade UI templates.
It's fine that they want to make money but it's very confusing for a new user. Ultimately, they might make more money by dropping the shady links if it's turning away enough new users.
across their site would be a big improvement.Try daisyui as a tailwinds plugin. It comes with the missing components. It also allows you to replace your 80 character style for buttons with btn btn-primary.