DEV Community

loading...
Cover image for What are your thoughts on Tailwind CSS?

What are your thoughts on Tailwind CSS?

nickytonline profile image Nick Taylor (he/him) Originally published at iamdeveloper.com Updated on ・1 min read

Photo by Mahkeo on Unsplash

I'm curious what people's thoughts are on Tailwind CSS. I'm a big fan of Refactoring UI (part of my frontend developer resources), so that's how I came across Tailwind.

The use of utility classes seems appealing, but also potentially overwhelming. On the other hand, having all these utility classes could be nice instead of going all bespoke.

I have not used it myself, but I'm planning on doing so in the very near future to take it for a test drive. I'm curious what others experience in the community has been using it.

Dog owner asking their dog what they think

Discussion (119)

Collapse
koresar profile image
Vasyl Boroviak • Edited

None had mentioned yet that it enables non-css devs to do css. I'm a backend dev who wrote a beautiful Web app not knowing css language.
Being a css hater I'm a tailwind lover. ❤️

My .vue files do not have <style> blocks. All visual styling is in <template> part.

Collapse
ashleyjsheridan profile image
Ashley Sheridan

As a backend dev, don't you find this violates separation of concerns? The HTML should have no knowledge or care about the appearance it has, which Tailwind classes do. However, Tailwind could be used if you're using a preprocessor like SASS or LESS, using classes in the HTML that describe the element/component and then building your CSS based on extending the Tailwind styles.

Collapse
koresar profile image
Vasyl Boroviak

I find that most developers misuse the word "concern". Often Frontend devs think that technology is concern. But CSS or HTML or JavaScript are not concerns. They are technologies, languages.

Here is what Wikipedia says:

When concerns are well-separated, there are more opportunities for module upgrade, reuse, and independent development. Hiding the implementation details of modules behind an interface enables improving or modifying a single concern's section of code without having to know the details of other sections and without having to make corresponding changes to those other sections.

The less files you need to edit to make a necessary change - the better your concerns are separated. (Hence I like Vue.js.)

In other words a concern is: a searchable drop down component, or a user profile page, or a login form, or feature of some kind. But not a programming language.

Tailwind is the next step in the concern separation game. My HTML and classes (and some JavaScript) are blended together within the <template>. It allows me to drop <style> and the css language altogether. Thus concentrating my concern more within the <template>.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

Having fewer files to update doesn't really mean you've separated concerns. An extreme example is the typical spaghetti code where your entire app logic is within 1 or 2 files.

Blending multiple languages together into a single file feels very much like the opposite of SoC. The code is tightly coupled both ways, the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future. Think about it in terms of dependency injection. You should remove tight coupling, and ensure that each layer only knows about the it's immediate relations.

Thread Thread
koresar profile image
Vasyl Boroviak • Edited

the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future.

It's actually vice versa. It was very easy to move and change a component written with Tailwind. Extremaly easy. 😉

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

But you're putting the responsibility of appearance on the HTML, which it shouldn't care about. I realise it makes things easier for a backend dev that doesn't know much about the front end, but it's basically the equivalent of not using dependency injection because you prefer each class to create all the instances of everything it needs by itself. Sure, it works, and it can be done very quickly, but it's not clean, and it isn't going to be very maintainable at scale.

Thread Thread
koresar profile image
Vasyl Boroviak

If you Google other people opinions on Tailwind you'll find numerous claims that it is actually more scalable, more maintainable.

To believe all those people you'd need to try it yourself.

Let's close this thread until you compare the traditional semantic CSS with Tailwind yourself on a real project.

Cheers! 😀

Thread Thread
koresar profile image
Vasyl Boroviak

twitter.com/lesliecdubs/status/122...
I found this just now. A poll on twitter. 😀

Thread Thread
sshanzel profile image
Hansel Solevilla

Hi @ashley , I like that you are fond of separating the concerns but when it comes to HTML and CSS whether you put them in a different file or not when you make changes you'd have to touch both of them as the HTML fully relies on the specifics of its design from CSS.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

Tell that to the people who produce the wonderful designs at CSS Zen Garden. The HTML absolutely does not need to change with the CSS whenever there are changes.

Thread Thread
koresar profile image
Vasyl Boroviak

It certainly does not!

But the reality is that 80% of the time HTML and CSS have to be changed simultaneously.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

That's usually down to developers not separating concerns correctly. If it's adding/removing content, sure, that makes sense, but if it's just because you need to change the appearance of something, then it's a sure sign that something wasn't done in the cleanest way.

I think this can stem from two scenarios: devs who are up against the wall with a tight deadline (this is probably the number one reason for unclean code), or devs who aren't as experienced with frontend and don't know the best approach to a particular task. These scenarios happen, and they will always happen. What we should constantly try and do though is always learn and strive to do things the best way possible. Tailwind voids separation of concerns, and contributes (in a bad way) to the overall file size of the page. That's absolutely not the best thing to do for the web.

Thread Thread
koresar profile image
Vasyl Boroviak • Edited

Tailwind improves separation of concerns IMO.

AND
Maaate, your are so very wrong by saying that Tailwind increases page size. Actually, it's quite the opposite. Full gzipped CSS is 10-20kb for large websites. And 5kb for my entire medium website (~20 pages).

Again, you have no ideas what you are taking about until your try it.

I can't explain what is a red colour to a blind person who never saw it.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

If you're counting page size only on the Gzip version, then you're missing the point. Total bytes downloaded is a metric, but not the only important one. Lots of repeated code makes for absolutely amazing gz compression resulting in very small downloaded bytes, but it still has to be uncompressed, parsed, etc, all of which can have a pretty major impact on devices on the lower end of the capability spectrum. Look at both compressed and uncompressed. It's not an absolute 1:1 match against required processing power on the end users device, but it's a fairly good indicator.

Thread Thread
koresar profile image
Vasyl Boroviak

What's the point of measuring uncompressed if the entire internet delivers compressed?
Also, uncompressed Tailwind is also much smaller than the classic Semantic CSS approach.

I feel like you're looking for any excuse to prove that I'm wrong just to prove that I'm wrong without even googling anything about Tailwind. 😂

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

We measure compressed for transport performance, and uncompressed for performance on lower end devices. If a file is 50kB uncompressed, that's alright (although still very high for something like a blog or personal website), but if it uncomressed to 1MB, then it has a big impact on devices with less power (basically what a huge chunk of the world is using). The bigger the file, the more memory it requires to hold (a low end device doesn't have an unlimited amount of memory), and it requires more processing power to parse, thus leading to longer delays on First Meaningful Paint (FMP), more impact against battery life, etc.

You say I need to Google things before replying, but I feel that you don't actually understand the points I'm making. I understand what you're saying, but your arguments aren't refuting my points, so there's nothing yet for me to "Google".

Thread Thread
koresar profile image
Vasyl Boroviak

Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.

Again, try Tailwind before bashing it.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.

Is it really? That number seems like it might be a wild guess without substantiation. Just by looking at a few sites using it, you can see that most often, the produced files are large (taken from a list of top sites using Tailwind, and Tailwinds own site):

Site Compressed Uncompressed
tailwindcss.com 19.15kB 110.21kB
support.zwift.com 127.85kB 1.84MB
loyalcompanion.com 57.77kB 390.61kB
fri.uni-lj.si 186.62kB 1.84MB
quad.hw.com 127.85kB 1.84MB
holstee.com 95.82kB 694.33kB
dmc-modesto.com 61.5kB 329.36kB
delraymedicalctr.com 61.5kB 329.36kB
wigwamwonderland.co.uk 52.81kB 301.19kB
askfavr.com 113.43 1.02MB

If a websites CSS file is in the hundreds of kB uncompressed, that's not great, but if it reaches MB, then something is awfully wrong.

Now, you could argue that this is just because they haven't got any kind of purge/pruning as a part of their build process, but that same argument could be made of any CSS, it's not a unique thing that only Tailwind has, so it's not a factor. What absolutely is a factor is the default, and as you can see from a couple of these websites that include the default (non custom) Tailwind CSS, the result is in the MB end of the scale.

You can ignore this if you don't know or care about the impact this has on low powered devices (e.g. mobiles, which is what most of the worlds web browsing is performed on these days) but that doesn't actually make the problem go away.

So, you can keep on requesting that I "try Tailwind before bashing it", but I think I have shown that I do understand what I'm arguing. I'm not trying to downplay your own development experience, but I am not wholly certain you understand the point I'm trying to make.

Thread Thread
koresar profile image
Vasyl Boroviak

Mate. PurgeCSS is built into Tailwind-css. No one uses Tailwind without PurgeCSS.

Also, that number is coming from my two large projects.

I'm trying to tell that your point is based on false (or lacking) info.

Before bashing anything your should study it.

Thread Thread
bernhardh profile image
Bernhard Hörmann

Ehm. Ashley just provided you exact numbers - so your assertion, that "no one uses Tailwind without PurgeCSS" is already proved to be wrong, before you wrote that. And your main argument is, that Ashley is false because YOU think he hasn't tried it. Thats not an argument for (or against tailwind), thats just bad argumentation style.

I want to pick up one main point in your argumentation:
"The less files you need to edit to make a necessary change - the better your concerns are separated."

If this is true, than tailwind is really bad in separation of concerns. Let's think about a simple example: Lets say we have a website with multiple forms on it. We decide to make all form elements have a grey text color and round corners so we add to douzens of files (doesn't matter if its HTML, Vue, Blade, Twig or whatever) these tailwind classes. Some days later, a designer (or the CI team) decides, that all form elements should be with green text color and without a border.

Now the 1000$ question - how many files do you have to update if you use tailwind? How many if you use for example bootstrap?

And if you are talking about file sizes and performance - CSS (zipped or unzipped) is just one messurment (and tailwind isn't that great in this category either). What about HTML size? Surfing on a website visiting 30 pages of it, I will only download (and parse) the css one time, but the HTML 30 times. So what is smaller and faster:

Tailwind:

<button class="bg-blue-500 hover:bg-blue-700 text-white 
    font-bold py-2 px-4 rounded">
  Button
</button>
Enter fullscreen mode Exit fullscreen mode

Traditional aproach

<button class="btn btn-primary">
  Button
</button>
Enter fullscreen mode Exit fullscreen mode
Thread Thread
koresar profile image
Vasyl Boroviak

May I ask you to watch this 17 min video before making any more false statements?
youtube.com/watch?v=R50q4NES6Iw

image

Thread Thread
bernhardh profile image
Bernhard Hörmann • Edited

First of all - this comparison isn't a very good argument for your point. It shows, that uncompressed html with utility-first is just trash. Gzip is worse and only with brotli it is minimal better (0.8 kb).

You also mentioned, that utility first is soooo easy, but it only perform well, if you add extra steps to it, so you weaking your own point.

Second: This comparision isn't fair at all. She compares an "old" version of a side, which grews over time with a completle new created, optimzied version. Its like you would say - hey, my new Honda is much better then my 30 years old BMW.

To be fair, a lot of the arguments in the video are true or some kind of true. But she basically only picks aspects, where utility-first aproach is performing well. The aspects which dont fit well for her point are ignored or she just says "its ugly, but live with it". She also compares more or less "hardcore" sematic vs "utility first" mixed with semantic ("create button classes") and promote it as a feature of utility first only.

I totally understand, that the new kid in the block has to show his muscles, but this "I am the new super hero for all cases and everything what we have done till now is wrong," behavior is just stupid.

Thread Thread
koresar profile image
Vasyl Boroviak

Let's just see if it's better than the existing CSS frameworks. Time will tell.

twitter.com/GuamHat/status/1316845...

Thread Thread
koresar profile image
Thread Thread
redbar0n profile image
Magne

He had a lot better objections to the idea of TailwindCSS than "I don't like it". You're not really refuting any of his objections. So to me it seems you're putting forth the inverse of what Evan said. It comes across as: "I like it. Look, it's popular. You just don't understand it". It's not very convincing for us readers trying to evaluate TailwindCSS on balanced terms. I was hoping for better arguments and refutations in favour of TailwindCSS here, really.

Thread Thread
koresar profile image
Vasyl Boroviak

Time will tell. :)

State of CSS 2020 review: dev.to/lukekyl/2020-state-of-css-i...
Alt text of image

Collapse
trixn86 profile image
trixn86 • Edited

I'm not sure if anybody already posted this but here is a link to a blog post of the author of tailwind css explaining why "Separation of Concerns" is a Strawman in his opinion and how he got from the "traditional" way of handling styling to utility first classes: adamwathan.me/css-utility-classes-...

It is a very convincing read and totally reflects how I feel about the topic given the years I spend developing web applications.

You should give tailwind css a try on your next side project.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

I did read it, but I'm still not convinced. Even just looking at the CSS that results on the Tailwind site there seems like too much, coming in at 144kB uncompressed. While that's not as bad as some of the sites that seem to be using the full Tailwind without anything stripped out, it's still more than feels necessary for a website like that.

Thread Thread
trixn86 profile image
trixn86 • Edited

That's not very big at all and also is due to the fact that the tailwind website itself uses most of the utility classes including all the breakpoints for demonstation purposes in the examples. The average website will have much less than that.

The site you are writing this on has >400kB of uncompressed css.

And adding just some examples of the most popular css frameworks websites: getbootstrap.com has 153kB uncompressed, bulma.io has 437 kB uncompressed, materializecss has 161kB uncompressed. Semantic UI has a whooping 628kB uncompressed. So all of those are acutally bigger in uncompressed size.

Stackoverflow has about 700 kB of uncompressed css. Reddit is a little hard to measure as they load css in chunks but in total it's also way above 144kB. Netflix has >700 kB. Instagram has >300 kB.

A more common example may be ottonow.de (a german shopping website). It uses tailwind css and has some more semantic css added. Total css uncompressed is 64 kB.

Also it has to be noted that tailwind builds do not grow at the same rate if you add new elements to the site. If you use all the available utility classes (which should never be the case) it reaches its maximum size while on a website with semantic css it will still grow as you have to add more and more css.

But even if it would be true that tailwind builds are somewhat bigger in uncompressed size: If that is your best argument in response to the article I linked then you will find about any excuse to not have to change your mind. This isn't even a metric that is very relevant. Much more relevant is kB over the wire and time to interactivity. Compressed size is absolutely fine and the tailwind site feels very snappy to me. No issues whatsoever.

This whole discussion reminds me of the people that said reactjs was bad when it came out. Now if you ask about any web or full stack dev they wouldn't look back for a second.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

I think there's a lot of hype surrounding Tailwind that's touting it as a magic bullet that will solve all problems. The fact that there are a lot of websites out there using over 1MB of Tailwind is a sign that it isn't. Now, for whatever reason, something is going wrong on those websites. Maybe the developers didn't run any cleanup tools afterwards, but the question then becomes "should they need to?"

Thread Thread
trixn86 profile image
trixn86 • Edited

How did you count those websites and how do you know that it's "lots" in relative terms? Can you provide some examples of those websites?

Also, why should I care? There are many sites out there that are incredibly poorly made not using tailwind at all. I don't measure the usefulness of a professional tool in terms of the number of people that don't know or don't bother to use it correctly. Running the "cleanup tools" is a matter of minutes to setup and a matter of seconds to run if you know how to do it and doesn't have any weight compared to the improvements in productivity and maintainability. And knowing how to do it is a 5 minute read in the "Optimizing for Production" section of the docs. I don't see how this is even an argument. Also ff you use a bundler like webpack to develop your web application in the first place the build chain is usually already there. You just have to provide the paths to your templates or react components or whatever it is you are using and the tool does the rest.

And yes, there is a hype around it but I like to stick to the actual arguments for why this tool is better than the others for my use cases. I'm not interested in tailwind because everybody talks about it but because it has convincing actual arguments for it while having many years of experience in developing web applications with the existing tools and knowing their weaknesses and pain points.

Thread Thread
koresar profile image
Vasyl Boroviak

Mate, in this thread I told them few times that none is using Tailwind without PurgeCSS.
But they simply ignore this fact.
No point in arguing here.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

If that were truly the case, there wouldn't be websites out there using 1MB+ tailwind.css files. Given that there are, there is clearly an issue where PurgeCSS (or an equivalent) isn't a natural part of the ecosystem. Even if it seems a natural pairing, unless it's a first class citizen partnership, it means that Tailwind has the same problem of other CSS frameworks/libraries: there's a lot that just isn't needed.

Thread Thread
trixn86 profile image
trixn86

There has always been and will always be a problem with people not bothering to ship bad code. How does the number of websites that have shitty bundle sizes has anything to do with that? It's 10 min of work to setup the optimisation and the fact that those people didn't do it is not a problem of tailwind or purgecss but the fact that those people do not care.

You claim is basically: Not all people fasten their seatbelts therefore cars are bad unless the have a built-in first class automatic seatbelt fastener.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

If it's not built-in and enforced by the library/framework, it will be ignored, and eventually becomes almost a defacto standard.

It's more similar to people not fastening their seatbelts because seatbelts aren't part of the car, and the driver needs to install them when they purchase the car. Because they're not built in, people won't use them unless something enforces their use.

Thread Thread
trixn86 profile image
trixn86

Again, there is a section in the docs describing the optimisation process which is literally a few-minute read and easy to follow and understand. The docs also describe, how to install tailwindcss and that includes autoprefixer and postcss. The reason that tailwind doesn't enforce installation of those is, that nowadays many people have custom build-chains and tools and there is no one-size-fits-it-all approach. Still, the recommendations are to install it and the docs only really describe how to install those together. Everybody that follows the "Installation" section will install it.

Your argument still boils down to "Some people don't care about bundle size and ignore the installation instructions therefore the framework itself sucks". Have you even read the docs? It clearly points out that you should install postcss together with tailwind and also how to do so. Not following that is a failure of the user, not of the framework.

Collapse
koresar profile image
Vasyl Boroviak

Hey mate. Just found this little tweet for you. It's doing a better job to explain things than me in this thread.
twitter.com/drewm/status/122940127...

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

It's explaining the same things in slightly different ways. I still don't think that my points are fully addressed within the first few dozen comments. In-fact, one of the prevailingly common comments in that thread is that it makes styling easier for non-CSS developers, which to me is an indication that those developers don't care about the quality of the CSS (how can they if they don't know CSS and aren't actually writing it?).

It might work fine for them, but it's a bit like using a hammer to force screws into wood. Over time the workmanship of the whole thing will suffer.

However, I see we will never agree about the merits of Tailwind, and that's the great thing about this kind of technology, the very fact that we can disagree on the tech ultimately means that we get better tech in the future.

Thread Thread
nomikz profile image
nomikz • Edited

Yes, It is good to separate concerns.

But if you look at bootstrap the most popular css framework, you will notice that it is mixing the styles and the html template too.

When using bootstrap, you put bootstrap's style classes into the html. So it is not fair to say that tailwind is bad because it is violating the separation of concerns.

Being a hard core backend developer and trying to write clean code, you may hesitate to use tailwind and its utility approach. But more and more people, are coming to enjoy utility approach. Most ui frameworks are based on utility first approach.

However, when building my own site, I did not use any ui framework. I tried to do it in the cleanest way so chose to do it with scss + flexbox + BEM. Not many irrelevant style classes. But I have to say this approach may take more time.

Thread Thread
koresar profile image
Vasyl Boroviak • Edited

Again and again and again people think that CSS or HTML are concerns. Remember.

  • CSS is not a concern.
  • HTML is not a concern.
  • JS is not a concern.
  • Any other technology is not a concern.

A concern is synonymous to the word feature. (See Wikipedia for example.)

Your need to separate FEATURES, not technologies.

Thread Thread
ashleyjsheridan profile image
Ashley Sheridan

Not quite. Dependecies of anything should be limited to one way. It's quite ridiculous to be specifying so many classes in the HTML for styling, and it means that it a) doesn't lend itself very well to a component based system and b) ties itself too closely to Tailwind, meaning it's almost impossible to break from it cleanly in the future unless you create something that mirrors the exact behavior of Tailwind.

Oh, and as for the filesize of Tailwind: over 1½MB uncompressed. That's way too much for the browser to be expected to parse on a low end mobile device.

Thread Thread
koresar profile image
Vasyl Boroviak

50kb is my uncompressed Tailwind file. Because Tailwind goes together with PurgeCSS.

Mate, I beg you. Just google it before writing this nonsense. This is basics.

Thread Thread
chrisbarry profile image
chrisbarry

Ashley Sheridan, I find your angle about saying that hmtl/css/js to be separated is fairly incomplete. If you think about everything that exists in any decent piece of software, then everything is a tree of components (or views, or divs or whatever you call them) and these things will have some associated styling perhaps, some logic perhaps etc)

It makes most sense for these things, if they exist in one place, to be defined in the component. What you then want is a mechanism for moving styling or logic to a more global place, if it makes sense to. But lots of the time, it makes sense to have it next to the place that it's needed.

Separating for the sake of it is like just introducing a service orientated architecture or micro services, just because.

Also, it's like organising by technology, rather than by feature, which I think makes a lot more sense. A big folder of all controllers or views (as many frameworks organise) doesn't really make sense to me, once you've done a lot of organising by feature.

Thread Thread
jmmendez profile image
John Mendez

Ashley, this talk clarifies Vasyl's points. They specifically address separation of concerns, clarifying that even CSS garden isn't separated as you believe. Because although the html has no awareness of the css, the css is fully aware of the html. Should the html change, the css breaks.

I started listening to the talk as a skeptic, and it really cleared things up for me.

youtu.be/R50q4NES6Iw

Collapse
jawadcode profile image
jawadcode

If you dislike CSS then should you really be working with the frontend at all?, tailwind is also a complete violation of separation of concerns

Collapse
koresar profile image
Vasyl Boroviak

Separation of concerns is not separation by technology.
Concern is a synonym to feature, or page, or component.
See Wikipedia.

Thread Thread
peerreynders profile image
peerreynders • Edited

See Wikipedia.

"A concern can be as general as the details of database interaction or as specific as performing a primitive calculation, depending on the level of conversation between developers and the program being discussed. IBM uses the term concern space to describe the sectioning of conceptual information."

Separation of concerns is not separation by technology.

The separation was never about "technology" (or file types, though unfortunately it's an extremely common misconception even in the Vue documentation). The separation comes from the web browser's approach to fault tolerance and resilience. That approach ultimately lead to the practice of progressive enhancement.

Aside: The Resilient Web, Chapter 5: Layers

As Aaron Gustafson put it:

  1. Content is the foundation
  2. Markup is an enhancement
  3. Visual Design is an enhancement
  4. Interaction is an enhancement

(And then SPAs (with native-envy; initially targeting desktop) made it all about JavaScript)

So in terms of concerns

  1. Structured Content (HTML)
  2. Visual Design (CSS)
  3. Interactivity (JavaScript)

The technologies are simply a consequence of the intentional layering of making content the top priority.

And if you look at OOCSS you'll find that even within CSS there are multiple concerns - for example: separate structure and skin - i.e. while a module/block should have autonomy over it's structure, the definition of it's skin should be separate (otherwise theming the module in accordance to the page/site as a whole becomes impossible).

Modern JS frameworks tend ignore this separation because they are all about JavaScript. To this day browsers still process HTML, CSS (layout), and JavaScript (behaviour) separately and a lot of the performance strategies focus on preventing JavaScript from blocking the other two layers from doing their job.

  • JSX isn't markup. It's a domain specific language with an XML-style syntax which only exists to generate JavaScript.
  • Similarly the template in Vue's single file component simply exists to generate JavaScript. At least the CSS styles can be extracted separately.

So none of these technologies conform to the "browser layers" because everything is just collapsed into the JavaScript layer. That is why SSR has to be used to get some of the performance benefits of "the layers" back.

Some argue that it's time to build the "application web" but the current layering acknowledges that the network is never going to be perfect. For the "document web" the tradeoffs are clear - content is king while visual design and interactivity are expendable. What are the tradeoffs that the "application web" can make when things start going south? Many "modern web apps" will only work under near perfect conditions, don't degrade gracefully, much less have their own vision of what progressive enhancement should look like.

Douglas Crockford wrote in 2008: "JavaScript is most despised because it isn’t some other language. If you are good in some other language and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying."

These days "the web" is similarly despised. Seems many want to develop for the web as if they're developing a desktop application or at least some native application. That ignores that the web by its nature is distributed - there is no abstracting that away. And while native apps may use the network they are typically much less constrained by it. The browser's ServiceWorker API tries to make "the network an enhancement" by creating the opportunity to cache all essential parts of a web site for offline use but in general browser-based apps have to operate under more severe constraints than native apps.

Aside: Web vs. native redux (2015)

Another issue is that while the web strives to be a universal platform it isn't one platform - which is why people coming from (or wishing for) a more monolithic environment judge many web technologies (including CSS) as weird.

Aside: Front end and back end (2015)
Aside: Web development as a hack of hacks (2016)

CSS seems especially weird to software developers as visual design composes very differently from software. Object orientation values encapsulation, functional programming values functional purity and immutability. In contrast a "visual component" has to maintain its structural integrity while also having to adapt to its surroundings in order to become a "harmonious part of the visual whole" - so defining styles to compose visually is very different from composing software behaviours.

Aside: Don't QWOP Your Way Through CSS (2017)
Aside: You'd be better at css if you knew how it worked (2019)

Point being: The familiarity heuristic will lead you to favour tools aligned with your current mindset. However when the domain requires a significant shift in thinking (e.g. from software development to visual design, styling) then a shift in mindset is required to become truly effective (rather than subjectively productive; many paths to "apparent productivity" can compromise quality) - no tool can replace that necessary shift in mindset.

Perhaps that may explain statements like:
"I don’t think it’s a coincidence that back-end developers have written most functional CSS libraries."

Other more design-minded opinions seem to range from "it's useful for prototyping" (not for the final product) to "if it works for you, why fix it". But that's hardy a universal endorsement and doesn't explain the "best thing since sliced bread" popularity. That is explained by:

  • Editor support for choosing utility classes
  • Dispensing with (ignoring?) the need to identify appropriate abstractions and names (don't make me think)
  • Leading to a sense on increased productivity

I'm still skeptical that this approach is maintainable in the long run as style-centric classnames convey no intent behind (or provide any meaningful organization of) the selected property values - just because the values are right in front of you doesn't explain what particular aspect of the visual design/component they support.

Thread Thread
koresar profile image
Vasyl Boroviak

This is a deep write up.
Has to be an article.
Do you want to post it separately (as a post, not a comment) for further discussion?

Thread Thread
peerreynders profile image
peerreynders • Edited

Not sure it's worthy of an article - right now it's more a collection of thoughts (and links to background information) that highlight some inherent characteristics of the web that a lot of people (and tools) just want to make "go away" (whether that's reasonable or not).

While I may have given a different perspective of what "separation of concerns" means in reference to web browsers that doesn't really put it into relation to Tailwind CSS. Adam Wathan actually does note in his article that "separation of concerns" isn't the core issue:

Instead, think about dependency direction.

He goes on to rationalize why it's OK for HTML to depend on CSS:

  • CSS that depends on HTML: HTML is restyleable, but your CSS is not reusable.
  • HTML that depends on CSS: CSS is reusable, but your HTML is not restyleable.

By emphasizing "reusable CSS" he justifies HTML that depends on CSS.

This can be judged as either "clever" or "very wrong".

"Clever" because "HTML that depends on CSS" gives permission to drop the loose coupling that approaches like BEM invest in and replace it with HTML to CSS tight coupling. While typically loose coupling is highly valued it does tend to create extra work - so if you invest in loose coupling where it doesn't show a return it's a pure waste. This tight coupling manifests itself in the style-based class naming that is used in the HTML. Ditching the indirection of a loosely coupled (meta) naming system is going to save work - "reusing CSS" serves as an additional incentive to embrace the HTML to CSS tight coupling.

"Very Wrong" because of the fundamental notion of "Visual Design is an enhancement" (see previous comment). HTML and CSS are often described as being co-dependent - largely because it is sometimes necessary to add elements and class names to markup to expose additional binding sites for styling (though divitis and classitis describes an overuse of that practice).

In my view the reliance of CSS on selectors tightly couples CSS to HTML structure. CSS declarations with selectors that don't bind to any HTML are essentially dead code - this is why Tailwind CSS has to use PurgeCSS to eliminate dead CSS.

  • CSS is tightly coupled to HTML due to CSS selectors binding to the HTML markup structure
  • HTML is tightly coupled to CSS due to style-based class names

Typically bidirectional tight coupling is only a good thing if both ends are part of one cohesive whole - but:

  1. Content is the foundation
  2. Markup is an enhancement
  3. Visual Design is an enhancement

i.e. while visual design builds on markup there is a distinct separation between both which is why people keep bringing up "separation of concerns".

Approaches like BEM accept the inherent CSS to HTML tight coupling and invest in HTML to CSS loose coupling (via naming that isn't style specific).
Giving Tailwind CSS the benefit of the doubt, it tries to weaken the inherent CSS to HTML coupling by supplying a library of predefined selectors (lessening the need to work in style sheets) in order to exploit the perceived benefits of HTML to CSS tight coupling.

At the very least it should be acknowledged that Tailwind's approach goes against the grain of CSS.

In this context HTML, CSS, and Dependency Direction makes an interesting observation:

we don’t have any long-term data to tell what difference HTML ← CSS (HTML depending on CSS) and CSS ← HTML (CSS depending on HTML) make.

The Tailwind CSS community reports that editing HTML is more productive than CSS.

But I've also observed that individuals who like CSS often don't see the need for Tailwind CSS (e.g. Two cheers for Tailwind, Why I Haven't Jumped on the Tailwind CSS Bandwagon). This gives rise to the hypothesis that perhaps Tailwind CSS adopters feel more productive editing HTML because they are more comfortable editing HTML (i.e. they don't feel comfortable with the way CSS works).

In my view the preference to edit HTML can be problematic. In a comment to her talk "In Defense of Utility-First CSS"" Sarah Dayan states:

If you need to change black titles to red titles, you need a new utility class for red text, and use it in place of the former. Depending on your project, this may either require a find/replace in your codebase, or a single change in a template component (instead of in a CSS abstraction).

??? To me this sounds akin to endorsing changing a JS constant name from const TITLE_BLACK = '#000000'; to const TITLE_RED = '#FF0000'; rather than using const TITLE_COLOR = '#000000';to begin with. This is where the indirection of names that are not based on style values pays off. Furthermore the change from black to red may affect titles in more than one template component but not all black titles in all template components. It doesn't always make sense to capture every styling abstraction above the level of a utility as a template component - like capturing a particular style of title (for the sake of consistency). Also not every useful aggregation of styles warrants a separate template component - aggregate style boundaries can exist within template component boundaries. There is also an overemphasis on reuse and elimination of duplication. Abstractions sometimes simply identify meaningful boundaries even if they they only occur in one single place (while duplication isn't always a sign that there is an (or just one) abstraction waiting to be uncovered). I wouldn't classify the same title style in multiple components as a case of reuse but as a demarcation of a common aspect across various template components.

Back to Adam Wathan's 2017 article - he really zeros in on "CSS reuse" citing About HTML semantics and front-end architecture (2012) as the inspiration for coming to the conclusion:

The more a component does, or the more specific a component is, the harder it is to reuse.

Again "reuse" (rather than demarcation of meaningful boundaries) is being cited as the all important objective. This is the justification for using single property/value utilities as the basic building blocks (pre-built "lego blocks").

In my view that isn't the primary reuse mechanism that the design of CSS had in mind.

In 2016 Harry Roberts published his ITCSS architecture (for one current implementation see web.dev). ITCSS essentially lays out a strategy for wrangling CSS in a way that plays to the strengths of CSS. "Reuse" in the large is accomplished through global styles with a wide reach while narrow reach overrides are responsible for local styling; reuse in the small is largely left to mixins (see also mixin, BEMIT and CSS guide).

Aside: CSS Is Certainly Global And That’s Exactly The Point (2020)

There isn't anything that I can see in Tailwind CSS that encourages "reuse - the CSS way" (it's not actively discouraged either but exploiting it requires an understanding of how CSS works). Template components may repeatedly apply identical properties which really should be candidates for promotion to a "more global" reach via the cascade; leaving this type of duplication in place creates the opportunity for the "look and feel" of the components to "fall out of sync" when changes are only applied to some of them. Always maintaining a style guide could go a long way towards detecting these type of problems early.

In my judgement these type of problems result from the bottom-up approach to styling that is commonly found in the CSS-in-JS type approaches of component design styling. CSS itself is more of a top-down technology - set the overall global environment then override locally only when absolutely necessary. ITCSS coordinates between the top-down nature of CSS and the more local nature of components.

Recently Andy Bell introduced his CUBE CSS methodology which uses utilities but also incorporates some of the ITCSS insights. The first thing to note is that CUBE blends the top-down nature of CSS with the bottom-up approach of utilities - given that composition comes first, top-down gets the first pass. This mirrors "designing the system" before "implementing the components" in software development. The difference being that composition isn't just responsible for identifying the gross layout but also the global styles (i.e. establishing the overall "environment" of the page). And while a utility (generated by Gorko) can be just a rule with a single property/value, it isn't constrained to that. What is important is that it "does one job and does that job well" which can take multiple CSS properties
(aside: Anybody thinking "Single Responsibility Principle"? - that refers to: "Gather together those things that change for the same reason, and separate those things that change for different reasons." - "same reason to change" isn't the same as "single responsibility"; another case of bad naming).
Also "blocks" still have a role to play, whether or not they coincide with the boundaries of behavioural components doesn't matter.

So again I think that Tailwind CSS's definition of "reuse" deviates from the intent behind CSS.

Ran across this interesting tweet:

Confession: The apply feature in Tailwind basically only exists to trick people who are put off by long lists of classes into trying the framework.
You should almost never use it 😬
Reuse your utility-littered HTML instead.

... and further down:

I think buttons are still a good use case for custom classes in a lot of projects
I’m really more just bitter about all of the complexity and bugs apply leads to in Tailwind itself, wish we would have just offered the theme helper instead which is bullet proof.

My only conclusion here is "there is no getting away from knowing the fundamentals" - but that was an open secret even in the Bootstrap days; people just chose to ignore it.

Another observation:

Tailwind CSS users! Tell me what you like about Tailwind.

A point that keeps coming up:

easier to author by non css people

Now it's great to have such an empowering tool and Tailwind CSS operates at a lower level than Bootstrap - but from I can tell using Tailwind CSS doesn't contribute to understanding what makes CSS tick.

Frameworks have the potential to inhibit a deeper understanding of the things they abstract, which is the web platform.

radEventListener: a Tale of Client-side Framework Performance (2020)

This is a recurring theme with lots of popular front end tools - jQuery devalued JavaScript skills, React devalues Browser Web API skills, Bootstrap devalues CSS skills etc., etc., etc.

Aside: Tools don’t solve the web’s problems, they ARE the problem (2015)

From testimonials it's clear that Tailwind CSS:

  • is popular
  • has a number of short term benefits
  • is deemed useful over a wide range of use cases by those who have chosen to adopt it

As a result Tailwind CSS seems to be evangelized heavily but there seems to be a lack of clarity regarding applicability, deliberate tradeoffs, objective caveats, and potential long term (undesirable) consequences.

Thread Thread
koresar profile image
Vasyl Boroviak

Mate. Create a post from this. Call it "just raw thoughts" or something. But it should not be lost in comments section here.
Well written stuff!

Collapse
jmmendez profile image
John Mendez • Edited

It's not a violation of SoC. Rather than do a bad job explaining it myself watch this talk which articulates it well.

youtu.be/R50q4NES6Iw

Collapse
poiu24 profile image
ahmadfarisfs

as engineer who occasionally write backend and frontend, I can approve this !

Collapse
uminer profile image
Moshe Uminer

I'm a big fan of tailwind. In my eyes, the biggest advantage is the fact that there is a range of preset values for everything.

Let's take coloring for an example. Using tailwind you don't need to figure out a complete color palette beforehand, because tailwind will come with 9 shades of every color. And if you don't like the exact color, you can change the configuration. The same is with margins, instead of fretting over the distance, just use a preset. Which margin preset looks better? Take it. And it is so with all of tailwind's classes.

I should note, that tailwind is best used with a component framework, because you definitely don't want to right the same 10 classes 3 times. The framework can take care of the repetition for you.

By the way, the tailwind website had some screencasts for design using tailwind.

You haven't mentioned why you find tailwind overwhelming, but I will guess that it feels like there are simply too many classes to keep track of. I had a similar problem, but downloading the tailwind plugin for vscode gives me code completion. So now I just need to remember that all margin classes start with m-, for example, and the plugin shows all possible classes and their values.

Collapse
autoferrit profile image
Shawn McElroy

I have learned not to worry about the volume of css classes because the way it's designed we won't be using them all. It's basically ergonomics. Like if I want left/right padding on medium and above it's md:px-2. I can almost predict what the css classes will be. And it's usually right.
If you ask me, that's great framework design.

Collapse
zediwards profile image
ZediWards

I am also using it as a means of making design and layout choices easier by limiting myself to tailwinds options. The vscode extension gives me autocomplete with all of that properties options and the actual css property so I dont forget what css I'm actually writing.

Collapse
michaelandreuzza profile image
Collapse
michaelandreuzza profile image
michael-andreuzza

Here a Tailwind color picker colorsandfonts.com/tailwind.html
Enjoy it !

Collapse
nickytonline profile image
Nick Taylor (he/him) Author • Edited

Thanks for sharing your thoughts on Tailwind.

Yeah, I wrote "potentially" overwhelming. Not saying it is, just an impression before having used it. Thanks for the mention of the VS Code plugin and I'm definitely going to watch those screencasts.

Collapse
shaijut profile image
Shaiju T

Why tailwind is better than bootstrap ?

Collapse
rickmills profile image
Rick Mills • Edited

It took me a while to get my head around its benefits over something like Bootstrap, and I did make mistakes along the way. However now I can safely say its sped up development for me significantly.

The biggest thing to remember when using it is that whilst you can just stick every single option on your class, they can quickly become pretty overwhelming to manage.

This has been accounted for though. Tailwind has an @apply method you can use in your CSS/Less/Sass that allows you to create reusable components.

So for example lets assume you've got a box you use all over the place, and its classes look like this:

<div class="mx-2 text-center border-1 border-blue-800 bg-white shadow rounded">
Enter fullscreen mode Exit fullscreen mode

In your CSS you can do this instead:

.card {
    @apply mx-2 text-center border-1 border-blue-800 bg-white shadow rounded;
}
Enter fullscreen mode Exit fullscreen mode

Or to be even more tidy, this:

.card {
    @apply mx-2;
    @apply text-center;
    @apply border-1;
    @apply border-blue-800;
    @apply bg-white;
    @apply shadow;
    @apply rounded;
}
Enter fullscreen mode Exit fullscreen mode

Then on your div you simply have:

<div class="card">
Enter fullscreen mode Exit fullscreen mode

It ends up making it super easy to build out components. Make no mistake though - there is a learning curve, but in my experience so far it's been totally worth it.

Feel free to poke around my first attempt at using it here, I went with a raw copy of tailwind and no custom css for this one, given the size of the site it didn't really need its own stylesheet. You can also use purgecss to strip out any unwanted css to make load times super quick :)

Collapse
bernhardh profile image
Bernhard Hörmann • Edited

Thats a very important feature, but it does then basically exactly what all other frameworks (bootstrap, etc.) does, the only difference is, that you use tailwind instead of css. What is the benefit of using for example

Tailwind

.card {
    @apply mx-2;
    @apply rounded;
}
Enter fullscreen mode Exit fullscreen mode

CSS

.card {
    margin: 0.5rem;
    border-radius: .25rem!important;
}
Enter fullscreen mode Exit fullscreen mode

or even using variables in SCSS/Sass/Less with the same effect?

Collapse
sergiodxa profile image
Sergio Daniel Xalambrí

The idea is that you can use the Tailwind design tokens (the classes) to keep consistency, it also removes magic numbers from your CSS (why .5rem? mx-2 is part of a scale and you can understand the reason behind it).

Also Tailwind team recommends avoiding using @apply, specially if you are using a component based frontend framework like React/Vue/Angular, because now your components are in the framework not in the CSS.

Thread Thread
bernhardh profile image
Bernhard Hörmann • Edited

Sorry, but that is no argument. mx-2 is just another representation of .5rem and the scale is exactly the same since mx-4 is twice of .5rem. The only difference is that you are using some kind of "proprietary" unit instead of standard unit rem. To understand rem, you only need ot understand CSS. To understand mx-2 you need to know tailwind. And if you don't like magical numbers, all css preprocessors understand variables.

And of course is the tailwind team against apply, since its the opposit of what they do.

I dont see that big advantage of using tailwind in comparison of just using inline css.

I some cases, I even HATE Tailwind, when you don't have the full controll of the output html. Just a example - Laravel nova. They use tailwind there. Its almost impossible to change a lot of stuff without really hacky css rules (and they even have some extra classes like btn or card, but way to less of them)

Thread Thread
denu5 profile image
Robert Denus

Berhard its more about the design SYSTEM. Applying this to your comment "to understand mx-2 you need to know tailwind" -> you would need to say: "... need to know your design system". And this makes sense, look at is a contract between designer and developer. Therefore using agreed tokens is a big help instead of any not-systemized values like rem, where you would need to measure by hand any spacings. a good read here: medium.com/swlh/design-system-base...

Thread Thread
youngelpaso profile image
Jesse Sutherland

This is the most underrated use of TW CSS! TW as a foundation of a design system that you can specify your own utilties for, or convert into more 'conventional' BEM via @apply is a really good use case IMO. The way I'm currently doing it is like this:

  • Specify initial TW config w/ custom colors etc
  • Prototype components using utility classes
  • When 'done' use @apply to map those utilties into a BEM style CSS file, which can be re-used later by consumer of the design system, but since its TW based can also be easily purged - if I don't use that class in my docs/component templates, its not exported to the library

CSS-in-JS offers similar structure, but TW is probably (or at least the most popular) CSS-first framework that allows for such easy and systematic style composition/extension.

The next thing I'm investigating is how to integrate 'design tokens' into my TW config file - and there's a couple OSS projects that might fit the bill such as Style Dictionary.

Collapse
clifton893 profile image
Clifton Long Jr.

Wow, that's a pretty compelling argument for Tailwind. Thanks for the explanation!

Collapse
nickytonline profile image
Nick Taylor (he/him) Author

Awesome. Thanks for the info.

Collapse
seangwright profile image
Sean G. Wright • Edited

Adam Wathan, the maintainer of TailwindCSS, wrote an article a couple years ago about the differences in CSS architecture that exist between traditional approaches (BEM, SMACSS) and atomic/utility approaches.

Here's that article: adamwathan.me/css-utility-classes-...

I recommend everyone read it.

Adam doesn't declare that one approach is bad and another is good. Instead he provides insight into what the constraints are of each and what use-cases each might be good for.

In the end he argues that most of the sites/apps he works on benefit from the approach provided by TailwindCSS and other similar libraries (Bulma, Tachyons, even Bootstrap's utility classes).

I think understanding why we should use TailwindCSS is as important (or more) as asking the question "does Tailwind make me more productive?"

And yes, I like TailwindCSS because it fits the type of work that I find myself regularly doing.

Collapse
melissamcewen profile image
Melissa McEwen

Ooo love that post, that answers a lot of my concerns.

Collapse
nickytonline profile image
Nick Taylor (he/him) Author

Thanks for the thoughtful response and link to Adam's post. Definitely going to give it a read. I'm eager to try it out, but thought it'd be fun to get some feedback from the community. Cheers. 😎

Collapse
johndetlefs profile image
johndetlefs

Cracking article - ta for posting - hadn't really thought about separation of concerns as comprehensively as this article, ended up making me want to give tailwind a try!

Collapse
andrewbrown profile image
Andrew Brown 🇨🇦

I tried so hard to make it work, but I felt I was doing the same amount of work but I've just shifted the work someplace else.

I think people are just better off making a handful of utility classes and scoping css per page/component.

Collapse
mskog profile image
Magnus Skog

Huge fan. I was using Bulma for all my project and while that is still a great choice I find that Tailwind is a better fit for me. I can make something that looks half decent with it so that has to be worth something!

Collapse
sergix profile image
Peyton McGinnis • Edited

I was a little put off by Tailwind when I first looked at the examples in the documentation.

Why would I put all these classes in my HTML? Why wouldn't I just use Sass mixins?

But I decided to give it a shot, and oh man am I glad I did.

Once you start seeing patterns and memorizing the basic utility classes, it becomes an absolute breeze to style any component or section of your page might have.

I found it especially great for using flexbox, simply specifying flex and flex-1, flex-grow, flex-shrink, etc.

And the configuration and adding custom classes is very simple and intuitive once you learn it, which doesn't take long at all.

Again, it does seem off-putting at first, but as the docs themselves say,

You just have to try it.

Collapse
w0rddriven profile image
Jeremy Brayton

This mirrors the path I took almost completely. I’ve had relatively lackluster CSS skills and at first drinking from the firehose was really off-putting. There is a ton of stuff to learn if you’re trying to get a handle on everything at once. I found it much easier to retain very little and to just browse the docs whenever I need to implement something. Then when a coworker who is more versed in CSS implements something, I pick it apart and start using the same technique.

Even in taking bite sized chunks of knowledge there’s room for more advanced topics like figuring out how purge css strips extra selectors or how to apply themes. Fortunately there’s also a huge supply of examples as I’ve been fortunate enough to find just about everything I’ve been looking for with a few short google searches.

I also happen to be a fan of letting other people choose sane defaults. It’s not that I’m incapable but it allows me to keep my brain focused on what I need to finish, not get stuck in the minutiae. I also feel way more productive, though that could be a product of applying more knowledge. Even though it lacks the JavaScript components of a Bootstrap, I find I don’t really mind implementing behavior from scratch.

Collapse
deciduously profile image
Ben Lovy • Edited

I'm using it for the first time currently to style my Stencil app.

I think I like it, but I'm also not sure if I'm missing the point. To use it with Stencil, I'm still keeping separate CSS files and applying these template classes manually:

.subtitle {
  @apply italic;
}

.name {
  @apply text-2xl font-extrabold;
}

.cv-links {
  @apply flex mb-4;
}

So, while the built-in utility classes are handy, in a lot of cases I think I could probably be doing just fine without Tailwind. This is kinda like how I'd write up plain CSS anyway. The one big thing I like is the flex spacing - it's pretty easy to tweak and play with to get what you need:

.cv-section {
  @apply flex mb-4;
}

.cv-heading-section {
  @apply w-1/3 px-2;
}

.cv-body-section {
  @apply w-1/2 px-2;
}

.homeaddress {
  @apply float-right;
}

I have definitely not spent enough time defining my utility classes and have repeated segments in a few spots across different components, that might push me more thoroughly to the "pro" camp once I get around to it. It is super intuitive and easy to use, though, I like how quickly I can throw a new idea on my page without diving through a search engine rabbit hole. The docs right on the main page have covered every question I've had so far. I generally dislike CSS and building frontend styling, it's a necessary evil from my perspective, so the frictionless experience is pretty great.

Collapse
uminer profile image
Moshe Uminer • Edited

Hi Ben, I also took that approach before, and while it isn't the recommended way to use tailwind, you do still get one of the big benefits: a range of presets. It means that you won't start tweaking every color and margin that you add, unless you decide it really is necessary (see my comment above). As you mentioned with flex spacing, for example.

Collapse
deciduously profile image
Ben Lovy

You're right, I don't think I'd fully realized exactly how much of a help the presets really are. I've skipped a lot of work by using Tailwind to get my page to the point it's currently at, and didn't even notice because it was so easy to do but still felt as granular as doing it manually.

Collapse
aravindballa profile image
Aravind Balla

Well, I'm a big fan. I will try to respond without looking at what people already said.

I like how the framework is not opinionated design-wise. This help us style things from scratch. When opposed to something like Bootstrap, a button looks a certain way.

The class names are CSS-friendly. I mean it can be easily derived. align-items: center becomes items-center. We will have to look at documentation at lot in the beginning, but as we use we can easily derive. This also making building UI's faster.

And many more to go.

[Shameless Plug] I recorded a podcast episode on this recently - open.spotify.com/episode/07zmevkV4...

I'd recommend you use it.

Collapse
wwayne profile image
wwayne

I've been using tailwindcss for a couple of months, it is my favorite css tool after sass.

Good: Development efficiency; Easy to do the updates and responsive works
Bad: Sometimes a long class name; Hard to start at the beginning(an autocomplete plugin is useful)

For the autocomplete plugin, nothing works for React in Sublime at the moment, so I update another plugin tailwind-sublime-autocomplete to work with className in React, hope it can be helpful :)

screenshot

Github: github.com/nerdy-doggy/tailwind-su...

Collapse
mattwaler profile image
Matt Waler • Edited

Tailwind has made me royally hate using anything else because it's so goddamn awesome. The initial learning curve is slightly challenging, but with the TailwindCSS Intellisense VS Code extension you can even get autocomplete for the classes you have based on your config file.

I write very declaritive markup that shares CSS classes across every component. The footprint is ridiculously small: cssstats.com/stats?url=mattwaler.com

No other CSS methodology or tool will get these results.

Collapse
razbakov profile image
Aleksey Razbakov

The first day i found it i said: I will use it.

I implemented one project (in an alternative @apply why, which is not intention of tailwind). Tailwind actually speeded up the process, but I said: NEVER AGAIN!

After few weeks reading reviews from others I was not sure.

Later I started missing Tailwind.

And finally I started using it for all my projects…

The first benefit of Tailwind - you don’t have to come up with ids and class names for your divs. I love this part. It actually a big time saver.

Second - if you use react / vue and need a component - tailwind is just made for that. If you see repeating yourself with classes - create a component

Third - I don’t have to write any .css file. Everything via html. I was afraid it’s like an inline-styles, but it’s not actually. It’s about using a design system.

The funny thing is when i was using bootstrap, i needed to visit homepage to find a code to copy paste it. even after 1 year using it. It took me few days with tailwind and I rarely visit docs...

Collapse
bobylito profile image
Alexandre Valsamou-Stanislawski

Hey 👋 thanks for asking 😃

I'm a massive fan of having a set of values already sorted out for me. As a developer/product maker, we should always aim for repeatability. And you get that with Tailwind as it shrinks down the number you get to choose from:

  • only a subset of colors instead of the whole color spectrum
  • responsive breakdowns instead of the ones that you've just looked up on google
  • margins and paddings instead of every possible value in the integer set

All of this is configurable, so you get to keep the limited subset with the values that are harmonious with the design.

I hope this helps 🙇‍♂️

Collapse
nickytonline profile image
Nick Taylor (he/him) Author • Edited

Awesome. Merci pour tes pensés Alexandre. A+

Collapse
icawebdesign profile image
Ian.H

I've adopted it for all of my personal projects since the early betas.

I've "done it all" from CSS from scratch back in the day (before less/scss etc) bootstrap (2, 3 and 4) and got to the point when using bootstrap that I was writing so many utility classes myself to fill in voids or change functionality (much easier than trying to rebuild bootstrap) that it made a great deal of sense.

I abstract things out to components for re-usability when it makes sense to do so, else, happy with the classes.

Collapse
drewtownchi profile image
Drew Town

I've written a few articles now about Tailwind and how much I like it. Tailwind works best when used with a component/partials system and I pretty much would consider it a requirement at this point.

One of my favorite parts of Tailwind is the limitations it imposes on your choice by using a constrained set of options. Consistency is hard and limiting your options to a small subset makes managing choice easy.

I really like using it on my personal blog and I really like the fact that is less than <5kb gziped.

Collapse
peerreynders profile image
peerreynders • Edited

Some more skeptical opinions about Tailwind CSS in particular or functional CSS in general:
The perils of functional CSS
I Tried Functional CSS and It Kinda Sucked
Thoughts on Tailwind CSS
Thoughts about Utility-First CSS Frameworks
Utility First and CSS Components: a reconciliation
Dave Shea (CSS Zen Garden) on Tachyons
Jeffrey Zeldman: Kiss My Classname

Also Adam Wathan points out in
CSS Utility Classes and "Separation of Concerns".

I still think there are a lot of use cases where it's more practical to create a CSS component ...but build them using utilities first

Aside: Jeremy Keith's response to that article

Extracting CSS components with @apply

Given that most people use Tailwind CSS with some kind of JS component framework or templating system they never see the need to "extract CSS components". Also the notion that CSS components only exist to eliminate duplication is restrictive - "descriptive and meaningful names" on class selectors serve to communicate (to the future developer) the intent behind applying that particular set of CSS properties. Style-centric class names only inform how an element should be styled rather than why the styles are being applied. CSS is a declarative language (IF this selector matches THEN apply these property values) - in my mind style-centric class selectors make it appear more imperative (which may contribute to the popularity of functional CSS/Tailwind CSS).

A Sass mixin could already do what Tailwind's @apply does:
When to use @extend; when to use a mixin

The need for Purgable HTML makes the class attribute values even more verbose (unless you are willing to manually manage selector exceptions).

In response to the seemingly indiscriminate popularity of Tailwind CSS Andy Bell published his CUBE CSS methodology (tutorial) supported by the Gorko utility class generator.

Collapse
vaibhavkhulbe profile image
Vaibhav Khulbe

I totally like Tailwind. The fact that it's not just another CSS framework but is a utility-based framework is great! 💯

I wrote an article dedicated to my first-time use of Tailwind, here's a snippet:

What sets apart Tailwind is that instead of some predesigned components, it provides low-level utility classes that we can use to completely customize it!

Of course, it's fairly new as compared to other CSS frameworks like Bulma, Bootstrap or Materialize, but I'm sure in coming years it'll boom. I like the fact that new features are added every now and then to this with good community support.

Collapse
sebnitu profile image
Sebastian Nitu

I'm not a fan. It feels more geared towards devs who hate writing or don't fully understand CSS because it essentially just moves your CSS into the HTML with some slight abstraction. Seeing 15+ utility classes on a single element hurts my soul.

Collapse
kal_starkis_383572a61c753 profile image
Kal Starkis • Edited

Well said. The sheer popularity of atomic/utility CSS makes me question myself, but only a little. The old emperor (presentational markup) is back with some new clothes, but his unsightly parts are still on full display. It may well be that those who heed the 'just try it' cry do find that it makes them happy, but it's a biased sample because the devs who try it are the ones who don't cry when they see 15+ utility classes on a single element!

Collapse
ryansmith profile image
Ryan Smith

It appeals to me by providing the benefits of a pre-styled library while still allowing you to create a custom design. The downside is that the design still needs to be created by the developer. Not all developers are detail-oriented when it comes to the front-end, so I could see it being a challenge for some. I have also seen many cases where Bootstrap users do not apply classes/markup correctly leading to elements that do not look as the maintainers intended, so Tailwind's added complexity with applying classes may lead to some designs that are not as polished.

They are also working on Tailwind UI, which I believe will be a paid set of templates created using Tailwind. I think that will help to bridge the gap with the other Bootstrap-like frameworks but I'm not sure if they are providing any parts of it for free. Last I heard, they are expecting to release it in February.

Collapse
itsjzt profile image
Saurabh Sharma

It's great we used it before we went into making Shopify apps. But sometimes things like purge CSS and using React components as a way to reuse logic makes me things we need really need a framework that just makes a 10 character CSS property into 2 i.e flex instead of {{ display: flex}}

Collapse
johnark88 profile image
John Arkema

I decided to give it a try after a co-worker sent me this article

adamwathan.me/css-utility-classes-...
Writer does work on Tailwindcss

So far I am really enjoying not have a giant css or sass style sheet to deal with. Its got great built in breakpoints and handles responsive design well.

Plan to keep using it in the future!

Collapse
tornography profile image
Manuel Schulz

(I actually registered, just to answer here)

I get the point, why tailwind css is so popular. Especially when you don't like or understand css. But there are some points, fans bring up, that I don't get or see different.

"Predefined values" or "no magic numbers"
Setting up a predefined subset of values is possible in sass/less or even with css custom properties like

$margin-2: 0.4rem; // sass/scss
--text-color-dark: #222; // css custom vars
Enter fullscreen mode Exit fullscreen mode

And if you use css custom vars, there's even no delay because of compiling time.

"Naming classes is hard"
So what do they call their javascript functions or the like? a() b() wtf()?

"seperation of concern"
As @peerreynders nailed it. Concerns ar not features but content, markup, styling and functionality.

"I don't need to switch context"
So switching tabs in i.e. vscode is a context switch then?

"I can rapidly code my MVP"
But what about the project in the long term? What about maintenance?
Even in times of using components stylings may may get out of sync.

"the cascade"
You lose the power css gives you. You can style a very component, even with breakpoints and hover. But can you style by context?

.category-a .btn { background-color: red; }
.category-b .btn { background-color: green; }
Enter fullscreen mode Exit fullscreen mode

or

.name-input + .btn { width: 100%; }
Enter fullscreen mode Exit fullscreen mode

I'm really willing to give it a try, as I see the benefit for non-css devs in my teams, so I try to be as open as possible. But until now the "utility first" approach is not my thing.

Collapse
iamschulz profile image
I am Schulz

A bit of criticism on my side.
Tailwind (and atomic CSS b design) miss out on the cascade.
Many people refer to it being easy to learn because of this or enabling non-frontend Devs to write CSS, but that's only half true.
What tailwind enables you is write coherent styles and not breaking you CSS file. What it discourages you from is writing an effective design system.
You'd have to deliberatlely define your styles on each component instead of cascading your styles down. Your components become more robust that way, but also more repetitive.
Another shortcoming is the binding of styles to the DOM. I have a paragraph about that here: A bit of criticism on my side.
Tailwind (and atomic CSS b design) miss out on the cascade.
Many people refer to it being easy to learn because of this or enabling non-frontend Devs to write CSS, but that's only half true.
What tailwind enables you is write coherent styles and not breaking you CSS file. What it discourages you from is writing an effective design system.
You'd have to deliberatlely define your styles on each component instead of cascading your styles down. Your components become more robust that way, but also more repetitive.
Another shortcoming is the binding of styles to the DOM. I have a paragraph about that here: dev.to/iamschulz/in-defense-of-the...

Collapse
skaterdad profile image
Mike

I used it to develop a fairly complicated web app, and it fit my work style perfectly. Love it.

Not having to fight a premade UI framework, or have to context switch to a CSS file to iterate on styling tweaks is a real time saver.

Collapse
dennisk profile image
Dennis Keirsgieter

While i like the idea after trying it (first i was like omg so much classes!?) i am not sure i will use it for something production wise.. I have my doubts about the css file size after purging everything not used vs writing my own css for big websites.. And unfortunately i don't have the time to port one of our bigger client websites to tailwind just for fun and actually compare the file size :)

Collapse
michaelandreuzza profile image
michael-andreuzza

Hey Nick, a fan of Refactoring UI my self too.

My thoughts are that I wish I would have discover Tailwind some months back, when I started to build colorsandfonts.com with Bulma.

It will come that day that I rewrite it with Tailwind....

Collapse
khrome83 profile image
Zane Milakovic

Big fan. It takes a few hours to get use too it.

But it speeds up Development a lot. The defaults are pretty nice, and easy to change.

We moved our entire frontend too it. I love putti by everything in html, even though it makes the markup slightly ugly. I am looking forward to pairing this with Alpine Js in the future.

Collapse
pavelloz profile image
Paweł Kowalski

I like it.

In a new project its a no brainer (especially for those performance oriented).

Im slowly growing to rewrite my companys docs site from bootstrap+custom css to tailwind. This will be interesting experience.

Collapse
dvlpr profile image
Travis Werbelow

I really enjoy it. I have used it for a handful of personal projects and it's great to work with. When I have to use something else, for example at work, I miss it.

It makes knocking something out design-wise, pretty quick and easy.

Collapse
melissamcewen profile image
Melissa McEwen

It saves me a lot of time when working with an unfamiliar React codebase. I know if there is Tailwind there are standard things that I can use.

That said I'm a little skeptical of the long term effects of having to go into every single component to change a style if a designer decides we're doing something different, but I'm not a Tailwind expert so maybe there are architectural choices that can help mitigate this.

Collapse
sroehrl profile image
neoan

I am currently using tailwind in a project and absolutely love it. It's relatively straight forward and combined with postCSS extremely powerful and modifiable.

I noticed that I started to "live design". So let's say you play around with an input until you get to the point where you say "yes, this is how my inputs are going to look like/behave". At that point you ask yourself which of the used classes will always apply and then write your @apply accordingly.

After a while you will notice that you kind of wrote your own CSS framework in doing so.

However, the amount of CSS you will write isn't as much as you'd expect.

So personally - yes, it's awesome!

Collapse
raisaugat profile image
Saugat Rai

I have tried Tailwind CSS in one of our projects. The first few days was confusing and difficult. But once you get the gist of how p-1 and pl-1 works then it's all easy and fast. The implementation is faster than ever. Responsive is also handled way easily.

Collapse
jannikwempe profile image
Jannik Wempe

Awesome discussion going on here :-) I am myself still looking for my perfect fit in regard to styling. I moved from Bootstrap and tried Bulma (which I liked more), but after using React I am still not sure if I prefer scss modules or styled components. On the other hand I always liked the approach of TailwindCSS, but also thought it could be overwhelming in the beginning.

Is there anybody preferring TailwindCSS in components over (s)css modules / styled components? Or the other way around? Why?

Collapse
bluehaoran profile image
Haoran

I feel like everyone I've seen who's a fan of Tailwind is a developer. What do web designers think about it?

For my last two teams, at least, my web designer is still the gatekeeper of good web design, so I defer to them and don't touch the CSS.

Collapse
timvandijck profile image
Tim

I'm quite torn. In Bootstrap I notice I use more and more of the utility classes.
Then again I'm afraid that if I go all utility classes (like in Tailwind) I will end up repeating myself unless I highly componentise all my stuff. Otherwise if I want to change something I have to adjust all the classes everywhere on that type of component.

I can see this being less of a problem when working with things like React, but when I build a content site I don't want to put each button into a partial.

Collapse
mrispoli24 profile image
Mike Rispoli

I just started using it for a new project that is rather large. I've been a big tachyons fan for years but I felt I needed tailwind this time around because it allows for more fine tuned configuration options as well as some additional breakpoints. That being said, it is a lot heavier than tachyons so I added purgecss to the project, which, while not hard was some added complexity so as not to serve the entire library all the time. I also generally found the class names of tachyons a bit easier to memorize (that may just take more time also there are lot less to remember). Overall I definitely will be using tailwind a ton in the future but still keep tachyons in my back pocket for smaller projects where the restrictions of less allow me to develop faster.

Collapse
dennisfrijlink profile image
Dennis Frijlink

I'm a frontend developer who is working with CSS/SCSS/Sass for a couple of years. Of course I thought about using TalwindCSS and tried it a couple of times. I like the principle and their docs/website are awesome. There are only two things that hold me to use it in the future:

  1. Unlearning css. Writing CSS is most of the time more complex than writing code in Javascript. However if you know how to write 'good' CSS, using tailwind would not have many benefits in my opinion and will ensure you'll unlearn how to use css.
  2. I don't prefer class names that are longer than the width of my screen.
Collapse
johnnywalker2k1 profile image
JohnnyWalker2K1 • Edited

Yes, one of the big problems with Bootstrap was that it came with a theme. TailWind fixes this by breaking everything down into smaller "utility" classes instead. This is a smart move, and noteworthy.

Another problem with Bootstrap (and early TailWind) was that it included a ton of unused styles, slowing your site down. TailWind uses PurgeCSS to fix this.

But there are still lots of other problems with Bootstrap that TailWind has, too. And they're unavoidable, despite how fervent TailWind's fanbase is. In fact, honestly, it's like a cult: "Here's a long post explaining why 'separation of concerns' doesn't apply here". Sorry, I don't want to drink the KoolAid.

HTML is concerned with semantics. CSS is concerned with presentation. Two concerns, separated.

But let's go further: Why is this good? Because if you're skilled at writing OOCSS you can write all of your HTML, with all of the styles you will need, without ever having to think about presentation. One pass and you're done.

A skilled front-end developer can write their HTML and never have to come back to it. That also means another developer can pick up the styles without needing to ever edit the HTML. In fact the only reason you would need to edit the HTML again is because the content of the page changed.

But then the TailWind fans try to compare it with other CSS frameworks ("it's smaller!")... as if being smaller than other CSS frameworks is some sort of accomplishment. Let's not overstate things, a "CSS framework" is just library of styles. Competent CSS developers shouldn't be using CSS frameworks with production websites. (Rapid prototyping, sure. Otherwise, no.) TailWind being smaller than Bootstrap isn't a sign of... anything.

Then there's talk about how small it is when it's gzipped. Again, as if this is some sort of accomplishment. Bootstrap 4 is only 20kb once it's been minified and gzipped. The problem has never been the payload size, the problem is the number of styles your browser has to parse! CSS is a render blocking resource, which means that the browser won't render anything until the CSSOM is constructed. Once 20kb of minified gzipped CSS has been ungzipped, that's 147kb of classes that need to be parsed!

The true comparison is the number of CSS selectors for a site written in TailWind vs good OOCSS. (The answer is obvious.)

So in the end, TailWind is good at two things:

  1. Taking a CSS framework (aka library of CSS classes) and making it as small as possible. Given that CSS frameworks should only be used on prototypes, I don't know what the huge benefit of this is. ("My prototype is a bit faster!" Cool.)
  2. It gives developers who hate CSS the ability to avoid CSS. And boy are they fervent about it.

That's it.

Actually it's good at one more thing: Making it harder to rapidly prototype because it doesn't come with a theme, so replying on you trying to make it look good instead. So maybe focussing on utility classes wasn't such a smart move after all.

Be honest, all you TailWind fans: You like it because you don't have to write CSS.

It feels like a boyfriend trying to convince his girlfriend that it's good for their relationship if he sleeps around: "Just read blog post and watch this video! See all the good arguments? It's GOOD for us if I sleep with other women!"

Uhuh, okay.

Collapse
michaelburgess profile image
Mike Burgess • Edited

Whilst I don't necessarily agree with everything you said, it's a good post with some interesting points raised.

I do have you pull you up on this though - "Competent CSS developers shouldn't be using CSS frameworks with production websites".

It really doesn't matter what you used to accomplish it, but what really matters is if people are willing to use or pay for your product?

If two production sites both look good and one happens to be using a CSS framework and the other was painstakingly hand-crafted, what does it matter?

If they portray the right brand image and drive usage / revenue, I'd argue the latter was a waste of time to a certain extent?

Anyhow, this thread was a good read, very lively!

Collapse
michaelandreuzza profile image
michael-andreuzza

I like it a lot, you don't even need custom css....

Look, I am making templates just with that.

wickedtemplates.com/tailwind-templ...

They only use Tailwind and a variable font. Inter.

Collapse
publialex profile image
Alex

For what I tested, it's more a step back to me than a revolution. I don't see where is the gain to give many classes to an element instead of giving it one or 2 classes and then apply the right CSS rules to that classes.

Maybe it can be cool with the latest frontend languages like vue or react that "encapsulate" some kind of components, but when you deal with standard html / css / javascript stack, it's more annoying than helping.

I knew the era of table design, then divs and CSS, I have the impression to go back where you put the style attribute directly on each elements (just replaced styles by classes).

I probably miss something

Collapse
anthonywebdev profile image
Anthony R.

I am a big fan of tailwind. I would not use it in a "big project". But it's okay for me if you use it for an MVP or a small side project.

Collapse
jhechtf profile image
Jim Burbridge

I think it's interesting, and I'm aiming to use it going forward. I'm hoping that the tooling for VSCode has improved since last I fiddled with it (about a year ago).

Collapse
sm0ke profile image
Sm0ke

Impressive, got a lot of traction in the last few months.

Collapse
brianboyko profile image
Brian Boyko • Edited

Rick & Morty: "Well, that just sounds like inline styles with extra steps."

Collapse
anthonywebdev profile image
Forem Open with the Forem app