Tailwind CSS has taken the frontend development world by storm over the last few years. A utility-first library of CSS classes, it promises a new w...
The discussion has been locked. New comments can't be added.
Comments have gotten pretty spicy, and I don't think much valuable discussion is happening any more. See my comment for reiteration on some of the concerns raised.
For further actions, you may consider blocking this person and/or reporting abuse
Once again, if you don't like X technology, don't use it. But you don't need to look down on it. If you've created a library with a new paradigm, why not focusing more on the possitive side of it?
I literally opened the article praising Tailwind’s core ideas, and how it solves some real problems. But I also think it has some real issues that many people might not consider until they’re maintaining projects at scale with it. If Tailwind fits your use case then go for it, it’s a solid library by some clever people
Well said Madi. Thanks for the article, I'll certainly keep this on my reading list in case I do come up against your started issues.
Personally, so far, I love using Tailwind. I just find being able to do my CSS within my markup to be great for productivity, but doesn't feel like 'cheating' because I feel like I still have to understand all of the CSS that it's applying.
I also don't mind having to break out of the abstraction to do some custom CSS in specific cases - for me I don't particularly mind having a long list of utilities such as mt-3, border-2 etc - if it keeps that basic stuff from creating one or, perhaps multiple, large CSS files. It keeps what is in the custom CSS more focused.
Like I said, I haven't really felt like it's limited me so far, but I'll keep this post in mind if I ever feel like it does!
Because attacking the leading competitor is the easiest way to pitch something new. Conveniently enough, the author left out any any mention of cons & issues Pollen has over Tailwind. Or how it reintroduces decades old issues traditional CSS codebases have dealing with writing semantic CSS class names, organizing CSS, and handling specificity issues.
But yeah, this was a weird, if not cheap way to introduce Pollen.
Hey I really don’t know why you have this axe to grind. For a start nothing about using CSS variables implies needing semantic CSS class names, how you should organise CSS, or deal with specificity. There are so many solutions out there for all of those issues, and variables work in all of them. It is literally just CSS.
And as I have said maaany times, you absolutely don’t need to use Pollen, it isn’t some crazy new framework. It’s literally a collection of CSS variables. If you find it useful then awesome, but what I’m trying to get across is that the platform already has a solution to the value tailwind provides, and the style-by-classes abstraction introduces a lot of difficult problems that often don’t become apparent until you’re using it at scale.
Sorry you didn’t find it helpful.
You can't expect people to not elaborate on the important details you omitted.
Using CSS variables might not imply it, but moving away from a utility-first CSS paradigm like Tailwind's absolutely implies you now need to worry about that. Yes, there are many "solutions" to these issues, but they are far from a silver bullet that magically makes all problems go away. Writing semantic CSS class names will still be hard, CSS code duplication will still be a challenge, and you'll still need to come up with a strategy for avoiding CSS specificity issues. Not to mention you now have to factor in the decision making towards how you will solve each problem. And like you said before, a lot of this also doesn't become apparent "until you're using it at scale". And yet, you don't acknowledge any of this in your article.
Then perhaps don't write an article title and pitch that sounds like you're created this crazy new framework that solves all of Tailwind's issues?
Great. But you're not doing a very good job at this by omitting pros and cons from both sides. And no, praising Tailwind at the start of the article isn't quite what I mean. I know you had fair reasons to omit a lot of information and important considerations when choosing Pollen over Tailwind (since you clearly have experience with Tailwind) such as that a lot of things should be "obvious" to people that have used Tailwind. However, not everyone reading this has used Tailwind in the past. And all you end up doing is spreading missinformation for the sake of pitching your new library.
Tailwind fan boy right?
Nope, just someone who prefers conversations stay neutral and unbiased.
Though calling someone a fan boy just because you disagree with them instead of providing valid counter-arguments could be considered immature and I'd advice against it if I were you.
Sorry to say this Sergei, but your whole comment is biased towards tailwind.
I think the author is merely providing his opinion on a technology and proving an alternative approch to people new/existing to the CSS landscape and are looking for solutions.
If you disagree with the author's opinion then don't worry about it and keep doing what works for you and that is okay!
You literally went crazy about someone criticising tailwind. It's difficult to reason with people at that point, so fan boy would do.
So if the author conveniently omitted important key information from the comparison it's called "providing her opinion". But when I include the details she omitted, it's called "biased"? Something tells me people now throw around the term "biased" too lightly nowadays just to describe any time they dislike it's content.
The author provided his opinion in a biased way by omitting key information when it suited their pitch for a new library, I'm not sure how anyone here is missing it. And by omitting information, it does nothing but spread missinformation to people new/existing in the CSS landscape about Tailwind and it's alternatives.
I'm aware Tailwind is not a silver bullet either and it absolutely has it's downsides. However, for the comparison to be fair, it needs to include all valid pros and cons from both sides, not just the ones that suit the author writing it.
Madi only stated what everyone who uses Tailwind already knew. Also, the comparison was necessary as Pollen was "inspired by Tailwind".
It's LITERALLY the concept of Design Token.
Pollen has absolutely nothing to do with Tailwind. She's using Tailwind to get attention to her framework, nothing more.
Nothing can ever be improved if it's not okay to think critically.
If you don't like X article, don't read it. But you don't need to look down on it. If you've learned a library with a paradigm, why not focusing more on writing about the positive sides of it?
^such a narrow-minded approach to anything in life.
The metaphorical snake eating its own tail
How can you write something so compelling when I've put so much effort to get semi-comfortable with Tailwind?! 😉
It's often so long between the projects where I use Tailwind that I'm constantly on their docs (they are great by the way). But it's adding an extra step for me. I know how to do something in CSS but I'm using the docs to find what the utility class is for what I want to do. I've been most happy styling when I've used SASS modules. But it's no denying that regular CSS variables are greatly appreciated!
Thanks for the write-up! I'm gonna stare into the mirror for a bit and see if I'll just yeet a dependency where regular CSS makes more sense 🤔
Yo! Stop shitting all over the comment section folks. As some of you said, if you don't like it, don't use it. Stop taking place for a framework as if it was a person. IT'S A TOOL. And as it is with tools, new ones come out, new ones will be similar to old ones and some will be more or less effective. It's all about what you need to do. Just then you should think of how to do it. And in times like these where everything is overly complicated, there's no place to say no to something that's trying to make our life just a little better. If you think this post/framework is valid, great! If not, why even bother?
I myself love tailwind and won't stop doing so, because It does most things better than most if not any other framework I've used before (And I tried most already). I will consider Pollen too though. I love CSS variables since they came out, and if Pollen makes sense in that regard, there could be projects where it would make sense to use it. I love new tools. And you should too. 🤓 And Pollen and Tailwind kinda share the same principles and ideas anyways. Less is more.
Thank you 😌
I really didn’t mean to start a flame war. Tailwind is a solid framework written by some very smart people. I think it introduces some problems, especially at scale, but if it makes sense for someone’s use case then awesome!
I completely agree, I would say more: Tailwind never was a solution.
Using Sass modules properly gives you the same source of truth and theming capabilities without messing with the structure on a much more maintainable way.
For me, Tailwind is so absurd that you need to learn the entire CSS API in a wrong way that makes you able to work only with tailwind projects while learning the proper standard API from CSS and the capabilities of Sass leads you to a top tier front end dev.
The refactors when using tailwind due to re-designs are just hilarious and I bet it will die before it reaches the successful status as a tech. That and the bloatware in the structure are the main reasons for which it will probably die sooner than later. Imagine having to edit like 300 html elements changing some classes to another ones just to fit the new design. I'll leave in a blink 😆
For reference, currently there's only 1 job available on LinkedIn that mentions "Tailwind".
"much more maintainable" is debatable. Since CSS class name organization has been a staple issue for decades, something Tailwind does away with. Your HTML may be less messy, sure, but you are moving the organization problem to your CSS files where it can become an even worse nightmare.
Tailwind doesn't do away with reusable classes, they still allow them in the shape of components. And should you be building a SPA with React, Angular or Vue, you would simply change that component affected. If you need to update "300 elements" for even a small design change, you aren't using Tailwind correctly.
Then again, I don't blame you for thinking this. I had the same reaction as you the first time I learned about Tailwind CSS. And only after seeing it in action in a production project did I finally start to understand its benefits.
Along with a SPA library like React or a framework like Angular, Next or Vue I use CSS modules with a good architecture on it.
There's a theme.scss that exports the color-related stuff, a grid.scss that does the obvious and a global.scss that exports utilities and similar stuff. All the color-related stuff is declared inside theme (this allows for a quick reaction to design color changes) and what belongs to each component is inside the component directory as component.module.scss
it's just a matter of good architecture and experience. Of course if the devs are generating dummy classnames constantly it will be a mess but there's a nonsense on comparing the worse use cases as there's no tech to deal with that.
Of course you can shape reusable components in tailwind and tailwind at all can be fine till it's not, and the "till it's not" happen when there's a refactor needed due to a redesign, it increases the chances for something to go wrong with design context (the same component looking different depending on the page it's shown).
My opinion is on the main hand due to an analysis and POC did 2 months ago comparing tools for a changes proof code, long story short: custom implementation using Scss inside Next.
Also the team having experience on that is a keystone but also the tech community and similar projects that applies it. As I've said, 1 job available with the keyword "Tailwind", there's a dark future for it in my opinion; just good for people that hate CSS so they learn it the bad way, the same when you add chicken with the vegetables to a kid so he don't cry 😆
Bingo. A POC is often not enough to get a good enough idea of something. And like I said before, I don't blame you for feeling this way. It's absolutely a big change in terms of paradigm. And people, by nature, fear change (sometimes irrationally). Many things we take for granted today as "the best practice" took generations to receive widespread adoption. Only time will tell if this is another of those moments.
If anything, this is a terrible way to gauge a product's viability. All major libraries started this way. And if the State of CSS global survey teaches us anything, is that Tailwind is quite new, and yet is having exceedingly high adoption numbers thanks to it's record-high user satisfaction and interest to learn it. I guess we'll find out in the coming weeks once the State of CSS 2021 survey comes out to see how much Tailwind has grown in 2021.
It is a good article. It is sad some fan boy try to resolve their soul and ego problems here in the comment section. You should write more article and don't worry about these kind of people. Keep it up! Your photos are awesome btw :-)
Thank you so much!
Ah another week another "I don't like tailwind because" article. There are a few valid points but after about 18 months of using tailwind in several projects, I can say I'd find it pretty frustrating to go back to css or css-in-js again. Tailwind just makes styling fast and easy.
If anything, the verbosity of tailwind's class combinations works perfectly with view frameworks (React/Vue/Angular/etc) to abstract your styled elements into semantic components.
Anyway I'm not here to try and convince you to like tailwind. Some people love it, some people hate it. That's fine. Unless you're joining a new team where they use it extensively and you have to just suck it up and get on with, I suppose 😂
That’s totally fair! I won’t deny tailwind helps speed up prototyping etc, and it’s not so much “I don’t like because X”, it’s that after using it in my new team where we do use it extensively, there are a bunch of issues that a lot of people might not realise until they’re at scale. Like it’s not that tailwind is some horrible stupid framework, I spend the first chunk of the article praising its ideas. It just has limitations to be aware of, which I think have better solutions in CSS. But if it works for you then awesome, it’s a solid library.
And for everything that is coming for my throat saying I didn’t present a balanced argument, I mean, the article was already huge, and look at the hype around tailwind presenting it as the panacea for our problems and a new way to style things. Tailwinds own rhetoric certainly doesn’t mention any limitations 🤷🏻♀️
YES! This guy gets it
I just created an account here just to tell you how much I love this article. I agree with almost everything you said and I had most of these thoughts ever since I first tried tailwind. It blows my mind how every youtuber praises tailwind without mentioning the downsides.
Edit: I have nothing against tailwind. I just believe you should be aware of both good and bad sides of a framework/library/tool before you dive into a large project.
I’m so glad you found it helpful!
Because naming is literally one of the hardest problems in development? Why do you need a name in the first place?
Also, Tailwind still allows you to use your own names with
@apply.Does no one actually read the Tailwind docs before trying to shit on the framework?
Tailwind isn’t the only way not to name things. I use css-in-js myself and much prefer that way of doing things, but that’s neither here nor there.
And yes I’ve used tailwind extensively and read all their docs. I seem to have really upset you I’m sorry if the article came across the wrong way
Software engineering is full of narrow-minded people who can't stand a critique.
Thanks to the people that dare to critique the status quo is why we can advance, I personally always felt like Tailwind will become the next Bootstrap, it's popularity is incredible as allows people who don't know CSS to ship.
Nevertheless I have use it and I understand it works in some scenarios, but I also prefer to use a similar approach by using the incredible tooling, APIs and new specs that CSS has, thanks for the article @madeleineostoja
For all who thinks this is a way to sell in Pollen, read the article:
Full disclosure: I wrote Pollen. But I'm not trying to sell you on adopting it. I'm trying to sell you on the ideas behind it for your own work.
Good points and valid arguments in my point of view.
No, I think the post raised some valid points. Sure, it's good knowing such a popular tool as Tailwind because I encounter it in other projects. But for myself, it doesn't really speed up my development and SASS modules are a good way to manage my styles, making it easy to maintain over time.
Still, I like what Tailwind has done for me. I started using it at a time when I had terrible style structure. It was a horrible jungle in style.css. Tailwind was a gust of fresh air and made my styles a bit more maintainable in comparison.
There are some valid criticisms on Tailwind but for me at least it misses the true beauty of Tailwind, hyper-productivity.
I have been building web applications using CSS for over 20 years and I have used everything from hand-written bespoke CSS to every framework under the sun but Tailwind was an absolute game-changer for me. I immediatly had a huge gain in my productivity as making the classes utilities allowed me to quickly apply them without leaving the markup. I didn't have to jump from HTML to CSS then back again. Add a class and it just worked.
The classes are also predictable so when I learned the pattern I had an intuitve sense of what was possible. As I found gaps or areas that I wanted to customize I could easily extend them with my own classes.
This hyper-productivity also had the benefit of giving me more "courage" to expirement. I am much more comfortable trying things becuase I can apply a few classes and start getting a feel for how different styles might look.
Tailwind allows me to quickly build great looking applications with a fraction of the effort I've used with other tools and I did not need to learn any technologies that I wasn't already using.
Yeah that’s a totally valid use-case for tailwind, and if I was building a quick prototype that didn’t need to scale I’d probably use it myself.
I more wanted to point out some issues that I have come across at scale with it, because it’s often presented as a flawless new way to do things, which isn’t the case
I guess I disagree with the premise that Tailwind only makes sense for prototypes and can’t scale. I’ve built/maintain a number of projects with some using Tailwind and others using various SASS/CSS frameworks and the Tailwind projects are an order of magnitude easier to maintain.
That is what attracted me to Tailwind. I find it easy to build projects AND easy to maintain.
I’m not saying it’s going to work for everyone but it’s certainly NOT only for PoCs.
Not being into Tailwind is totally valid. Using CSS variables is totally valid. I like to use Tailwind using @apply while creating BEM classes. I find it extremely useful, fast and easy to read doing something like:
It's become more of a property generator for me if that makes sense. It's really the variants and extendability that shine along with the new JIT.
At that point why not just write css. I can probably consider the media queries part. But py-1, come on.
I don't solely use Tailwind to write
py-1but I think we can all agreepy-1is still faster to write thanpadding: 1rem Xrem... cOmE oNActually, it's more like
padding-top: 0.25rem;
padding-bottom: 0.25rem;
So I totally agree, I prefer py-1.
@regislutter Exactly, your example is more accurate. I also want to point out in the newest version you could do this
py-[30px]etc. which is very handy.You can also take what you need and leave what you don't. For example, I probably wouldn't ever write this if the design called for it
pt-1 pr-2 pb-3 pl-4 md:pt-2 ... lg:pt-3 ... xl:pt-4 ....just out of preference, especially if you have a lot of other styles going on in it. However, there are a variety different ways to handle you could handle that. You could just write your normal csspaddingshorthand and write them in respective media queries as necessary.You could use multiple
@applystatements organized by query (or whatever you want, variant, spacing, etc).Or you could put them in the
@screendirective:A lot of the common css frameworks/tools provide utility classes. I made pretty heavy use of Bootstrap's utility classes way before Tailwind was born. The examples I provided are just one of many things I like and use on a daily basis. It becomes a situation where you or your team would need to agree on the approach based on what works for you and define your house style. At the end of the day all of this could obviously be written by hand without tools and frameworks. These tools are meant to help improve your workflow and should be evaluated for your needs.
I don't see why
py-1is worth than the idea of the post, which is :--small-padding: 0.25rem;
padding-top: --small-padding;
padding-bottom: --small-padding;
I'm sad to see a lot of these comments. People seem so angry and offended. 😒
Yeah tbh this is gonna be my first and last article on Dev.to
Like I know this is a hot topic, and I mention another library (which I also say you prob don’t need, it’s literally a collection of variables), but damn. They be coming for my throat lol.
I too hope you write more articles. Promoting debate is good, the response you've got does contain some comments that show a surprising level of vitriol to something that you've clearly thought about deeply and inspired something you've given to the community for free. We don't have to agree with your conclusions to thank you for your work and your effort in creating this piece.
I'm so sorry for all the hate comments you get. I, for one, enjoyed your article as it was neither one of these "Tailwind is the best damn thing" articles nor a "Tailwind is total crap" article.
And as for what Tailwind can and cannot do: Everyone should just make up their own mind instead of coming for other peoples opinions.
I hope you'll write more articles!
I thought your post was very well written. I hope you continue writing here!
These angry developers feel like they have the one true answer, that their experiences and conclusions must make sense for everyone else. They act like they have ownership over the technology they use because they made the choice to use it, and that these choices represent them as people.
It's immature, disappointing, and in some cases results in cruel and compassionless responses.
You don't deserve this, at all.
These people need to step back and self reflect some.
The problem with inline CSS is you lose access to every pseudo element, pseudo selector, state, and media queries.
Personally I use CSS-in-JS so the class naming thing isn’t an issue, but even if you were writing regular CSS it seems like a pretty minor problem compared to the sort of things Tailwind introduces
That's patently untrue:
tailwindcss.com/docs/configuring-v...
tailwindcss.com/docs/just-in-time-...
tailwindcss.com/docs/just-in-time-...
It's almost like you've never used Tailwind.
I haven't used Tailwind, but enjoyed this article nonetheless. I'll keep its arguments in mind, and if I ever consider using Tailwind I'll evaluate said arguments based on their merits and drawbacks in relation to my specific use-case—as one part of several in a broader evaluation.
I also appreciate that the author based on an analysis of a perceived problem came up with an example solution (which is pretty much our collective job description). I think that's a commendable mindset, no matter what you think of the solution specifically. It's a shame that what could have been a quite fruitful mutual discussion has degraded to schoolyard antics, here in the comments.
Stuffing CSS variables into a tailwind config file seems to be a popular route, so cheers for implementing the principles of Tailwind with a CSS-first approach; not requiring config files and build tools to get there.
Before I clicked into Pollen’s docs I was looking for your take on Tailwind’s
@applybut realize now you don’t need to mention that since your point is about configuring utility classes through JavaScript vs configuring them through CSS.Great to have the alternative way to do things 👍
@madeleineostoja I beg you, let this not be your last article, hate comments just mean you had something really worth sharing. You wrote this perfectly well, this is basically the model for a good research work. Bringing light to both advantages and disadvantages, your findings, then you ended it with your solution. Come on, that's how it's to be done. The people who really deserve to criticize the shortcomings of something, are those that are able to produce a better way of going about it, and that's exaclty what you did.
Thanks for the great write up, and please keep it up.
I wonder why not just use something like "@apply font-bold py-2 px-4 rounded;" in your css file? It would be a lot less typing than Pollen. Class soup problem sold... if you want shorter lines just use another @apply line! The huge thing about Tailwind, is speed... test out multiple css styles with just hitting a few keys thanks to auto complete.
Because for all the benefit of saving a couple of keystrokes you're introducing a whole new DSL and preprocessor requirement, and by using
@applyyou're also ditching of the benefit of atomic stylesheets that Tailwind gives you, since it literally just copies and pastes those style rules into your CSSI'm wondering what the problem is with just good ol sass/scss, I'm sure there's some handler too that can convert your sass variables into browser variables or just write your variable as a modern variable.
I agree with another person's comment about how they are often going back to the documentation on these. I've been feeling the same with bootstrap lately, often it has great responsive helpers but then you run across the few things that don't, or it covers like 90% of flexbox cases and then falls short. I know you can modify their helpers but then like you said you bloat the system when you add something like a new size or color which then has to get pushed out to every helper for every permutation, and I doubt many people are thinking about that when all they are doing is wasting their time digging through documentation and stack overflow trying to solve their otherwise trivial problem, but I feel that many people fall into the trap and time sink of trying to be a purist that wants to do it all using their thick shiny tool.
I'll have to check out your lib next tone o get a chance.
Um, as other people haven't pointed out, you can use @apply to move your inline-styles-like classes into a custom class. What's more, the whole deal with tailwind is that you can customize your config file.
@apply works great with frameworks that implement scoped css block (Vue, Svelte). There is also windicss which expands tailwinds feature set, giving you pseudo-selectors, the ability to combine variants and lately the atrributify mode - using (most of the time) the first bit of tailwind css class as a HTML attribute to group classes.
I touched on it in another reply, but if you’re using @apply what benefit are you getting over regular CSS with a strong design system other than a few saved keystrokes? The price you pay — introducing a whole new DSL and preprocessor — seem steep to me for that. Like, you shouldn’t need a config file to write CSS. If you use the CSS variables we already have then you can “customise” your design system in a single css file, and do it dynamically with JS in the browser too if you want.
I haven’t heard of windicss, and it sounds cool. But again a lot of the things you mentioned are plugging feature gaps that shouldn’t exist in the first place. All of these issues go away if we just abandon the style-by-classes paradigm
"Like, you shouldn’t need a config file to write CSS. "
Weird, because you don't need a config file to use Tailwind. It works just fine along-side normal CSS.
Again, seems like you don't even understand what Tailwind is, you just want to advertise your "library".
Guy, take it easy. You're a tailwind fan boy. God...
I personally believe your point is actually pointless.. since you can come combine tailwind utility classes into a single class using the @layer component and @apply reducing the long class list in your Html all though I use it mostly with React so jsx.
Promote you work
Don't try to bring down others
Your "library" is nothing more than a couple of CSS variables, I don't see how learning the variable names introduced by pollen is different from learning tailwindcss "DSL" that is just a bunch of class names.
This is literally the point. You can get the core benefits of tailwind with just “a couple of CSS variables”. Using them, or your own, in any way you can use CSS, means you don’t have to reinvent CSS with the style-by-classes paradigm
I guess you have never worked with TailwindCSS. It's so much more that just variables.
divide-x/divide-yspace-x/space-ygrid grid-cols-1 md:grid-cols-2and you have a responsive 2 column grid layoutgroupto the parent andgroup-hover:text-red-500to the child - doneIn my eyes, TailwindCSS is even easier than writing regular CSS. Example: Grid. 2 Columns in TailwindCSS:
grid-cols-2/ Regular CSS:grid-template-columns: 1fr 1fr);And "saving a few keystrokes" - it saves A LOT of time to just write your html and do styling directly inside the class attribute, thank thinking of a class name, navigating to the css file and do it manually there.
No, the point is that you don't even understand Tailwind.
It's not just "some variables".
I don't really see how using CSS variables is better.
From your example :
You can do that in Tailwind with
@applylike :There is clearly no advantage to the variables.
Also, Tailwind is really useful to work with designers (and with Figma for example). They use a Tailwind template and you can clearly see the padding they want, you have the color and hue gradient applied, the text size, etc. You just have to type the Tailwind class corresponding.
BEM + Tailwind is for me really versatile. And if I need an extra responsive margin on an element just one time, I can do it in no time (exemple
class="button mt-2 md:ml-2 md:mt-0")[Edit] :
And totally forgot about useful classes like
divide-xdivide-yspace-xspace-ydark:ring-Design tokens are not a framework.
You created a "framework" of CSS vars. How is that a framework. It's just a set of variables, nothing more and the entire concept is called Design Tokens and has been around for YEARS.
Tailwind offers so much more than that and the fact that you didn't discuss that at all just shows your bias. And the fact that your wrote Pollen, so you have no interest in showing why it's worse than Tailwind anyways.
Wow okay lot to unpack here. Pollen is absolutely not a framework, that’s the whole point. The point of the article is that you don’t need a framework like Tailwind, and if you don’t want the ‘design tokens’ in pollen, based on tailwinds own tokens, then don’t use it, write your own bunch of variables to bring consistency to CSS in a way that doesn’t require a whole new styling paradigm with its own issues.
This isn’t a framework v framework thing, it’s a critique of some of tailwinds implementation choices, and an example of what can be done without them. I literally end the article saying you probably don’t need either of them 🤷🏻♀️
80/20 rule. With tailwind I have sensible defaults and sensible named classes which I can use in a modular way. Without having to write yet another css boilerplate.
Leaves a lot of time for the more custom stuff.
And try adding to a large project where an edit to class x can possibly bring complete mayhem to existing templates. Not so with single use utility classes.
And I love writing css and using css custom properties. Not having to write display:flex in dozens of components or have all kinds of variants of the same component with minor differences and having to name all of them..
It seems like author forgot that a large amount of Tailwind's community uses Tailwind for SPAs (React / Angular / Vue) where components can leverage JavaScript logic with Tailwind classes.
Even Tailwind's Docs recommend not needlessly creating classes and prefering writing components when an option.
And while the article has some great points, I can't help but feel this comes off as somewhat of a hot-take of Tailwind for the sake pitching yet another library that solves some problems while introducing old (traditional CSS project file and style organization, dealing with specificity) and a potential for new undiscovered ones.
I'm sure Pollen is a great library in some cases, but I'm not sure this was the right way to introduce it. Since it makes me wonder what pitfalls or issues Pollen might have that he/she is not mentioning just like with Tailwind.
Heya, I use CSS-in-JS in React myself, and have used tailwind in production at scale in that context, so not entirely sure where you’re coming from. The point you highlighted wasn’t about creating your own classes, it’s about what Tailwind has had to do itself to maintain its style-by-classes paradigm. By creating classes like .block etc that add no value whatsoever over normal css.
Re: “yet another styling library”, as I mentioned at the end of the post you don’t need to use Pollen, it just takes a lot of the helpful utilities from Tailwind and reimplements them in native, regular CSS. Absolutely nothing about it dictates the need for “traditional” style organisation or worse inheritance problems (again I use it in a css-in-js context). You can literally check out the source, it’s a few blocks of CSS variables.
If anything it’s proof that you don’t need a styling library, especially not one that dictates a whole new paradigm of styling like Tailwind
My bad, when I read in order to apply a consistent set of values with classes, it sounded a lot like you were describing the generic use case behind classes. I interpreted this incorrectly.
I kind of agree with this. But it's not like the opposite side of the spectrum isn't filled with issues. Writing semantic CSS classnames that carry "value and meaning" is an equally large minefield.
And yet, you pitched it with an article title ("Tailwind isn't the answer") that implies there's an objectively better solution to Tailwind CSS on the horizon (in the shape of Pollen). Don't get me wrong, I agree that there is some great value in Pollen for specific scenarios and uses cases. I'm just not sure pitching it by attacking Tailwind by omitting key pros/cons to make Pollen seem objectively better was the right approach, as it can lead to a lack of confidence.
Sorry if it came across that way, but the better solution to tailwind on the horizon is, just, using CSS. And CSS variables in particular.
Tailwind is excellent if you aren't comfortable with CSS because you're don't have to make it look pretty, everything already is pretty. What tailwind does is boost you to where you need to be for 90% of situations. If you can avoid the other 10% then you are golden.
The issue with tailwind is as soon as you get to that 90% mark, you hit that wall described where you can break the "spirit" of tailwind.
You can avoid this by writing your own classes that (where possible)
@applytailwind utilities for the big stuff that will be used all the time (buttons, form controls, etc.) as well as the tiny stuff (the pseudoselectors, the nth child, etc) that is used almost never. That way you spend most of your time doing what tailwind wants you to do, writing some classes in your HTML.As with all tools, you can use or abuse it.
Yes totally! Tailwind is excellent for quick prototypes, the problems come up at scale. I just feel for those kind of contexts it introduces more problems than it solves
I'm not saying Tailwind CSS is a magical solution to everything but all of your examples can be done "the Tailwind way" as well.
Tailwind has selectors for
:first-child,:last-child,:odd-childand:even-child. Those cover most of the use cases but in case you want a class only on the 7th-child, the easiest way is to just put the class on that element instead of using the pseudo-selector on the parent element. Or if you are using a front-end framework to dynamically add the elements, you can add the logic of adding the class to the 7th child in javascript.For siblings, usually you'd just add the classes to the element itself but you could also use the peer-* variants if you need to depend on a sibling element's state.
I'm not completely sure what you mean with this but if you only want a class to be applied to let's say the
md:breakpoint then you can just set the style back to the original onlg:. For examplebg-black md:bg-red-500 lg:bg-blackis red only if the window is 768 - 1024px wide.The whole idea in Tailwind is to apply the styles for each element itself so ideally you'd add the class to the child element. If that's not possible then you can create a selector for it yourself or use tailwindcss-children -plugin for example.
I using YouEye the last few years which comes with the benefit of Tailwind's productivity, but at the end it's just CSS. Tailwind is also a subset of CSS basically, well constructed/collected defaults let's say. I'm using it with shorhands so it basically achieves the same as TW's short classes, but at the end I have the full power of CSS at my fingertips, not just what the library offers. There is no extra DSL, no inheritance/encapsulation/naming problems. States, pseudo elements, Media Queries in an inline fashion.
Additionally this completely misses the point of tailwind and why its existence is necessary.
I would MUCH rather write inline styles (if it wasn't for the obvious draw backs and issues with specificity) and keep the markup close to the styles so when I look at the code I can tell exactly what it's meant to look like and behave like on the page.
Classes like 'button' or 'button-container' are literally meaningless and I have to go looking for the CSS definitions to find them. CSS-in-JS and Vue.js get closer to this, but still keep the information in a separate place.
And this knee-jerk reaction is monstrous blinkeredness due to the doctrine
herp, more words bad.It's a descriptive list of abstracted rules which are easily maintainable over semantic classes in place.
I have a lot time and use cases for CSS variables, I use them for ALL my in-house projects/design systems as a basis for my own stripped back utility class library.
But if you look at tailwind, it also relies heavily on css vars declared in root as a basis for it's extensions for size, color, etc.
So I'm not really sure what the point of this was. Like apples and oranges?
Hey guys, this has gotten a lot spicier than I anticipated, so I'm going to go ahead and lock comments on it.
A few things to reiterate before I do:
Tailwind is a solid library written by smart people, with great ideas behind it. I think the way these ideas are implemented introduces serious problems at scale, which often go unmentioned. If those problems aren't deal breakers for you, then by all means use Tailwind!
The other library I talked about, Pollen, is just a collection of CSS variables. It shows how Tailwind's key benefits can be accomplished using the tools we already have in the platform. I hoped that some people might find it useful, I know I have. But as I mentioned in the article, you absolutely don't need to use it, and I'm not trying to sell you on switching to it.
Apologies to anyone this article offended. That wasn't the intention
— madi
I agreed with some of the criticisms of Tailwind (though I wrote my own library/framework, Passionfruit, for a similar purpose and in a similar manner, long before I knew anything about Tailwind (probably before it existed, but I haven't checked)).
However, I wasn't expecting this to be a run-in to advertise another library. I feel like this should've been stated clearly from the beginning. Just feels dishonest, imo.
The integrity of this post is hilarious - you're bashing on a CSS framework you obviously don't know enough about, just to promote your own CSS framework 🤦♂️
She isn't bashing on anything, she literally points out the good qualities of Tailwind right in the beginning.
" The Tailwind alternative that doesn't reinvent CSS " , that sounds offensive, somehow i feel you wrote this article out of hate against tailwind :)
Cool...
Nice. I've been planning to do this with SCSS variables which hold CSS variables, that way less to type, but still easier to do theming, switch from light to dark, or comfortable to compact, etc.
This article tries to figure out some evidence to justify author's point of views. The logical way of thinking is to do it in the opposite way.
Well to be honest i disagree with that. But I guess in the end user's experience matters.
Btw your menu drawer on pollen.style is not working on mobile. Maybe fix it by using tailwind.
It’s just a site on gitbook, but hope that was fun to point out
I agree 100%, tailwind is reinventing css in a bad way. It's inline css under some shorter names and in class instead of style -_-
My friend, I sense you miss one big point in here.
The reason why people used Bootstrap and now Tailwind CSS is not consistency, but rather getting away from the hell of CSS.
Pollen isn't the answer
My sass, wickedtemplates.com is based on Tailwind CSS, we develop templates with it, and people loves it,..just like I do.
he ahua whakahirahira mai i to taha.....
Tailwind is the was to go. If you haven't used I suggest you try it out. Way better than writing your own css. With the JIT, Dark mode and autoprefixer you won't need to stress about compatibility
Its better to use Twin Macro!
I think Tailwind is meant to solve and simplify common styling issues.
But as all the technologies, has points of strength and weakness, that we as developers we have to deal with.
Tailwind is the answer to huge projects, read the customizing section in it's documentation it will solve many of your problems.