Responding To The Tailwind Conspiracy

DO NOT HARASS THE AUTHOR.
As soon as I saw the title of this blog post, I knew I had to read it live. I regret doing that.
Debated not posting this because it's so negative, but the author has INSISTED I read it and continues to spam it everywhere, so this is my response.
keywords TAILWIND CSS SEMANTIC CSS HTML BEM STYLE SHEETS
Blog post: nuejs.org/blog/tailwind-misin...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏

[@JonathanRose24]

Now that’s a rare insult “this guy still uses double equals” 😂

[@marvnch]

lmfaooooo

[@MrSofazocker]

I feel called out. I know in Python we now use "is" but is the Top-G move in typescript really just ===?

[@theseangle]

​@@MrSofazockerin JavaScript in general, yeah. == Was largely a mistake. Upd: people saying "use [either operator] for checking undefined or null to check for false". No, just use logical NOT operator: `if (!value)` If you write these: `if (value === undefined || value === null)` or `if (value == null)` or `if (value == 0)` to just check for falsy value then you're either a beginner or straight up dиmb. There should not ever be situations where you're required to write such code. I was trying to come up with such a situation for a good 5 minutes and every time there were better, more strict and reliable solutions. --- There's literally no reason to use == at all. I have been working as a webdev for 5 years and never EVER saw `==` in any working developer's production code I kid you not. Also, don't use toString(), don't use parseInt(). Other people suggested that you have to use those methods if you use ===. That's a lie. Default to using concatenation (or string interpolation) and the operator sign `+` instead of those functions. They will bring more harm than good if you don't know how to use them properly. I can write 10 times more text for arguments on why using == in new code is a bad practice but I don't have that much time. Instead, you can just read a few articles on that topic. ESLint shouts warnings when you use == and they highlight why in their docs. --- People saying "not really, == has reasons to exist" that's a lie, they just want to sound smart. == has a single reason to exist: backwards compatibility. That's all. It's an archaic feature of JavaScript and a remnant of the past. In new code, you never have a reason to use it. And if you think you have, then learn more, there is always a better alternative. --- To answer one guy below that said that === was added because checking for a falsy value was verbose. Checking for a falsy value was never verbose: `if(!value)`.

[@MrSofazocker]

@@theseangle so... as always the fix in javascript is inventing something new that does the samething a little bit different?

[@pokefreak2112]

​@@theseangleNot really, they both have their strengths and weaknesses. === needed to be added because checking for a specific falsey value used to be extremely verbose, but in most cases you don't care if your variable is null or false or undefined. Bad teachers suggest people to just spam === but if you actually wanna get good you should learn the semantics of == and pick the appropriate operator to use carefully

[@Jojor11]

This article made me finally try tailwind myself instead of being in a “I should look into what it does and how at some point”… it just felt so weird and it made me think “yeah, semantic css doesn’t just work, I always have problems knowing what each thing do and having to replicate all classes with small differences”… and that’s how an anti tailwind article got me to use tailwind both at home and work😂

[@t3dotgg]

Funny enough this is kind of how I got into it as well

[@Dreamvention]

me too ))

[@ericka.montanez6821]

Maybe that's the intention of the author, get people thinking that his post doesn't make sense, and push people into Tailwind.

[@Fearthelettuce]

"As soon as you recognize that components are the abstraction for reusability and CSS just kinda gets in the way, Tailwind makes infinitely more sense." OMG, it just clicked for me! Can you put that on a shirt?

[@ummnine6938]

excellent idea for a tshirt!!

[@ohhellothere17]

Yea lol, makes sense since custom reusable components and tailwind are abstractions for barebones html and css, literally made for each other 👍

[@Dominik-K]

Would love to have this as a shirt too

[@jonhobbssmith]

But you can still use proper CSS in components. in fact, that's what everybody did before Tailwind. You don't need it in a separate file and it's far more readable. Tailwind just turns your markup into a horrible unnecessary mess.

[@ohhellothere17]

@@jonhobbssmith you can and yea that's how it was and still is if tailwind isn't used, but the fact that you don't need to switch between files/screens and giving arbitrary class names was a big win for me, but I agree on the part where it makes the html look ugly af

[@CurlyCow]

I definitely think one should reach for Tailwind for most/many things, but telling newbies it's ok to skip learning CSS and go straight to Tailwind is almost the same level of bad as telling newbies it's ok to skip learning JavaScript and go straight for React.

[@jacoblockwood4034]

I agree with this, but maybe it's OK to tell newbies that it's ok to skip learning specificity and selectors? At least the basics of course but I feel like it's probably not that important.

[@Atriace]

Mixing language syntaxes is ugly. In my humble opinion: - CSS shouldn't be in JS. - JS shouldn't be in HTML. - HTML shouldn't be in JS. - CSS shouldn't be in HTML. The author wasn't entirely wrong in their position; they were speaking from their own perspective. Tailwind is ugly, and it also addresses your desires, which makes it the right choice for *you*. You've got a lot of vitriol for someone who was quite passionate about their frustrations in their programming; if anything this video convinced me that you (Theo) are not someone I would want to work with.

[@wlockuz4467]

30:15 Oh my god. All that build up and he just ends up describing why Tailwind exists. The self-awareness of this article is non-existent. "You start with a pure semantic layout and figure out reusable pieces of CSS" First this approach is impractical when working professionally because you just don't have time and resources. Second, this is literally what Tailwind does, it has figured out a sane way to make CSS reusable without getting lost into specificity and naming hell. God forbid BEM and OOCSS and other conventions. "At times, especially when building new components, you might want to prototype quickly with inline styling" Again this is barely feasible. Good luck prototyping with inline styling then migrating to CSS, worse yet having to go back and change these because you changed something elsewhere and its affecting your previous classes because of cascading. "But that's okay and part of the system" That's just an excuse. You need a very good argument as to why such a big bottleneck should be a part of the system if there are no clear benefits. "You can clean things up later" Again, like already mentioned in the video this is a pipe dream. But this is where Tailwind shines the best imo. You can prototype something quickly and leave it in there without having to worry about "cleaning" it up. Example, If you have a "flex flex-col" in your prototype you can be guaranteed that it will stay that way regardless what other things change.

[@osman3404]

But even his point of prototyping with inline styles misses the point that Tailwind is the BEST "inline style" system we have LooL Not only does TW allows the rapid prototyping powers of inline styles, but its also more reusable, maintainable and shippable WHILE also provides features that inline styles do not have like variants, breakpoints etc... I hope he used AI to generate that article to troll us because its so crazy

[@ChristophFloat]

"You can clean things up later." My man clearly never worked in any kind of... well, job.

[@rand0mtv660]

Yeah "later" in programming world usually translates to "never".

[@ChristophFloat]

@@rand0mtv660 "If it's ugly, but it works, it's n… actually still ugly, but we don't waste time and resources for code aesthetics, and this 'maintainability', you're speaking of? Yeah, I've decided to wait until it becomes a problem. If you write a non-functional ticket, I'll put it in our backlog though. Not for next sprint though. Or the one after. We've got important features to implement." - Way too many POs around the world.

[@rand0mtv660]

@@ChristophFloat lol so true. Backlog just becomes a dumping ground for tickets like that.

[@real23lions]

no matter what industry you're in, no one will remember to do the clean up. 😂

[@runejensen3978]

This is because you and Theo are looking at it wrongly. The post says clearly states: "you might want to prototype quickly with inline styling". The emphasis here is "inline styling", using the "style" attribute, which is not the same as "styling by class" using the class attribute(className for JSX). Most of the time/if not always, you never style inline(as an end goal), hence its good for debugging and thrashable when you classes are in place. Its a blunder by Theo to overlook this.

[@austinstewart1451]

When you brought up the horror of manually handling selectors near the end, it brought back flashbacks of older projects before the company I work at adopted React. Static sites aside, working with reactive web applications used to be a nightmare with plain HTML, CSS, and JS. When you have a button that needs to do something, it needs to be selected. Can give it an ID. Now you need that button in multiple places, either duplicate the code per button or use a data attribute selector. Oh, wait, the button doesn't exist on page load because it only exists after another button is clicked... Now you have to programmatically add the functionally and remember to clean up if the element is removed. One possible way to handle it was to place the event on a container so then we didn't have to worry about dynamic elements... uh oh, we need to move it and now it's no longer in that container. If you don't know that's how it works, there's no type-safety so the element(s) can be (re)moved and you wouldn't see an issue until runtime. Like you said, things "can" be done without tools like tailwind, typescript, etc. When I first started, I stayed away from libraries to make everything as small and "clean" as possible. But, that was for me working alone on basic projects. As time went on, again, you hit the nail on the head, I came to love how these tools raise the base bar to make codebases so much more maintainable and use them even in personal project now. Final thought going back to the actual styling topic and clutter: manually writing CSS means you create and maintain the source CSS. Our handy dandy Tailwind compiler removes any classes we stop using automatically so we should get at least one point 🙂

[@TheTigero]

The fact that you jumped from “give it an id” to “we need another, use a data attribute selector” is bizarre. And then you claim that if the element doesn’t exist on load you have to manually add it? Seriously what the heck are you talking about? You’ve painted yourself into a corner and are raving about how nice the drywall in the corner is.

[@andreilucasgoncalves1416]

Programming vanilla nowadays is different than it was in old days, you have webcomponents and things like querySelector by css classes or .closest() to get state of a top level component I still prefer to use vanilla for SSR pages with esbuild to bundle For pages with tons of forms and states SPA with React or other framework is better In my opinion struggling with modern vanilla is a skill issue In the webcomponents part the only thing that matters is connectedCallback and disconnected, everything else is bad for most use cases

[@austinstewart1451]

@@TheTigero I'm not saying anything is complex - it's not hard to write the necessary code - but was only trying to note how the frameworks help alleviate some of the pains of modifications to a codebase. If you have a button that opens a modal, you have to have a way to select it with JS. I then note the client requests that button be available in two places - now you need to use two distinct IDs or swap to something reusable like a data attribute. Again, nothing complicated but there's no check constraints to ensure a new dev doesn't accidently break functionality compared to React with TypeScript ensuring at least certain constraints are followed. Same thing with web components - you can do a lot with them but the safety net isn't there without other tools.

[@austinstewart1451]

Also, I apologize - should have clarified my thoughts are around large codebases and the example was overly simplified to not make it too long, despite still being long haha. Again, nothing wrong with vanilla and I definitely don't want anyone thinking these tools are the only way. I believe everyone should still learn HTML, CSS and JS since that's what gets compiled at the end of the day. To clarify a little more on the selectors, it "can" (not always, but I've seen it and had to fix it more times than I'd like) cause issues as projects grow since everything needs to be unique and constructed well. Working on an old MVC app, you might have a page that is constructed from numerous partials. And, those partials are asynchronously rendered so, until you render it, you might not find that someone accidently used the same selector as someone else on the original page (if using ID, it would likely select the first instance and therefore add a second event to the original element and nothing to the second). Web components again can help but adds their own complexity. Not expecting everyone to agree but hopefully that makes some more sense and sorry again for making it overly simplified/general.

[@andreilucasgoncalves1416]

​@@austinstewart1451 I agree with you, it must be terrible to work in that old codebase And partials is not like React Server Components? Well probably Server Components must be a "modern" version of partials

[@lukeinderwick5951]

I'll admit I thought tailwind was stupid and mocked it's syntax even after watching lots of Theo videos on it. I was dumb. I finally used it in a project and I'm completely converted. The speed at which I was able to develop that project whilst having maintainable code was just insane, plus the perks of copilot better understanding what styles I wanted based on my JSX. It's so true that you write crap CSS when prototyping for speed and then NEVER clean it up. But with tailwind you can prototype fast and the code you write is often far cleaner the first time round. Thanks Theo!

[@neociber24]

That article was made with really bad faith with those cherrypicked examples lol Tailwind is good for 95% of the cases, when I want weird shit I use CSS, I don't need custom css for adding some padding, margin, border and colors

[@MrManafon]

yep, the beauty that people often miss is that Tw is super open to using whatever else you’d like. I use it for 95% of stuff, and then use styled components or scss where that is a more appropriate choice

[@ea_naseer]

hi.... I see you everywhere...

[@huge_letters]

Yup, that's why I love tw with Vue/Svelte - use tw for 95% cases, use scoped style blocks for the rest

[@xphstos_]

Thank you! That’s the issue that not all tailwind evangelists get. Most of them probably work on products that have to build dashboards, lists and tables. I work with a brand design agency that each site it’s super unique full of gimmicks and very… very unique styles like filter blurs, transforms, animations, layouts that goes over and under your normal columns etc. Tailwind is a pain in the ass for sites like these and only make my code harder to read and maintain.

[@kaanatakan]

​@@xphstos_It really isn't. Tailwind offers a range of filter and transform classes that fit most needs but you can always break out of the presets with the bracket notation if you need to (eg: blur-[1.23em] or translate-x-[123.4%]). Or you can redefine the presets using the config file. Animations can't be inlined. You will need to modify the tailwind configuration but in the end its really basically the same as adding it to a CSS file. There is literally nothing you can do with vanilla CSS that you can not with tailwind just if not much more easily. Why would there be? Also just because someone works with tables that doesn't mean they don't deal with complex layouts with fixed and sticky elements, z-index issues, animation etc...

[@diobrandoggo7471]

Theo gon from 0 tilts to 100 tilts in 25 mins lolol.

[@akam9919]

More like 115.69 tilts.

[@userx2usery224]

Yeah )) Never seen him like this - wounded to the heart and in righteous anger =) And what is Theo Rant in comparison with this now? ha-ha. His logic is unbeatable here and emotions are... just awesome!

[@voidash]

I don't know how i feel about the blog post but i couldn't agree more with Theo's Components are the best thing that ever happened argument. For me, when working in a team setting, the advantages of components are - Naming things has become easier with components. - When working with design team, the changes designer has to make aren't in jsx file but in css file pertaining to that component. (most of the time). It helps when working on git... But you don't need tailwind for component based system, even though tailwind really shines in such scenario. I tend to avoid tailwind for a big project that i think of selling or maintaining in future because - when finding the next person to manage the code, it becomes a bit easier when the requirement is CSS and not tailwind. Think of it like finding bootstrap developer when everything is tailwind. - No installation of some specific plugins, LSPs, or maintaining config file. Additional set of tooling like hot-reloading, minification for the sake of some boost in throughput shows that the tradeoff is quite disbalancing. - There is bound to be a better solution than tailwind in the future, but the CSS will remain CSS. Well consistency is a issue but a sane and well thought out design system, with emphasis on defining core set of styles like fonts, color, margin before hand with foundational components like button, checkbox, input boxes predefined etc can be on par with tailwind consistency. But again i find myself using tailwind when working formy projects - composability with different and easy way to think about the css - GPT is better at tailwind than CSS - If developer productivity comes in form of installing few plugins, starting some LSP server, some tools in pipeline then it is not a problem when i am the only one to decide what happens in a project. At the end Simpler tools become more popular, but they come at a cost. Tailwind one day will become like Bootstrap. A stable station where the hype train has already left and it is parked at framework that has some shiny new way to do CSS

[@osman3404]

The funny thing is that the parts of bootstraps I liked the most were its utility classes loool The concept of Utility-first that tailwind is built on is very powerful and the tailwind compiler we only get more powerful to illuminate the need of config files, plugins and the pain points you talked about

[@andreilucasgoncalves1416]

GPT being better with tailwind is a bigger seller point

[@franzgm]

Use vanilla CSS, you'll be sleeping comfortably.

[@PhilipAlexanderHassialis]

The fact there is much digital ink spilled over a flippin' CSS framework is all the motivation for someone NOT to work as a frontend engineer. Like, what the actual hell? It's a CSS framework. At the end of the day, it abstracts or codifies the standardized CSS primitives that are the same for every browser (well, at least a good portion of them). If you don't like said framework, use another. Build your own. What's the fuss? God, some people have too much time on their hands.

[@azizsafudin]

Haters gonna hate you onow

[@niceowl]

He did build his own framework :)

[@guseynismayylov1945]

because it affects people and their work environment, I want to get things done and don't listen about introducing new css lib next month.

[@kevinb1594]

I would say the problem is the similar for people relying on React and jQuery and not actually knowing how to Javascript. New dev show up to your team not knowing how to actually write CSS or how the cascade, selectors or specificity work and when they get stuck on your 4 year old legacy project, they can't contribute effectively or the other way, when Tailwind stops being this weeks hot new thing or the developers decide to do things differently or deprecate things, you're stuck not actually knowing how to style. I thought we decided inline styling was bad a long time ago and coupling more of the webs reliance Javascript seems like a bad idea.

[@bluecup25]

THE TAILWIND PROPAGANDA MACHINE

[@drisvalakasvrykolakas4248]

Honestly, I've used both and this time I do not even care I know the truth and will not stop using Tailwind, period.

[@erickheredia8910]

I can't go back to plain css after 4 years using tailwind daily.

[@mintcar]

It seems Tailwind is really beloved by a lot of devs, and I'm sure I'll be forced into it eventually, but when we tried it it in my team it didn't stick. I find that components make utility classes unnecessary for CSS reuse purpuses just as much as they make reusable semantic classes unnecessary. You get the same bennefits of deleting CSS when you delete code by just colocating your CSS file with your component. The lines of CSS that are not being reused in the component is roughly the same as the amount of class names I would have to write in the markup using Tailwind. Utility classes are better used as a means of altering a component's behaviour from the outside as a one off. I agree that the article is in bad faith, but I really which CSS was not something devs tried so hard to avoid.

[@MrX8503]

Try CVA. It cleans up your class names and dictates your component API at the same time.

[@DavidDeCorso]

@@pcap8810 getting in the way of what?

[@redakcjaTheBased]

is antipattern in REact but somehow Tailwind is not

[@daviidon]

I'm in the middle...I like components but hate how noisy tailwind makes my markup. The way imba does styles is the perfect balance.

[@tasmto]

Studying the MDN docs feels like such gate keep vibes. Just build stuff, learn based on problems you encounter while building stuff, its fine!

[@unowenwasholo]

I was all against css in my html (well, react, but w/e). Then through watching Theo and using T3 I decided to give it a shot. The funny thing is, I realized at some point that I was making Tailwind in the first app I made before actually looking into Tailwind. Before that, I was using mixins for consistency. Most things point to Tailwind.

[@Trekiros]

I'm curious what you think of CSS modules, since those seem to solve many of the same problems you seem to have with vanilla CSS of having to come up with names which don't clash. Most of my projects only have about 100-200 lines of global-scoped css, and the rest is on a per-component basis already. I've pretty much never had to worry about maintainability or conflicts.

[@DeepTitanic]

The problem with CSS modules is that it doesn't make the maintainers of Tailwind any money so influencers have no reason to push it

[@shinodinhaa]

Tailwind still be a utility framework in this case, which works as a replacement. But making the bootstrap, prototyping, and development in general faster due to not having the necessity of creating new files, switching contexts, managing files, and creating complexity in general after the tool is in place.

[@rand0mtv660]

I've used CSS Modules for last few years and have switched to Tailwind in the last 6 months or so and will just stick to Tailwind going forward. Yeah CSS Modules are really great, but still come with their tradeoffs as everything else (TW included). There can be styling ordering issues if you want to pass className from parent to child to adjust one property. I don't want to always add another prop to a component just to adjust one thing in one scenario. In that case, depending on actual module load order, things might not load same in dev and production and you might end up with styles that worked locally, but not in production just because things load in different order. So you have to increase your class specificity to apply styles to make sure they work. It's hard to debug and notice sometimes because it can break with changes unrelated to styling itself. But ok, that's an edge case and you should most likely encapsulate everything in a component, but it's just such a burden sometimes. I also disliked CSS Modules when I just needed few quick styles like flex or padding/margin on some wrapper element. I have to create a new file, create a class for it and add those to it. Yes I could have those basics as utility classes, but I also have to make responsive variants for them which can easily explode CSS file size in the end. And when you do create all of that, you basically created a framework that you just know and anyone being onboarded to a project will have to learn it and it will have to be maintained in the end. I also work in an agency, I don't want to always copy-paste that from project to project or re-create it from scratch each time. Of course I don't think Tailwind is perfect for every scenario, but it works nicely for me 95% of the time. That 5% of the time it makes things harder (like before/after pseudo styles that might require a lot of rules) I can live with. I'd also prefer TW working in a team because it's easier to learn something that has so much documentation compared to some homebrew solution like I mentioned above.

[@andreilucasgoncalves1416]

CSS modules are fine, Theo prefers things in the same file so he will very much prefer TW Another thing is you can use TW in other languages like GO while CSS modules are JavaScript dependent

[@socialkruption]

Vanilla CSS bros, are we enjoying this drama? I know I am >:->

[@dennisaarts7924]

Love these videos and love the discussion. I noticed that a lot of times the discussion is about if the tool/language fits your needs, project, way of working. And sometimes it is based on data. In this case its a bit of both. Props for telling your community not to harass the author for having his opinion. Real class there.

[@jokinglimitreached1503]

Aw man, Theo... 24:24 Those statements will age like milk, believe it. This is too painful to watch

[@TravisHi_YT]

There's no saving TWCSS zealots man. You can tell when he says separating CSS from the HTML is silly, when TWCSS is literally just someone else's convoluted take on semantic CSS.

[@JT-mr3db]

This article reminds me of how I felt about Tailwindcss before I actually tried it. The minute I did, I calmly gathered my belongings, walked to the Stern of the non-tailwind ship, and jumped off.

[@tom.watkins]

The @apply argument you made is bang on, since using tailwind the only time I've had to use @apply or even touch an actual CSS file is for when I can't directly control the markup, a particular example of this is styling Clerk components (I know they have a theming option but it didn't quite cover everything)

[@azrielsatan8693]

Tailwinds users bloating every page with 5MB of classes instead of just writing clean HTML and actually learning CSS.

[@Daktyl198]

I gave tailwind a serious shot, and I just don't like it. It just feels like a different way of writing inline styles, and I feel like I'm writing far more code than I would be otherwise. If you want all elements to look a certain way, you don't need to copy/paste 15 classes between each with semantic naming, you don't even need to give them a name. You just need to use a selector for that element. The number of times you have to have custom styling for an element in modern JS frameworks that isn't just like 5 lines inside of a component's tag is extremely small. Tailwind makes debugging small to medium sized projects far worse than semantic naming, at least in my experience with it. Anybody that struggles with semantic naming is probably writing too many lines of CSS to achieve the same result. TL;DR they don't want to learn how actual CSS works, so they use something like Tailwind.

[@AllanSavolainen]

Hmm, if multicursor editing is a recommended thing, let me give you even better way. Click on the class="foo", editor opens .foo and you can edit it directly. Or if you need a new special class, just duplicate and rename and use that, or add that semantic extra class, like "active" or something like that. Or if you need to know where it is used, just click on the class name and select show usage and get a list of places it is being used in. And it is super simple to clean classes from css that aren't being used. And the best thing, no need to compile css, ever.

[@josefaguilar2955]

My last company had a design system like tailwind before tailwind gained popularity. It was nice to have a consistent compostable style set to use but we ended moving away from that towards specifying all related css in a file right next to the component. It becomes less magical and you have to figure stuff out yourself for sure, but then you aren't trying to debug another style libraries code but rather the specific targeted css code you are working with. After using both, I like the separate css module approach the best but it does have a higher learning curve that might not work for all teams.

[@andrueanderson8637]

13:36 - "... [this is] much easier to fix, much easier to maintain ..." - yea I'm gonna hard disagree with you there. I know it's trendy to hate DRY but deduplicating things that are semantically equivalent such as the links in this clip is infinitely easier to fix and maintain because you don't have to do the fixes/maintenance multiple times (each with the possibility of subtly introducing a bug). Granted, if you've misunderstood the context of the advice to _not repeat yourself_ and you've taken it at face value as "don't type the same string of characters more than once" then yes, it probably did make your code harder to fix and maintain.

[@kabukitheater9046]

sounds like a hitpiece for people to talk about their framework

[@jacoblockwood4034]

This is infuriating and hilarious at the same time

[@codeOfPatrick]

Semantic HTML is for the consumer of the HTML the USER not for the developer ???

[@theseangle]

Good point

[@Peptou]

Not sure I follow what you mean when you say that you have no guarantees on how a element works.

[@Vlada97my]

As a front end dev,who got started doing web design about 2 years ago and fell in love with that, i got started with react while next js still wasn't a thing that too many people used and people were still only building client side apps (SPA).I found out about tailwind totally at random and saw some videos about it,and first i was like okay this looks confusing. I didnt mind the inline styles at that time i just wanted something to help me do web design better and easyer. So i tried it and never looked back and i dont regret it. Even after 2 years of trying other stuff,like other front end frameworks i always look at it as okay but can i integrate tailwind to it? Thats how much i love Tailwind CSS. I just built a website with Next,tailwind and flowbite which is built on top of tailwind, in 2 mounths and its crazzy how fast and productive it makes me 💙.

[@luboshemala3485]

Thanks Theo, this really opened my eyes a little. I was also raised in an era before css frameworks, so separation of concerns and clean classes were kind of a big deal. I was always struggling with development velocity and now I can guess why. I wanted to have "nice" dry css, at the cost of having things much more complex than they could be. I like the SwiftUI example even more, it looks like combining inline css properties with semantic values. I think it comes a little bit from university background, there was a push to optimize the shit out of things, not really telling you what the cost is in dev time, especially in teams, since they were none or small.

[@ej3281]

"DRY was not the right way to think about your code"? You said that pretty casually for such a hot take

[@PureGlide]

Another key details is you you can mix it up, I often specify a few very common items such as buttons in a typical class (with @apply to tailwind classes), so I don't have to specify every single button. But keep it minimal, and put anything unique to individual items on the actual element. Side note: use "prose" class if you're not already :)

[@medbenbrahim3246]

Tailwind is more useful via components/partials, so you DRY. But would have been great if Theo challenged the long button case from Catalyst components. One button with ~2kilobyte in its class, reusing the button component just 7 times in a page, and you have more than ~14kb of duplication. Tailwind is good, but it still has some unsolved questions

[@keithjohnson6510]

That is certainly a good point, yes, your code is DRY, but the DOM is not. Saying that modern web browsers have some very clever optimisations, if not already done, one idea is that the browser could maybe auto de-dupe, so a massive 2kb classname, just becomes a pointer. And even if the browser didn't do it, a compile transform certainly could, I would think this would be nicer than using @apply.

[@lorcaranr]

The dialog example also demonstrates how you can make effective changes to your code base in a controlled manner. If you applied default styles to the native element there are no constraints on who might use it. Where the component equivalent is specifically used because you control it. You are opting in to that component when you use it.

[@kevinb1594]

This is only true if you have a global selector. .Foo > dialogue {...}

[@Vrishnaakh]

This guy doesn’t know how to make rounded background inside a div without using overflow. And then he acts as if he is the arbitrator of absolute knowledge.

[@LeonBlade]

What do you mean by this?

[@asdougl]

One of the best parts of tailwind is that it is essentially a standard, if I jump to another project that also uses tailwind I can pick up the styling super quick

[@_nononono_]

It's not a standard, it's just popular

[@jameslouizbuilds]

@@_nononono_it’s not literally an official standard no but it’s popular enough and well documented enough that you could treat it as such.

[@AustinCameron]

lol it's just an abbreviation of a standard. Majority of us have already memorized the standard.

[@docmars]

This is a great point -- it's similar to how Bootstrap was (and maybe still is) very universal for a lot of places and projects. Tailwind took a lot of great things from Bootstrap (inadvertently, Bootstrap has many utilities like Tailwind's) and turned it into a more barebones, customizable way to approach UI building for two use cases: 1) brands that need high customization and speedy development, or 2) a good baseline for styling that isn't too opinionated, like Bootstrap was. On that last point, you could easily point out the sites that were using Bootstrap because it has "a look", whereas Tailwind really gives you enough general defaults you can mix and match to get you a unique look, and that's why people love it. It's built for headless UIs, whereas Bootstrap locked you into their CSS override hell.

[@gearboxworks]

As someone who has not done any front-end dev in about 4 years, that comment was very insightful. Thank you.

[@MichaelLazarski]

my kind of problems with tailwind: a) I dont like vertical long text which if you looking for something specific its hard to parse b) you need prettier and eslint for sorting and so on c) you need another lsp running Are these deal breakers for me? no but it added another cfg file and another tool to the frontend stack which i find is a problem but that has nothing to do with tailwind and is a completely different topic.

[@eldarshamukhamedov4521]

As opposed to what people used to use (SASS/SCSS processors and editor plugins, CSS module plugins, CSS linters and bundlers, etc.)?

[@LeonBlade]

@@eldarshamukhamedov4521 This is such an important thing to consider. I remember having an older project that used Gulp to process SCSS into a singular CSS file. All of that requires multiple packages as part of getting your CSS output. I haven't touched SCSS in a long time, so I don't know what sort of build systems people are using, but I do know that tailwind is way easier.

[@mathiasfischler4227]

that was helpful, thanks! Learned more about the why of tailwind than in hours of searching and arguing!

[@mikaay4269]

I agree with the points but I find the statistic of your chat a bit off. If you ask a channel's viewership that mostly talks about react/nextjs stuff, most of them will answer with yes, because most component libraries are made for react.

[@LeonBlade]

True, but most developers are also using React.

[@mikaay4269]

@@LeonBlade yea react is probably the most popular framework, but i think its at least a bit exaggerated due to this channels content. I dont think a broader audience would change this outcome a lot, but its still something to at least keep in mind.

[@user-kd6mg4te1i]

theo, what do you think of MasterCSS? as a very avid CSS traditionalist, i took a while to adopt Tailwind as well... when i came around, i came all the way around, i love it now. still, i can't help but resonate with some of the gripes about it from traditionalists. honestly, i feel like a lot of this is solved with Master... the shorthand is better, and the flexibility with variant grouping for modifiers is choice. one of my biggest complaints with Tailwind is having to prefix something like dark: or hover: a dozen times. UnoCSS has a plugin that fixes this, but Master has it built in AND its a superior syntax. its still too new to feel good about taking into the wild for me, and of course it doesn't have the plugin ecosystem... but i feel like you'd appreciate what they're doing with Master.

[@HoNow222]

Oh wow another day of drama on theo channel.....

[@eccenux]

CSS also has reusable primitives. They are called properties 😉. This is what he means by saying Tailwind reinvented grammar for styles. Like you say - in Tailwind each class is just one line... Yeah that is mostly, one property with a specific value. That is a new grammar. New syntax you have to learn. You cannot use tools that know CSS (like Chrome dev tools that help you add CSS properties to flexbox or grid).

[@niknaksim]

13:45 yeah I was thinking the same thing. This example can be managed like this with css properties if that is how you want to manage your css....

[@xuldevelopers]

You are living in a world where programmers are designers. Not my world.

[@ashnur]

DRY was/is constantly misunderstood. People think it means don't have repetitions in the code. But that would be Don't Repeat Code. It's Don't repeat yourself for a reason. If you repeat your code, that means you can find it once, change it once. writing continuously the same superficial abstractions to avoid duplicated code is practically the opposite of not repeating yourself.

[@Lucas-gt8en]

Very insightful! Finally puts my feelings about the levels of abstraction in MVC frameworks into words. Do we really need 10s of lines of codes doing _almost_ the same for every single API controller?

[@andreilucasgoncalves1416]

​@@Lucas-gt8enWell we need, specially with well defined snippets or using Copilot I personally think that people too obsessed with DRY are more unproductive than people who just write tons of boilerplates

[@halfamoose]

What do you think of tailwind for a React Native Expo project?

[@simonthiboutot8855]

What if you need to use CSS in both static HTML (let's say Rails) and SPA such as React, Vue.js, etc. would @apply be a good case?

[@taylorswe]

Tailwind saved my marriage

[@ir8293]

Adam Morse did ship Tachyons and Adam Wathan was just ripping it off.

[@hamzaabamboo]

Wow... the swiftui code you show looks almost identical to my css-in-js code (chakra-ui/pandacss)... does that also mean css-in-js is the way forward too !? OwO

[@osman3404]

@Theo, I REALLY appreciate what you do you do because you give a loud voice to my inner thoughts and feelings when I read articles like that one and others LooL

[@lukasmolcic5143]

at 16:50 where we are looking at the button classes its not really different from what I would expect from a button, buttons are surprisingly complex in terms of styling , you need to have a bunch of state styles and usually also different categories of variants like colors, sizes ot "types" (fill / outline), also you will often need to used the button styles for buttons, links and sometimes even labels (for example a custom file upload button) however you want to implement that is going to be more complex than you would guess from saying "its just a button"

[@Dreamvention]

What if you are trying to inspect the element and need to find the component. You can use classes as references to the component by structuring them accordingly. How would you do that with tailwind.

[@LukeG2393]

This sounds like there’s bigger problems already. What happens when someone doesn’t give a component a class name which aligns exactly with the component’s name? Or names it slightly differently and sends you down a rabbit hole? Inspecting element to find which component was used sounds like a band-aid to start with.

[@mornwind318]

You use the browser extension for React/Vue/Angular, and you can add a class named like the component if you really need to. But I rarely inspect an element in the context of a larger application, I prefer sandboxing in Storybook.

[@LeonBlade]

I'm not sure when this would ever come up. There are plenty of ways to label components though that aren't class based. Also, you probably shouldn't be naming or tagging elements with classes since that's not the purpose of classes.

[@Dreamvention]

@@LukeG2393 I agree it is not reliable. How would you inspect then?

[@Dreamvention]

@@LeonBlade what ways would you label?

[@CouchProgrammer]

21:01 The author of the article is using your argument. Putting styles in a separate file = putting classes in a component. This is the whole point of the article. Tailwind is terribly ugly for low-level styling. And even uglier due to the lack of aliases. In previous versions, it was not possible to style all button states. It just didn't compile. But the article is written crookedly. I was expecting some kind of cool take at the end of the article, but it didn’t come.

[@nickmanning214]

The original "CSS Zen Garden" vision of HTML and CSS was a beautiful concept. It's too bad the tech and business world ultimately didn't embrace it. I think if high skill and enthusiasm of developers towards HTML/CSS was the norm, rather than the typical negatively we see, this approach would have more adoption and we'd have a more interesting and artistic web.

[@guest7329]

32:59 isn't this pitch for using Rust?

[@norboost]

I just want to throw out there that at least in PHP (Symfony, Laravel) frontend components have been a thing for quite a while too. So it's not only a JS thing. I quickly checked and Laravel added Blade components over 7 years ago now.

[@Loggerr]

Much needed point out of discernment while reading (esp. for new devs)

[@vulbyte]

okay, genuine question, ive been using tailwind for a bit now, and i still struggle to see why i dont just do something like style={{}}? for me (a jr) it feels a lot like writing rxn instead of reaction

[@andybrice2711]

Yeah, I know what you mean. But one of Tailwind's strengths is it takes all the verbose complexity of CSS, and condenses it down to just the most useful features, using short codes which behave more predictably.

[@wi1h]

it's not that different from writing inline styles. there are two main things that make it better than inline styles: 1. it heavily urges you to use standardized values for CSS properties across the project. for example, font-xl by default is font-size: 1.5rem (you can change the specific value in the tailwind config for the project) (it also includes line-height but that's besides the point), and if you use font-xl everywhere in your project, the font size for your headers (or wherever you're using it) will be the same across the site. if you use inline styles, you can unknowingly be using different sizes in different places, leading to a less-cohesive looking site. sure, you can break out of it by doing font-[1.2rem] or whatever, but that's a clear indication that the style is NOT supposed to be like the other places 2. reusing CSS classes will dramatically reduce the bundle size compared to inline styles. this isn't really tailwind specific (however, tailwind excels at this because it only has one or two CSS properties per class) since any class-based CSS approach where classes are re-used between elements will reduce the bundle size compared to inline styles also, and this is less important, but it's still important, it's easier to type. this adds up in a big project

[@anthonyewell3470]

As someone who largerly makes static sites, Tailwind is the only way I do CSS, what is the author smoking XD

[@TheOriginalBlueKirby]

truthgasm

[@Zeragamba]

13:08 That one snippet there is why i really dislike Tailwind. Long trailing off list of classNames, that are just wrappers around standard CSS properties. It just seems like Tailwind is just moving a problem elsewhere and not solving it. I love MUI's sx prop, which allows making SCSS like CSS scoped within the component. Yes, it's not that applicable unless you're using MUI already, but if there's a similar JCSS style library out there, I'd very much consider it.

[@LeonBlade]

MUI's SX prop is basically tailwind but done with less lines of code. Also, there's no enforcement of using SX across all components or custom components either. This is something that you as the developer have to enforce and have to make sure the entire team uses. I worked on a CMS for a large streaming platform where we used React and MUI. Using SX was never standardized in any of the components that we created. In most cases, the other developers didn't bother doing anything like this. In most cases, a prop was added only when it was needed for style overrides. Tailwind does a similar thing but also being language agnostic as it's all just classes at the end of the day. It's more flexible in that sense. You are right that they do serve similar purposes.

[@zar3615]

In simple term when deploy a site you need to calculate inline class in html or semantic css which one will be smaller for you. If html overhead more than css then the answer will be different when css is more than html per page.

[@jaspreetmaan121]

I bet he still uses float:left to put multiple elements in same line

[@nyashachiroro2531]

What's up with NueJs and this whole TailwindCSS obsession? Is it a marketing thing? Do they think they will increase framework adoption this way.

[@Burgo361]

CSS is the part of web front end that tripped me up more than anything else, not only in writing it but dealing with the copy pasted code from others that caused chaos everywhere.

[@pqnet84]

The big issue I'd argue is that since you can't achieve reusability within CSS (without relying on some kind of preprocessor), you have no alternative other than moving the composition at class level (i.e. sticking multiple classes to a single element). That means that, since rules in a single css class cannot be separated, every class need to have a minimal amount of rules.

[@DominikZogg]

First time i used tailwind i made tons of own classes with @apply. It was totally against the idea, but it works. In the meanwhile i am using it as meant. No hate for CSS anymore, since i get rid of the "C" of it.

[@spicynoodle7419]

Laravel has template components that are basically "server components". It's static HTML but you can reuse markup and UI logic

[@rohitkharche7562]

I selected tailwind as my goto style system because I can visualise the ui just by reading the classes on the html, and the ability to see the inner styles tailwind uses greatly helped me to learn css

[@andreilucasgoncalves1416]

That sounds like someone who uses it for a long time and not everyone will have that ability

[@wojciechosinski5927]

I would argue that “well-designed” should also include a rule “the last style is the one that gets applied”.

[@rzr1191]

I've used CSS since 2011 but I cannot imagine going back to it after tailwind. All these tools & strategies over the years (BEM, SASS, etc) were all falling short of what modern components could deliver. And tailwind is the best component-native solution IMO - it beats every CSS-in-JS solution in terms of performance & ease People always get stuck talking about the 0.1% use-case... you can use a style tag for highly dynamic stuff or a regular className with css file/module for those complex cases and keep everything else simple, only relying on components for re-usability. Combined with CSS variables there's almost nothing you cannot do in that environment

[@notlekrut]

I also did not like Tailwind until I used it. Clicked within 1 minute of trying it out. Haven't stopped using it since. CSS used to be a pain on large existing codebases, now I just focus on the actual component template

[@danzerkp]

While it is still good to know traditional methods to write css for when one gets hired to fix up things like a wordpress site (lol !important jfc), tailwind at the least is good for all those utility classes, especially where columns & rows are concerned (in the past, a custom system would have to be written, look at past systems like skeleton css, & it just ends up feeling like tailwind but worse in retrospect). Tailwind definitely becomes more manageable in components, & sometimes I wonder if the initial documentation & demos introducing people to tailwind are jarring because of examples that include massive html blocks not split into components. There are still certain things that I like to roll up myself globally like headings & typography on the web, although I have been a fan of nativewind for react native development due to the need for text components to standardize reasonably.

[@ajpl87]

When I first discovered Tailwind, I came across Tailwind UI and even though I hadn't used Tailwind CSS yet, I just went ahead and bought Tailwind UI because I was so confident that Tailwind CSS was going to be as great as it looked. 3+ years later, still rocking Tailwind :D

[@ReViv4L]

This individual perfectly illustrates how seniority doesn't always translate to experience. Despite my own two decades of programming, my affection for Tailwind CSS isn't related to my longevity in the field. Tailwind CSS's strength lies in its atomic utility-based approach, fostering modular and reusable code structures, while also being adaptable to specific design requirements.

[@TravisHi_YT]

I don't like TWCSS but I still use it for this reason, this is a great take.

[@maximilianm7324]

Components are great. If I look at the tailwind classes I know immediately what to change 99% of the time.

[@KTibow]

I have to say Svelte's scoped styles & a basic color system have replaced Tailwind for my use cases. As soon as you have multiple pages and dynamic state, you end up shipping less CSS and writing cleaner code (both in my editor and Inspector). Dedicated languages (even if it's right next to the component) are better than class names since they aren't constrained to a big string.

[@gyurkesm]

I am working with web development as a side project, not an expert in any means, so please don't judge me too harshly. I am interested in the relevance of tailwind css in vue3. I am using vue 3 composition API with script setup AND style scoped. This way my styles are really close to the components, and cannot change the behaviour of other elements even with semantic css. I would think that tailwind would only make my html template look worse. Can you prove me wrong? Should I implement tailwind?

[@LeonBlade]

Scoped styles still have weird bleed over, at least that's what I've noticed when working with Vue. There's no reason you couldn't use scoped styles like this. The difference is that tailwind is doing a lot of work to make writing out your styles a lot more concise and with less lines of code. Tailwind also has the benefit of being configurable in a way that vanilla CSS does not unless you want to leverage CSS variables which then also need to be enforced everywhere explicitly. I'd say go ahead and try tailwind out anyway. It's really easy to set up and play around with.

[@TravisHi_YT]

TWCSS will make your template messy, but theres nothing stopping you from using a combo of TWCSS and your own CSS classes.

[@user-wq9mw2tm8q]

I started web design in 1998. Until recently I hated tailwind, I slated it and thought anyone using it must be an idiot. I worked on a project where it was badly implemented, which didn’t help. And then I tried it for myself, and it finally clicked. Tailwind is awesome and using components makes total sense.

[@Novadeo]

This article reminds me of the tenured professor writing from his ivory tower about how things should theoretically work out in the field. Meanwhile, everyone out there in the field putting in the work is laughing at how out of touch he is.

[@svenmify]

I don’t get tailwind. How is it any better than just inlining styles? And sure? You can combine them into classes, but we already could do that too. I’ve worked on a tailwind project and hated how cluttered it made the html. It felt like such a major step back with only minimal benefits. But I’ll fully admit that I may have missed something.

[@TravisHi_YT]

It's not really, I only use it for a handful of utility classes that are probably better handled in a component level anyway like ChakraUI. You may as well go the whole hog if you're embracing component driven development in that case.

[@hicoop]

I used to bring up the same points about tailwind before I tried it and now I can’t imagine styling without it😂

[@ronakmehta8106]

Reusability through js/web component were the jsx/html would have the correct class already added, So is the problem which people are having with tailwind is basically they are writing for the normal html and the reusability and developer experience doesn't translate well there ? like do they not know you can just write stuff on top off tailwind which would be handling key styling relation. I m not getting the problem which people are having with tailwind.

[@ultrahalf]

i assume its published on April 1st

[@goldydog1]

I think the true power in tailwindcss is having an API for your design system. Semantic class names have their pain points, but inline styles can also be a pain to work with. Especially when developing reusable component that need to support overriding styles I also find that we often want custom css classes for one off styles that aren't cleanly supported by tailwind imo. For example, an arbitrary value for box shadow in tailwind is difficult to read to me. Tailwind + css modules is my preferred approach.

[@stercorarius]

Adams original reasons for recommending against @apply is he was fed up dealing with bug reports where people used class inheritance / 'nested' applys. If you use a flat hierarchy of classes using @apply there isnt as much of an issue. That said, lack of cohesion still makes it feel better to declare tailwind class sets in actual code rather than css when using react. If you have scoped css like svelte and vue, @apply is still pretty great.

[@lawrencejob]

Separation of concerns isn't problematic, they're just applying it on the wrong axis. Components are separation of concerns on the functionality domain (aka vertical slice); style and behaviour is separation of concerns on the technology domain (horizontal slice). (Plus the selector/specificity model is inherently leaky way to couple between style and behaviour.)

[@Tekay37]

17:30 I think the main concern with tailwind is, that you're having a harder time maintaining the html when you use css the tailwind way. This may even come from a perspective where you don't create dozens or even hundreds of minimal components for all the sub-elements of a page. E.g. would you create a separate component for a single label/input combination in a form? If you do, then using tailwind within that very small component makes perfectly sense, but if you don't, then applying all those tailwind classes to every row makes the form completely unreadable. So, the root of this discussion might just be looking at tailwind from completely different perspectives, where from one perspective, tailwind doesn't make any sense, but from the other perspective it's the obvious way of doing things. This can make it impossible to get to common understanding until you understand each others perspectives. (I find this issue to be very common these days. People argue about a thing and why it's good or bad, but they never clarify the perspective they're coming from or the premises they base their argument on. This is not a tech exclusive issue, btw.. It seems to be the root of many heated debates).

[@mornwind318]

I see why a tool wouldn't make sense for you. I don't see how they can warp it into "it's a conspiracy to make money out of poor developers who don't know better".

[@MichaelScharf]

My problem with tailwind is that the developers are not creating components

[@pqnet84]

would you expect the same developers to write a clean semantic markup with global reusable rules? Or would they just add one more if they need more spacing?

[@andybrice2711]

_"It's only a matter of time before Tailwind collapses."_ I'd tend to agree. But only because there'll be something better which synthesizes the best parts of Tailwind and vanilla CSS. People won't just go back to the old ways.

[@TheYinyangman]

separation of which concerns ?

[@anthonybeard3238]

I feel like the author doesn't actually understand "separation of concerns". I haven't used Tailwind (been ages since I've done any UI work), but it looks to me like they actually follow this principle more closely than the author of this article. To me, separation of concerns means "design your code so you can focus on one piece without worrying about the other pieces". Being able to write a component that contains everything it needs allows you to separate the concerns of a button from the concerns of a heading, while also separating form/function granularly for each component. This person can't get by the dogmatic idea that "separation of concerns" MUST ONLY mean separating into a few monoliths, rather than practicing separation at each level of abstraction, which Tailwind appears to do very well.