How would have React adoption looked like if it wasn't backed by a tech giant? React propounds a very controversial idea: to put HTML inside Javascript. Of course, once you get the hang of it, it all makes perfect sense: tight coupling and composability.
Tailwind, along the same lines, proposes a contrarian idea and it will only make sense once you start working with it. Here's what I have seen happen frequently: As the CSS grows, so does the bloat and repetitiveness of the same basic style. Let's say you want to position elements in the center of a component? "display: flex, align-items: center" easy. But what do you do when you encounter that same requirement again? Creating a utility class and replacing existing once will be a pain, so you add the same styles again. And that's how folks you end up with a megabyte of CSS doing a job that could be done in <100Kb.
This pattern is more pervasive than you think. The fundamental problem is that we are not thinking about styling in terms of composability of basic styles.
The benefits of utility classes outweigh the cons. You can iterate faster, you don't have to fight the framework, you don't have rethink abstractions at every point ("this style belongs to a component or a utility class") and as CSS becomes more expressive you'll need fewer classes anyways. I hope Tailwind takes off because styling definitely needs to be less painful than it's today.
The benefits absolutely do not outweigh the cons. For starters, your CSS can never compile down to a smaller size than component CSS - ever. Because of the nature of compositional classes the plateau of problems expands out almost infinitely, and the resultant inconsistencies necessitate new overrides, more code, more complexity, more misdirection.
What size site do you work on? How often do you have to completely change an interface, or move a component from one place to another without it breaking at all, and how well does that work for you with Tailwind? How do you plan to scale this codebase consistently across organizations, teams, potentially platforms?
Tailwind and the frameworks like it are absolutely terrible at scale. I've spent years of my life trying to remove functional css from sites trying to scale while it holds them back.
Co-author of Tailwind CSS here. Prior to building Tailwind, I followed more traditional approaches to writing CSS, like BEM. In fact, I remember when BEM first came out, and people hated it too. I've worked on small projects, and very large projects. I recently rebuilt a large web app using Tailwind, and my resulting CSS was TINY. I use Tailwind in conjunction with Purge CSS. The resulting filesize was 8.1kb gzipped (42kb).
> Tailwind and the frameworks like it are absolutely terrible at scale.
My experience has been the opposite. BEM is terrible at scale. You write the CSS, but then never dare change it, because you have no idea of the consequences of those changes. Developers end up duplicating BEM components for their use case, because it's safe. Which just leads to more CSS code. It's also worth noting that we're seeing more and more large companies move to utility based CSS, including GitHub and Heroku.
At scale, the priority is isolation of components. This allows things to be composed, moved, etc. without affecting each other.
We accomplish this in our web app (over 500 kloc) by simply giving each component’s top-level element a unique, formulaic, memorable CSS class (which is very easy to do with SASS/SCSS). And each component gets its own CSS (or .scss) file, HTML file, JS file(s), and I18n directory. The app loads each component’s CSS when that component is loaded at run time (which could be during startup or later). I just don’t see how one could get more straightforward than this for a large app.
We do have some classes that are included in the base-level stylesheets and shared among components, but we only use those when it would result in less code than not, or when necessary for themeing.
It may take a lot of effort to build this kind of architecture, but once you’re there it’s a breeze to create, compose, and maintain UI components.
The problem with isolation of components is that then the stylesheets are no longer cascading -- each component needs to be re-designed to fit within a design framework, and there's no CSS reuse between components is entirely copy-and-paste. Good luck re-styling anything for "dark mode" without having to hand-visit each component's JavaScript and CSS.
Plus, component isolation has really slow polyfills. None of the Google stuff as of late runs on anything other than Chrome for like a year after launch because it's too slow and broken -- everything is being rewritten in Polymer, which relies on browser support for component isolation.
Avoiding the cascade is kind of the point, although I'm sure that sounds antithetical. IMO, the cascade should be treated with an "opt-in" approach, where you have a fine degree of control over what, precisely, is cascading and why.
In general, with component CSS, you will tend to avoid the cascade, except within your component. This is actually where utility classes have some value - if they're scoped very tightly to the parent, and their effects are well-understood - then your single purpose class can add an easy way to do simple updates.
That being said, for my part, and on my own website (doggos.com) we do not use any form of utility classes whatsoever. The entire website depends upon isolation, and through this isolation, I have a degree of control that I've not found in applications that have opted for other methods.
In short, it's worked very well for us.
As for your dark mode example... you should take a look at how Apple made dark mode a reality with their new Mojave update. I think you will be surprised at the level of isolation their interface demands and, although we're no longer talking about the web here, just how easy it was for them to implement...relatively speaking.
In short, I can make a site go dark with components, no problem.
We're not using any Web Components APIs, thus no slow polyfills are required (see my comment for how we isolate component CSS).
As for eschewing the style cascade, yes, that is happening when we isolate each component's CSS. However, wouldn't using Web Components proper have the same problem? And yes--it would be a very large task to add a dark mode, as you say. Each component would have to be visited. However, when we drop IE11 support, CSS custom properties will make this potentially much easier.
We don't copy-and-paste CSS often (remember we're re-using components and composing them everywhere). If there's enough commonality for CSS copy/paste to be tempting, it's probably time to either revisit how components are being composed (do we need to create a new component, or maybe have these 2 similar components inherit from a base JS class?), or add those styles to a top-level stylesheet and use shared CSS classes.
> I recently rebuilt a large web app using Tailwind, and my resulting CSS was TINY.
I think Tailwind is quite an interesting approach, but to play Devil's advocate: how much bigger was your HTML? With all these class names, you're basically moving some of the entropy over from the .css to the .html, right?
I'd love it if you expanded on that last comment - my instinct is that functional CSS is a footgun, but I'm not nearly good enough at CSS to really be able to unpack that into concrete problems it causes.
Sure thing. Due to an NDA, I can’t get into granular detail about the site, but I’m more than happy to expand on the problem.
When I started here, I sort of “inherited” a large stylesheet written in the classic BEM/Tachyon style of CSS. I can see why the author chose this method, because at the time the website was small and functional classes seem like a really good thing, as they help you get up and running quickly.
Over the years, however, the site got more popular, and now the demands of the interface are increasing. At one point, it was perfectly OK to do, say, “container mt-5 mb-5 p-20 text-green” etc. This flexibility allowed the site to grow, and while the CSS did bloat, the impact was seen as negligible for years.
Now the site sees 50-80k+ DAU, and seeing as the business is very established, it makes sense that we would want to add bells and whistles to the UI that wasn’t on the roadmap those years ago, like theming, widgets, or simply making a previously non-responsive page responsive.
In Tachyons, and in Tailwind, the abundance of utility classes means that even the best, most organized authors will create inconsistencies. The original container styles from earlier might look something like
“container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5” in others.
It may seem trivial to just add and remove classes at will, but it isn’t. Removing a margin-bottom from one element inevitably affects the position of another on the same page, and trying to reconcile these inconsistencies _usually_ means an override, because figuring out how to rearrange functional classes without breaking anything else is a time suck.
Removing this style of CSS from the project has been tedious, but necessary. Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else. And you avoid the unexpected inconsistencies created using utility classes by, well, avoiding them. As someone that used to love BEM, tachyons, Atomic CSS, etc., the lack of scope, unpredictability and huuuuge bloat created by overrides steers me away from it even for the tiniest of projects.
> container styles from earlier might look something like “container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5”
I've only used Tailwind briefly for some side project, but I thought the docs made it clear that whenever you have a situation where you feel you're repeating styles you should extract them into a new CSS class. There's a whole section dedicated to that in the docs:
How would this have been prevented if those same developers weren't using Tailwind and instead simply created .container1, .container2, and .container3?
> Now that we build with small, immutable, scoped components
What do you mean by the word component? Are you talking about a React or <insert framework here> component? I don't really see how it's related. It seems like your team quickly iterated and didn't think forward about creating a common look for "containers" until a good amount of development was done. The common look could have been accomplished by extracting the common styles like the above link suggests or creating a common "Container" UI component with isolated styles. The mistake was not thinking ahead and seems unrelated to Tailwind IMHO.
> Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else.
Any suggestions for further reading on "small, immutable, scoped components" ? I'm half sure I know what you mean and entirely sure I don't understand it well enough to explain it to somebody else.
There’s no magic. Remember that at the end of the day, no matter what approach you take to your CSS, we are all dealing in trade offs.
I like to say, that with components, you encounter “a new level of bugs.”
With Functional CSS, you deal mostly with incidental bugs. “This container has margin 10 and this one has 15!” or “This text-red is overriding all my text!” Individually, these are annoying, but together they can compound into unfuckable problems. Right now I’m working on rebuilding a header that was styled with this approach, and ultimatley wound up unable to remove certain classes without breaking other elements. Something as simple as moving the text from one side of the screen to the other involves building an understanding of how they work individually, which is very challenging in a site as large as ours.
Enter my new header, a component. Its got a parent of .HeaderComponent and everything is scoped inside of it. If I delete, say, a .Link here, it doesnt affect links elsewhere on the site. And since I include re-usable mixins for base styles, like text, its easy to (say) @include BodyFont; or HeaderFont; without affecting the page or the site as a whole.
What I mean when I say “a new level of bugs” is that how and why you build things becomes more important. If I build a header component, but a large change happens elsewhere on the site, its unlikely I will change my original component. I’ll make something new and call that, instead.
In this process you can wind up with poorly built components, things that wind up not being used as much as you thought, etc. But the beauty of it is that getting rid of them is SIMPLE. I made a lot of mistakes when I started building doggos.com with components, but I’m really excited about how easy they were to remove. If you just make something new when you need something new, you wont have a bunch of legacy code following you around everywhere.
That probably isn’t a greaaat explanation, but I’m very happy to expand further or give you some links. In particular, Airbnb.design has some great lessons on why they ultimately went this direction, and they do a much better job of explaining it than I!
This is not for me. I am very good at, and very comfortable writing CSS since I've been doing it since the CSS Zen Garden days. But I understand the pains this is trying to solve and I think that this is the wrong approach and also the wrong abstraction.
- If you don't like CSS, this will not help you write less CSS, it will only make you write it inline and using a weird syntax.
- If you want to do the sensible thing and compose your styles into components then you'll still have to write CSS with the weird syntax and add a PostCSS to your dev pipeline. Not to mention that you'll still have to have some kind of system for your class naming.
- The order of the clases does not matter, the specificity is decided by the order in which they appear in the source. I can see all kind of untraceable bugs coming from that.
I've used BEM and SMACSS and similar before and I think they are useful as a naming convention for teams but I don't think of them as great tools to writing better CSS. In my humble opinion CSS-in-JS solutions are closer to a great abstraction. I quite like both StyledJSX (for react) and .vue files in which you can write plain css and forget about the global aspects of CSS and the cascade for the most part.
But I can see why some people will dislike that as fiercely as they dislike tailwind.
I think Styled System is a better abstraction than tailwind: https://github.com/jxnblk/styled-system it's a React library but I can see it's principles could be extracted successfully to plain CSS.
Not really CSS in js is basically applying styles directly to an element, this one declares a small style sheet upfront and classes on elements are looked up to get style information.
Css in js is very efficient if you don’t need any css inheritance. Tailwind is just inefficient for the browser to do all those lookups to resolve the final style bag.
I’m not sure why I would ever use tailwind. It’s yet another archaic syntax I have to keep in my head.
Hmm. That's an interesting syntax. I still don't like it and would hate to work on a codebase that used that for styling but I'm happy to know that it exists as an option for people who like tailwind!!
Lol here we go again. Why does this get people so riled up?
I suspect people who immediately dislike this maybe are not using some type of component-based UI. CSS classes are all about code-reuse. If you have the concept of say a "button" in your UI, and you are copying your button markup every where you use that "button" then it certainly makes sense to have a class for your button markup that encapsulates the styles for that button in a style sheet somewhere.
If using a button component however, you've already created a place for the concept of your button to exist. At that point if you go on making a class in some style sheet that also represents the concept of your button, now your button concept exists in multiple places, linked together by one or several class names. That seems a lot messier to me than using utility first styles, but I don't think it really makes a huge difference one way or another.
It's easy to understand why it gets people "riled up." For 20+ years the entire industry has been pounding the table about why inline styles are so bad. Thousands of articles have been written espousing this idea, and likely hundreds of thousands of hours have been spent devising better alternatives in the form of CSS frameworks.
Whether Tailwind is functionally and pragmatically better than inline styles isn't even important. It looks like inline styles, so the first reaction of almost any experienced designer/developer that looks at it is to make that association and squirm in discomfort at its mere appearance.
After doing a project with this I think Tailwind is great! There is no need to choose either BEM or Tailwind, they can co-exist in the same project and they both makes a lot of sense (for different use cases). Typically, I’ll start with tailwind classes and extract simple tailwind components when those classes start to repeat. If the component is clearly reusable and has enough complexity, I’d switch to BEM.
Sass makes it a lot nicer to write BEM notation. The long class names used to bother me too, but it is actually much nicer than not knowing where a class came from. Is `.right-button` a global button style, or unique to this component?
I agree that sass enables nice readable BEM, but I don't really think that BEM makes markup any easier to read than something like tailwind.
If you're into knowing where your class came from, it seems tailwind would be even better for you because now you have access directly to your styles right there in your markup. Skip the class step altogether!
after doing a project with tailwind I have completely abandoned the idea of BEM. while it was nice having clean classes, having the styles directly in the html is way easier to reason about.
If you're interested, I wrote a short blog post recently with some very similar thoughts on the role of classes vs inline CSS in the component paradigm.
Tldr: for me, classes make more sense for reuse in simpler content-heavy scenarios. For anything remotely complex or webapp-like, I think they are the wrong abstraction.
I really don't see the benefit. Sure, you don't write "CSS", but you write a lot of classes that look like CSS. If you write class="bg-white no-underline" you could easily write style="background: white; text-decoration: none;" and every frontend guy will understand it. I don't get the point.
If this article didn't make it click for you, that's understandable. It took me a long time of hearing about this & thinking it was stupid before it made sense. When that happens to me, it's usually a sign of something good.
But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray?
these inconsistencies compound, especially across teams.
Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.
I admit, after the middle of that article anything would look good.
It's a good realisation that there is no real separation of semantics and styling between HTML and CSS. XSL would have been one solution, but it was just too XML-ly. Personally I found it a joy; I could design my pages with pure semantics alongside a turing-complete stylesheet.
However now we have web components - your HTML and CSS are tightly coupled, but scoped. And the semantic / styling separation is provided by the shadow DOM. So no need to create inner platforms like Tailwind.
Sounds to me like the author should simply use SASS + a good autocomplete feature in their IDE.
When I write CSS, I use a lot of shortcuts. I simply write "mt5" and then press tab, it then auto completes to "margin-top: 5px;". If I write "tdu"+tab and then it goes "text-decoration: underline;". The IDE also shows me in a drop down all the options that can be used after writing "text-decoration".
Changing standards because you do not want to learn or remember something is the perfect example of programmer "laziness". Why remember this super common language when instead I can develop and remember a new obscure abstraction instead?
Oh no, laziness! Someone is doing something in an easy and convenient way that somehow doesn't match up with other people's ideals of conceptual purity! :'(
Bloating your markup with classes is simply a bad habit. It bites you hard in the long run.
Even the framework that they are using proposes better alternatives.
“Tailwind encourages a "utility-first" workflow, where new designs are initially implemented using only utility classes to avoid premature abstraction.
While we strongly believe you can get a lot further with just utilities than you might initially expect, we don't believe that a dogmatic utility-only approach is the best way to write CSS.”
A class based rapid prototyping framework is a powerful tool, don't get me wrong. However, like all tools you should only use them when they truly are needed.
How so? If what I need is (as the author describes) to occasionally make a quick relatively-usable site, and I want to do some styling on it, and then forget about frontend UX until I need to do another small site 4 months from now, how will this pattern bite me?
How can you achieve reuse (DRY) with this? Every time I have a button, if I want my buttons to be consistent and have a single place to change them, I have to like invoke a button partial that just outputs my <a> with 20 classes on it? It's a lot easier to reuse a CSS class (an abstraction) than a template of a chunk of HTML (an indirection) -- especially across divides of languages/runtimes/client-vs-server if you have any of those.
I agree with the point you're making, but it doesn't seem to address my question. The author describes the usage pattern that I find myself in, and I suspect is relatively common among non-frontend devs: we aren't particularly skilled in CSS or other frontend web dev work, but every now and then we find ourselves wanting to make a quick, simple, but usable site as a landing page for some other project we're releasing.
For people in that niche, frequent tweaks/changes to the styling seem unlikely: I'm going to make the site once and unless it breaks I'm unlikely to come back to the code for it.
The parent comment I replied to makes the direct claim that this class-based pattern will bite me, and I'm curious if somebody can help me figure out how that would happen.
I think the article provided good insight on this: "I wonder if the reason this approach makes more sense now is that we’re doing more generation of HTML than we were in 2003. In my tiny example, this approach to CSS actually doesn’t introduce that much duplication into my site, because all of the HTML is generated by Hugo templates, so most styles only end up being specified once anyway."
So you write your button one time in a reusable button component, then reference the component and avoid writing the same 20 styles again. I think this has benefits as it keeps all the information for a single component in the same location, making it easy to understand and edit the component from a single location.
Could you suggest how it's bloating the markup and how it'll bite you in the long run?
I understand that maybe adding a bunch of classes for every element will increase the overall size of the page but if it's served with gzip compression doesn't it actually (maybe only technically) work better to have repetitive classes everywhere instead of unique class names?
The problem with granular classes is that you project won't scale in an efficient way. It also makes refactoring almost impossible.
On a small one page website, do use them. However in something more complex like an e-commerce website theme or a complex web app, you will regret it quickly.
One of the selling points of CSS is the ability to scale and refactor very quickly and easily. Class based frameworks remove all those benefits. Extracting components and building sementically is the solution. As I said in my previous comment, that framework they are using supports it. They say it themselves:
“*While we strongly believe you can get a lot further with just utilities than you might initially expect, we don't believe that a dogmatic utility-only approach is the best way to write CSS.*”
I have worked on many contracts where the client came to us because their current web agency wanted to charge crazy prices to refresh their website's design (e-commerce websites change at least one a year). Almost every time, those projects are a pain for both the team and the client because the previous developer decided to be lazy and use classes or inline styles everywhere.
It’s not reusable. It’s not consistent. It’s not scoped.
It may be hard to see now how it will bite you now, but I promise you, it will. It would take hours to explain why, but I am speaking from years of experience here.
There is a reason large organizations have abandoned this approach, and it isn’t just personal preference.
This talk gives a pretty good explanation, Airbnb.design, Netflix, Facebook, and Instagram have many others
I tend to think laziness is positive when it inspires better architectures. Picture a dev who just sits there drinking his coffee until he finds a way to do something without typing a lot or remembering a lot of small details. Now picture a dev who dives in enthusiastically, writing the same bits of configuration a hundred times with small tweaks. Whose code would you rather maintain?
If an abstraction makes it easier to do what you want to do, it's a useful abstraction.
The project in question uses PostCSS, which is to CSS as Babel is to Javascript.
The point of a broad set of utility classes is to have predefined and discrete classes that map to conventions your application uses. Here's a few examples from an app I use:
Each of these are a "standard" that we use throughout the app. There are NO one-offs. These can then be composed into "component" classes (e.g. .Button, or .TextInput).
The benefit is mostly threefold:
* Maintainability is great. No hunting throughout the templates when you want to change the primary colour. Just update the .u-colorPrimary class, or its underlying variable.
* Our developers can look at a design and mostly do it themselves. No need for a CSS pro to come in.
* We can package these into a node module and share them across our apps.
You're right: this is laziness. I don't like to repeat myself, and I like consistency.
This way is great, it's not the one I use but I have no issue with it.
I prefer to use SASS variables along with a strict build system that refused to build if the developer isn't using variables that are injected via a config YAML file. In the end, we are both working in a similar way.
That being said, ".u-colorPrimary" is great. You can easily refactor it and it should scale well. However, ".bg-orange" and ".text-white" aren't great.
It's 2018, does CSS supported by modern browsers still lack the basic building blocks of reuse? Why am I being asked to choose between class="resources" (and having to know how to center a div in that resources class) and class="t:center t:wide-margins t:light-bg" (which is basically reintroducing all the harm of style tags). Why can't I, in 2018 and with vanilla CSS, say:
It seems like every one of these styling tools is just polishing a turd that is a turd for no reason. I can't imagine why the above would be difficult, it wouldn't have to change anything about the actual application of CSS rules, it could literally just be a simple preprocessor.
Sure give me a library of common ways of doing something. That's great. But the lack of basic code reuse for CSS is staggering. Even if you're doing reuse with SASS you're stuck with the fact that you end up generating a CSS File that's 4-5 times larger than it needs to be.
The main selling point of tailwind for me is that it improves iteration time by grouping the CSS with the HTML: I don't need to switch files anymore and also more importantly don't need to come up with ids and selectors. It reduces the level of indirection.
Of course you can say now I mixed style with HTML but if you never intend to change style separately from HTML then why introduce the mental overhead of indirection?
What's wrong with class="centered wide-margins light-bg"? It would do the same as what your .resources class looks like it might do, and it's supported everywhere already.
Nothing when everything's a one-off and you only have one supported theme. But if CSS is your component model (e.g. a card is always just a div but with a special style) then you'll have "centered wide-margins light-bg dropshadow" on every one of those divs, rather than just class="card". Similarly if you want to have two different themes with the same DOM, you can't do so easily.
Nobody who uses Tailwind would suggest copying the same classes over and over again in the example you’re talking about. You would either still create a card component (Tailwind does have the concept of components), or if you were using a framework like Laravel you could create a card blade component that held the tailwind card classes in one place.
I wasn't talking about Tailwind, I was talking about vanilla HTML and CSS. I assumed the question asked of me ("what's wrong with"...) was asked in that context.
I've been using tailwind for almost a year and I love it. I would not use something else willingly for something new! Its easy/fast to write and in my mind VERY readable, and if you don't know whats what, their docs are really good.
And for example in React to build a component with conditional styling I use classNames and use props that correspond to classes.
It puzzles me why these Atomic CSS based systems use various mnemonic systems instead of plain English which is much more understandable. I'm not a fan of human-powered text compression.
It's based on how often you use a helper. For instance, changing letter spacing is verbose (https://tailwindcss.com/docs/letter-spacing) as it's not something you use that often. Tweaking spacing is very common and "padding-horizontal-2" uses an awful amount of characters.
In what context is this "an awful amount of characters" an issue? GZip compression is fairly standard these days, and languages based on plain english (or similar languages) has a better level of compression than random text because of repetitive nature of sequences of characters.
I can't believe that mnemonic based languages are easier and more readable than something closer to a natural language. And with the assumption that code is written for humans first, computers second, what is the point of inventing a language that's less readable than the one it's trying to replace? CSS compresses particularly well, as every Atomic CSS based framework tends to point out on it's landing page!
After spending more than, say, two hours with Tailwind you'll probably read the first line much faster than second one (since there's less to read and you don't need to scroll). Humans are very good at pattern recognition, and you'll quickly read "mb" as a symbol in itself and not as "m[argin] b[ottom]".
> I can't believe that mnemonic based languages are easier and more readable than something closer to a natural language.
Well, it's worked out pretty well in mathematics. This is not about file size at all. It's about defining an "alphabet" of common concepts.
Ah, I see your issue: you do know you can have whitespace inside attributes? You don't have to clump all the class names on one line. Scanning vertically is quicker than through the horizontal line-noise of both your examples.
This also has the benefit too, that if you use version control line-based diffs to see what's changed, it will highlight the specific css class name that changed. Handy if you need to ensure that whenever you change the bottom margin, you can see at a glance whether the small prefixed one has been updated too.
On the other hand if you regularly need that many classes to style an element, perhaps it's a good place to refactor commonly occurring class names into a set, and label that set with a meaningful identifier.
As for mathematical notation, it's about as understandable to me as my understanding of Hanzi.
I agree with your sentiment. I think this is because half the programmers like mnemonics and the other half prefers English, so no matter what you do people criticize your choice. People call Java verbose and perl write-only.
Because you'll have 29 different margins, 67 different left paddings, etc all over the place. Tailwind allows you to create a consistent design system. CSS was supposed to be "write one class, use it everywhere instead of inlining". Usually it ends up with nobody reusing that class and everyone creating their on in the same codebase. There's an article I don't have a link handy, which explained how ridiculously many classes were used by GitHub/Lab, Airbnb, etc. Now even GitHub have their own utility based CSS system and others are following along, including Bootstrap with their CSS utility classes.
> Because you'll have 29 different margins, 67 different left paddings, etc all over the place.
That's not really the case since SCSS became a thing. If SCSS doesn't help you, Tailwind won't, you can ignore their classes just as you could ignore preset constants.
Honestly, to me it seems like people are just starting "fresh" with a benefit of some experience, and ascribing the benefits of experience to the tool.
I've used SASS for years, and yet switching to tailwind felt reaaally nice. have you tried it for yourself, or are you just assuming that you understand the practical differences?
Can you elaborate? I can't agree with you. Tailwind is meant to provide a consistent design system, of which CSS size should never get out of hand (which is the case then using regular CSS). Whenever I use Tailwind, I end up adding maybe 20-30 lines of CSS and I never have to open a CSS (or other sass/less/whatever) ever again. Have you tried Tailwind or you're just assuming what you're saying?
I use Bulma (discussed at the end) for all my projects. It's very easy and quick to get started with, but I found myself diverging from this style when I was starting to add new CSS of my own, to get the pages to look exactly how I wanted them.
And due to the lack of tooling, it's hard to refactor CSS (removing duplicate code, etc.) so I'm not sure how scalable it is to adhere to what the OP says for a long time.
I used Bulma as a way of getting up to speed after a hiatus since circa 2001 when it comes to web stuff. I needed to quickly throw together a company site.
I searched around and Bulma seemed ... "not insane" which was good enough for me. And it is good, and good enough. But I can easily see how you could start fighting against Bulma if you wanted to do much customizing.
If I ever get caught between a rock and a hard place and need to do stuff not easily wrought in Bulma, I will check back on Tailwind.
I never tried Tailwind, I landed to Bulma after using Bootstrap, and then Tachyons, for many years, and I really enjoy it. I find myself maintaining an helper.scss file with basic classes that bulma does not support out of the box, but other than that, it definitely saves me time and, overall, improves the outcomes.
Everytime I see Tailwind/Tachyons/Functional CSS at the top of HN I die a little inside. I've said it before and I'll say it again: if you actually like this kind of CSS, you probably don't work on large websites. And when you do, the reason people hate it so much will become abundantly clear to you.
Functional CSS makes for an unscaleable, inconsistent, unmaintainable dumpster fire of styles that is objectively worse than just writing regular CSS.
<sarcasm>
But it's convenient, right? So who cares! AirBnB, Facebook, Walmart, Github, and Twitter are all probably wrong anyway.
</sarcasm>
These are not stylesheets I want to emulate. As I mentioned in my other reply, GitHub is actively moving towards a more utility-based approach to solve this problem.
Compare this to a fairly large app where the CSS and markup were completely rewritten using Tailwind by a friend of mine recently:
This is all the CSS needed to render almost the entire app from mobile to desktop widths, in both light and night themes. The "utility CSS" is generated by a framework and not something engineers have to be concerned with when writing components.
Atomic CSS was used on Yahoo sites, since the Marissa Meyer level. Apparently on a few of their properties. Hard to assess whether it was a failure or not. Considering their websites were a negative asset, I doubt the use of Atomic CSS was a major component of that, there were definitely bigger problems.
I've been using Tailwind lately and I really like it. It lets me prototype and iterate quickly, and then when I've settled on a design I can create component classes for those completed styles. It has made doing frontend work slightly more bearable for me.
Most (all?) of the classes apply exactly 1 line of CSS.
I see this as an anti-pattern, because to me it looks like inline styles with extra steps. The only thing it avoids is accidental strong specificity.
The reason we have CSS is that it's really easy to make HTML unreadable - after all it's essentially a 1D medium(lines of text) trying to describe a 2D space.
The difference is that inline styles can't use several important CSS features, like media queries or pseudo-classes like `:hover`, `:focus`, etc.
You have to first be convinced that inline styles are not inherently an anti-pattern to understand a framework like Tailwind. After that, the benefit of Tailwind is that it's like inline styles, except with the ability to style elements in different states and at different screen sizes.
Inline styles = open ended, while classesrestrict you.
Also this is switching things around. Now your html depends on your css classes and not your css depending on your html. No more broken css when a dev modified the html structure and didn’t realize that one of the hundreds of lines of css now doesn’t get applied right.
Doesn't this essentially put you back to the bad old days of style attributes? Sure, the "styles" you are using are much more clever and they adapt to screen sizes, etc., but you are still putting the specific style you want an element to have in the element itself and not getting any redirection.
Say you have an entire application with a dozen primary pages, plus several dozen modal windows and other sub-pages. If you want to make a global change, like, "Change all the OK buttons in my entire application to have rounded corners and a gray to red gradient" then you have to go back and make a change to every button you have in the application. The whole idea with changing the CSS was that I defined a semantic CSS (e.g. "OKButton") which I used in all the places that had a common meaning, and then I could change the look of the entire application in one place.
I have trouble with the following statement. Complete flexibility is a bad thing? If I accept that how is limiting options to 30 not providing too much flexibility?
"Limits & standards. With normal CSS, I can make any element any width I want. For me, this is not a good thing! With tailwind, there are only 30ish options for width"
Actually it is, especially when you're working with a team of developers.
Imagine that your designer puts together a design system built on a soft grid. The rules in the design system are what ensure consistency across the site.
If you have a team of developers, sooner or later you'll manage a junior dev who interprets the design as a pixel perfect layout, and starts defining widths on elements per their own personal interpretation. Maybe they eyeball it, maybe they measure it, maybe they measure it but don't include the border.
You can catch such things through training and code review, but it puts the burden of managing design consistency on a senior engineer. Starting out with a constrained system is one easy way to ensure consistency of design across large projects.
As an example, it means you’ll never be off by a pixel here and two pixels there. You’ll be off by, say, five pixels or ten pixels instead. Your mistakes will be obvious and easy to fix.
It’s the difference between working with Lego and working with ordinary hunks of smooth plastic.
That's the nature of any higher-level language: you reduce flexibility and gain ease of use for particular use cases.
E.g., With Ruby and Python and Java you lose a lot of the flexibility that pure C gives you. You can't directly manage memory directly any more, for example. Is that a bad thing? Not for most people.
Note also that one of the major goals of an operating system is to limit flexibility. The first thing an OS does on starting is to lock a bunch of functionality away from any other code. Similarly, virtualization and containerization are mainly about removing capability.
In some situations, choice reduction can come from abstracting them away. Then, by definition it's a good thing. Assembler v C. Of course, if the abstraction is inadequate (leaky), then you haven't really abstracted anything away.
I fear that many will not prefer attribute bloat in their markup.
And many are moving to React, does this sort of toolset matter anymore? Not being negative, genuinely serious. Does this tool make sense for apps going forward? To me it seems Tailwind is for little html things.
I prefer the hybrid approach, having a mix constantly repeated utility styles for things like padding, margin, floats, and colors, and then having custom SCSS/CSS for the rest.
that's what tailwind does, look into the components docs. essentially utilities vs components are a matter of definition order, such that utilities can always override components.
I really like these atomic/functional css libraries with any sort of frontend framework or templating system that leverages components.
Personally, I have been using Tachyons with React for the past couple months, and it's been a blast. Compared to writing html templates with Emmet and css with Sass, I feel as if I am more productive and like I can reuse more components.
I've also found Tachyons & React to be an amazing combination. The only trouble I've had is extracting common CSS class strings into tweakable components, e.g. a <Button> whose background color you can easily override, or a <Header> with tweakable font weight.
I wrote a tiny (1kb) library to make this easier. For anyone working with React and functional CSS, I hope it's helpful:
Seems like an interesting library! I also encountered this issue, but I ended up just passing in colors/borders/spacing as props. I will have to see how that holds up for complicated UIs.
Thanks! I started by just passing props too, and I could see that approach working forever. I just got tired of having to always specify <Button bg="blue" border="ba1" />, when 90% of the buttons in the app were blue with a border.
Be sure to check out the Wizard Zines site they are talk about. It had old school hand drawn zines about topics such as git, debugging, and more. Here is one on tcpdump
Absolutely. She's really good at making a complex topic approachable and bringing a lot of excitement as she shows you around. It reminds me how incredibly cool I thought these tools were when I first learned them.
It only seems large because there's lots of repetition based on the various screen sizes, colors, and states (hover, focus, etc). In production it's just a few kilobytes in size.
Tailwind would come out ahead because there are fewer classes that contain the same declarations, so the total number of style declarations would be less.
What percentage of software churn is based on developers being reluctant to call out mistakes by other developers on their own teams/in their own companies (while having no problems calling out flaws in internet strangers' code)?
'Curating' what developers are allowed to do has been the focus of the last few jobs I've declined. "The guys at the other office are too dumb to learn (React|Angular|CSS|tech X). Obviously, we need a team to invent something that uses (React|Angular|CSS|tech X) behind the scenes but has a totally different API and no easily searchable documentation or support outside of our company."
Tailwind looks like one of those escaping into the world, when telling your devs to pay attention to a style guide would have been the easier solution.
Technology does not have a glorious track record in solving cultural issues.
Not sure it totally applies to this situation but agree and think this is a great point. Technology doesn't solve cultural problems and often exacerbates them!
Several people here say "this doesn't scale" but I'd be curious to find out:
- The 'scale' at which they think a framework like this doesn't work (number of users, devs etc).
- The scale of the projects they work on.
Who even says a framework needs to be adopted by tech giants or work at 'scale' to have any credibility?
A utility-based approach has been adopted at the last 2 companies I've worked for and it's been very effective, often when working with very complex designs on medium-sized sites (that serve less than 100k users/month).
I've been saying for years that, in these days where all HTML is generated, CSS makes no sense and we might as well just style inline. You probably already have a "button" class in your UI framework that contains the HTML for rendering a button; put the styling there too.
> So if you have a large number of buttons or other elements with the same class you will be repeating yourself over and over.
In the HTML, sure. But so what? It gets compressed in transport so there won't be significant overhead there (similar to how remote desktop protocols that send images with compression turn out to be just as efficient as those that tried to send intelligent drawing commands), and the browser has to compute the final style for each element anyway so there's no overhead in-memory either.
> This would be a nightmare to work on/maintain.
HTML is an output format, you don't edit/maintain HTML any more than you edit/maintain binary machine code. And keeping the styles inline allows better encapsulation: the styling for each component lives in that component, you don't have the spooky action at a distance of child selectors.
What frameworks treat HTML as an output format, and what is the input? When I see samples of React code, all the HTML (in the form of JSX) is still handwritten, just combined dynamically.
Sure - you write the html snippets by hand (and those are still very maintainable if you use inline styles). But you don't maintain the final page that might have e.g. twenty buttons, so that's not a case to optimise for.
CSS sucks because it lets you reuse code to a very small degree, but doesn't go very far. Less or sass seem much betters, if for no other reason than referencing common behavior.
Too much to read xD if anybody gets this far then remember this...
1. People arguing against this are arguing against utility classes and not arguing against tailwind.
2. Tailwind is different - it’s a toolset allowing you to build your own framework - you can use the tailwind config to define your variables and use BEM or what ever you want.
3. Tailwind is utility “first” - so it provides all the utilities you need, YOU decide how to use them, put them all in your HTML if you like, or make components out of them, include them into an existing project, etc.
So everybody here who is being negative towards tailwind regarding utilities is wrong - because they haven’t understood tailwind. - your arguments may be valid for utility classes, but this topic is about tailwind, so your spreading misinformation.
To address the author's “oh, another bootstrap site” line, Bootstrap offers a "css grid only" option. Which, I've found to be great when you don't want the Bootstrap look, but want a grid system in place to build with.
Say you want a div to be a specific width: 135px, how do you make it without writing any CSS? Or you want a specific shade of a colour? Or you want to style things that are not in your html (third party widgets).
You treat your stylesheet as your style guide, design system, or single source of truth. That's where you define your fonts, colors scales etc.
So you actually don't have to think about specific widths while you're building, you reference a width that is already set up in your stylesheet!
I find that it improves the design to dev workflow. You experiment with design in a design tool like Sketch, and then translate your final idea or rules into a stylesheet, which is the basis for your live prototyping in editor & browser (wrapping HTML elements and referencing styles in your stylesheet).
These packages are really useful for small to medium sized projects where you need little to no customization! When you do need something greater than what the package can provide then I find it better to use something else because these tend to pollute the namespace and things in my experience get really complicated when you start adding your own stuff with them, or modifying them.
Even though they are compact you probably end up having lots of unused CSS code in your website.
I've seen Tailwind pop up in some of the JAMstack starter kits, and I could have sworn it was some framework of yesteryear that I just missed that was now largely replaced by Bootstrap/Bulma/etc. Now that I've looked at the GitHub, I see v0.1.0 was released on Nov 1 2017! Some of these recent trends in web design really have me scratching my head, but I guess I'm just getting old.
CSS has a bit of a learning curve, the probably most difficult to understand is the C (cascading ) part, and where something more specific over-rides something less specific. It's simple. Yet complex. But it's very powerful to be able to change the look of something, without touching the code that makes up the site/app content. And change theme by replacing the CSS-file.
When I make something, I want all and just the relevant pieces of what I am doing in my face, and then I want them gone when I do the next task.
So if I were to every try to design a page, I want all the relevant design items there when I am figuring it out, and then when I am done, I don't want to see them again.
So if you spend a lot of time designing the html/css then this approach makes sense. I don't want to jump into the css file and then back in the html file.
However, if I want a particular look and feel for a site, and then knock out the css, then I want the css in a different file and then I want to focus on the layout and the logic.
So my guess is that the original author builds lots of new sites and moves on. My guess is that the original author does not build one large site for a large company that has a consistent look and feel for years (till the rebrand).
> Web design really isn’t my strong suit [...] for probably like 12 years now [...] and am making no efforts to improve
Is this ignorance common among those for whom functional CSS makes sense, or are there any CSS experts who like it? I'm bewildered by the popularity, as I am by several other fashions.
Sometimes I wonder if these choices come from blog-driven development. I used to feel a bit insecure that I didn't go to school for computer science. I tried to make up for that by reading books, many books, cover to cover. Reading a great book cover to cover gives you a coherent understanding of the beginning, middle, and end of a language or tool. Also I read references: the list of core PHP functions, the jQuery API, and the list of CSS attributes. I didn't memorize them. I just tried to understand the gist of each, filed in the back of my mind, enough to prod me to find it in the reference when I needed it. But if you are learning by blog and Stack Overflow, do you ever come to an overall, comfortable understanding of something?
I grant you that it will take some time, but so does learning these frameworks. The frameworks seem to fix one problem while planting three more. And Julia Evans is a technically minded person. She has written about Git and the Linux command line. Which is more complicated, Linux or CSS? I had always thought that HTML and CSS were meant to be softballs, for people who are geeky but maybe not full-fledged programmers. HTML and CSS were the first languages I learned, but my coworker stressed to me that they weren't full-on programming languages.
> It’s 2018! All websites need to be responsive!
I wonder if responsiveness is another cause for this trend. I agree that making pages that shrink and fold for various screens might put some novices over the edge. But looking the simplicity of Julia's website, maybe all she needs is a viewport meta tag.
Another advantage I've had is my lifelong interest in graphic design. Before I knew CSS I knew about color, fonts, white space, etc. So I'm sure that made learning CSS easier for me. But for those who aren't into that, why aren't templates and stylesheets from other people enough? They've already chosen fonts and colors and margins and stuff that looks good together. They give classes for various kinds of pages and sections. Maybe you're somewhere in the middle, where you're not adept enough to write your whole CSS from scratch, but you want more customization than just using a general stylesheet. But why can't you tweak it? If you're smart enough to use Tailwind, aren't you smart enough to fiddle with some attributes in a stylesheet, make the corner rounder, make a font bigger, etc.?
I truly am interested in understanding, if possible. CSS has a few things that are mildly annoying, but just mildly. Nothing would ever make me want to do something like this. Truly I am bewildered!
One more thing: my attention is spread across many complex applications, thousands of lines of code, and I am in charge of the full stack (JavaScript, HTML, CSS, PHP, Apache, SQL). So it's not like I get to spend all my time focused on the front end. Yet my users have told me that my pages look nice. I'm spread thin, but I've never wanted to use anything but stylesheets, no BEM, no SASS, just good, old-fashioned selectors.
Tailwind, along the same lines, proposes a contrarian idea and it will only make sense once you start working with it. Here's what I have seen happen frequently: As the CSS grows, so does the bloat and repetitiveness of the same basic style. Let's say you want to position elements in the center of a component? "display: flex, align-items: center" easy. But what do you do when you encounter that same requirement again? Creating a utility class and replacing existing once will be a pain, so you add the same styles again. And that's how folks you end up with a megabyte of CSS doing a job that could be done in <100Kb.
This pattern is more pervasive than you think. The fundamental problem is that we are not thinking about styling in terms of composability of basic styles.
The benefits of utility classes outweigh the cons. You can iterate faster, you don't have to fight the framework, you don't have rethink abstractions at every point ("this style belongs to a component or a utility class") and as CSS becomes more expressive you'll need fewer classes anyways. I hope Tailwind takes off because styling definitely needs to be less painful than it's today.