@@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)`.
@@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
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😂
"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?
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.
@@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
Think of html elements and vanilla css as assembly language Components as higher language that generates html Tailwind as higher language to generate the Vanilla css
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
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
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.
@@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...
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.
@@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.
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.
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!
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!
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
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
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.
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.
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.
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.
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
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.
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.
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
I find it hypocritical how you try to monopolize the right of "harassing" the guy (publicly trashtalking, mocking him in a mildly(?) passive-aggressive way for ~40 minutes, cussing, calling his arguments stupid etc. etc.), preemptively threatening everyone else attempting... I don't know... the same? :) Or what exactly do you mean by not "giving him shit"? That's not a very robust guiderail for avoiding your almighty permabans.
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.
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).
From the tailwind docs: "If you need to reuse some styles across multiple files, the best strategy is to create a component [...]" They most certainly do encourage creating components. Theo also pointed this out in the video.
@@LeonBlade Creating components is good. No doubt about it. Yet, why not pushing it further also to components themselves : "If you need to use lots of utility classes across a single component file, the best strategy is to create a reusable custom semantic class name corresponding to the component" 😁😉
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 🙂
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.
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
@@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.
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.
@@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
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.
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.
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.
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.
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.
I'm on building a new version of my own framework. :) A good exercise to make it evolve with new techs and practices : a tool that makes sense to us, keeping good ideas from today's frameworks and getting rid of their flaws. Is that reinventing the wheel ? Yes of course (or the piston, the axle ?), like Tailwind reinvented it it's way, or React and JSX, Next or Nuxt, Symfony or Laravel 🙂. Choose the piece you feel could be improved. I won't be smart enough to produce a revolutionary tool, but hey : we're not alone 😀
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.
Now I know why I don't like Tailwind. I am a 'static HTML' guy and I have actually mastered CSS. Some old guy was talking about how he prefers to make web and how Tailwind goes against that, and Theo was sitting there losing his mind, getting super emotional, screeching things along the lines of, "I haven't experienced web development in this way!! This doesn't fit my world view!! Large under-skilled teams using component frameworks with Tailwind are indisputably the only way that the web can be made!! You shouldn't hide CSS away in CSS files!! CSS is too hard and painful to master!! Anything in CSS I haven't mastered isn't worth mastering!! Developers are all too incompetent to be trusted to write CSS!! Tailwind made me better at CSS!! Semantic html is bulls**t!!" This video seems to communicate that Tailwind is awesome for teams of devs that are under-skilled in CSS, struggle with file browsers and never learned what HTML is actually supposed to be and have become too invested in their way of doing things to care - which I assume is like 97% of all the devs out there.
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.
Theo: "this guy is making lots of reaches and he better justify them" Poster exposing a reach from the Tailwind devs: "Semantic CSS (is) fucking bullshit" Theo: "yeah. 100% true" cmon dude, you are dissing the guy as being biased just for having a different point of view, and then you are just as biased as he is. I honestly tried Tailwind as vanilla and as component library. Its not a good experience if you're maintaining a large app with tons of components. Its borderline worse than just slapping a style tag and forgetting about classes altogether. The verbosity is practically the same. And you got to be insanely biased to claim that this monstrosity: "sticky top-0 z-40 w-full backdrop-blur flex-none transition-colors duration-500 lg:z-50 lg:border-b lg:border-slate-900/10 dark:border-slate-50/[0.06] bg-white supports-backdrop-blur:bg-white/95 dark:bg-slate-900/75" every 2 lines of your html is readable and maintainable instead of just "dashboard-header". Plus any gains you had with lower css bandwidth you will lose 10 times more on html/js bandwidth. You may claim that tailwind is more reusable, but I am not willing to pay the insane price tag on maintainability for it. I would honestly would only use tailwind for some contractor job for some quick page that I would never have to touch again in my life. For business critical large apps its a footgun.
People forget that theo's professional frontend experience is basically Twitch. Rumor has it he has a startup that's.. Also twitch. Prime has basically worked at Netflix his entire life on tools and small subsystems/services.
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
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.
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)
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 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.
@@LeonBlade you can use Vite, which is popular and configure whatever you want, using npm modules just like at the gulp time, so using scss, or sprites generator etc : anything you want, i got it 😉
Tailwind is to CSS what emojis are to normal language, while SCSS is literature. ;P That being said... I would never degrade myself to Tailwind and its nuclear wasteland of terrible and unmaintainable HTML.
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.
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
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.
@medbenbrahim3246, I think it's because Tailwind authors tried to achieve something absolute perfection for an idea. But the absolute is paid for somewhere else (here in the markup and readability). Having some helpers/utility classes is good, but why getting rid of css components class names like in Bootstrap ? An accordeon is always the same thing, a dropdown, a modal, a card (whatever it represents) : these are components and everybody knows their function : there's no naming issue here. Bootstrap design wasn't configurable, but Tailwind could have kept some good things in it, adding their good things (css purge, design system) instead of pushing the utility concept to an absolute that leads to divide the developpers. That is not pragmatism, that's ideology.
Tailwind is something that I never felt the need for personally. Less and components with scoped CSS already solved the problems I personally encountered. I don't like the the huge wall of text for style-heavy designs/elements, it's a huge blob of text and seems more verbose if you need to change styles based on the state. Adding/removing a group of styles and giving them a name is more readable and intuitive than adding several conditions. "You have to think up class names all the time" is something I 100% disagree on being a disadvantage to class-based CSS. Giving names to concepts is, while difficult, an important part of organizing and understanding code. Another point is simply reducing third-party dependencies. It's yet another tool that I need to learn and maintain. This is something I struggle with more than most other problems, the explosion in different tools/libraries and all the struggles that comes with that. However I see the point where it can help with bigger teams and frequent redesigns. Maybe it's just not for me.
Naming collisions is one thing and is solved by scopes. Another problem is classes trying to be generic across quite similar but slightly different use cases. This is another trap or rather tradeoff also present in other domains of programming or engineering in general. Sometimes you want to generalize to not duplicate stuff and effort and other times you need specialized implementations to not make it overly complex and handle dozens of special cases (jack of all trades, master of none). I find it quite strange to say either case is always right. Education may also play a role here. I see quite a lot juniors who are developers and don't know much about the fundamentals of their environment, severely limiting their tool set to solve problems. Then they stay in that role, are told to use only framework/library X without understanding what problem they are actually trying to solve or how everything works under the hood. But that is another rant.
While most people here convinced me to use TW in my next project I agree with you about naming collisions In my 8 years working in the web I never had any problem with naming collisions even working with other people Most of the time just use a name convention like ComponentName_box1.show that is fine
CSS modules solve the problem in another way compared to Tailwind, but no one wants to go back to having CSS cascade around like the author of the article implies. It's not "cleaner", "simpler" or anything like that. In fact, having to deal with that shit is pure hell. You have to rely on everyone else knowing it well and being careful, and at any time someone might throw a wrench in the whole thing. It's madness, and pointless, in a component world. Good fucking thing there are CSS modules. Yet, CSS modules are still one solution that require tooling. I do use them, I prefer them to Tailwind "usually". The con is that you write all your shit from scratch and I usually prefer to use something like Tailwind as a bootstrap. It takes a ton of time to make your own utility functions and all, and rarely clients (but it happened to me recently) have money and time to spare for you to make an entire design system from zero. Ironically, including something like tachyons means you have still a ton of CSS classes everywhere, but at least it's zero tooling.
Re: wall of text. If you are concerned about the same classes being repeated, you can always either create a smaller sub component (as Theo mentioned) or assign the classes to a const and then reuse it from there. If you issue is that the list of classes is too long, then just use a multi line string or join an array of strings. simple as Re: need to learn yet another tool. If this is your mindset why use React or any other component framework? Why not just roll your own component framework? It's less to learn, you just need to know Js, right? Except anyone who comes over to your project now needs to learn your bespoke framework. The same with Tailwind. A lot of people already know it well so they will be able to start contributing really fast. They no longer need to learn some non transferable knowledge about where you keep various aspects of your design system. Granted, its not a big deal to learn where you keep your colors, but its also not a big deal to learn tailwind. The documentation is excellent, there is autocomplete support and if you already know CSS, its actually very similar just a bit less verbose. Re: Maybe it's just not for me That is quite possible. But you might want to try it in a side project or whatever just to be sure. Why avoid something that is quickly becoming an industry standard?
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.
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.
What I find interesting is that you tell your followers not to flame this guy as you quickly ramp up the flaming and vulgarity pointed at this guy. Obviously he has a severe lack of experience working with web outside static HTML pages or he's openly trolling RUclipsrs like you who get their dander up with this kind of mind-imploding drivel that appears to be written in the "adult voice" of life.
Except that wouldn’t be something you do with tailwind in practice; you use it with a framework in a component to not reproduce the same styles over and over.
Tailwind’s selling point is ensuring your code’s maintainability, and that “problem” you’re complaining about has nothing to do with ensuring maintainability.
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.
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?
@@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
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.
I'm giving Tailwind its chance to for a week now... and i feel exactly what you describe. More code, more searching in the doc : more disadvantages than advantages. I really try, and i watch lots of videos to truly understand what gain is there... but except the css purge, all other arguments (one file for all, speed, "component") doesn't seem to take all the process to make the point. It's so amazing that sometimes it looks like either bad faith or i don't know... you know that kind of enthousiasm that is about some fashion... Lots of Tw defenders say they didn't like css before styling with Tw. It seems the only true reason of all that debate. Long ago i wasn't confortable with JS so i used jQuery. Though, i didn't think i used a miracle modern solution : i knew i wasn't good enough to code full JS. Anyway, Tailwind fans have the right to think that way, and i hope they let those who prefer standard css/scss coding thinking their way. I just enter this debate, so i find it interesting, but as it goes around in circles, sure i'll shortly have covered it. Anyway, in the end, what the browser understands is still html, css, and js :)
You have a button with 20 classes. You have 20 buttons on a page which are SSR. Will you deliver 400 classes with tailwind? I get all the component abstraction thingy. It makes sense from DX, but I'm not sure this is a wildcard for every case. The "primary" class abstraction that has all that CSS prevents you from repeating the same thing to be delivered to the client over the network. Unless gzip fixes that, I don't see that much benefit from tailwind. It remains a matter of taste in my opinion. I would appreciate a reading of an article less passionate and more constructive.
You are sending the classes only 20 times, but the class names would be sent 400 times. But if you are really in a position where you are optimizing text data this much, you probably should hand write everything without a framework at all, let alone tailwind.
Components are great. But besides Tailwind and global CSS there are: - CSS Modules (+ no naming problems, + no performance overhead, + no mess in the markup, + almost no learning curve, - still separate file, - no easy achievable type safety) - CSS-in-JS (+ no naming problems, + alomost no learning curve, + everything in one place, + max interactivity, + type safety, - performance overhead, - same mess in the markup) - Stylex (haven't used it yet, but from what people say at the Internet, it is the best of both CSS Modules and CSS-in-JS) Why everyone keeps comparing 2000-s CSS with Tailwind and completely forgets about every other way of solving the problem?
@@mornwind318 not exactly. it is about why use tailwind over generic CSS. but no one uses generic CSS in big projects. and everyone knows downsides of generic CSS. so much more interesting topic would be why use tailwind over any other styling solution out there.
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 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.
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.
Why is tha author so bitter? 😅It feels like he come up with an idea he wanted to achieve then somebody was just way quicker and published the same idea and monetized it and now he is heartbroken and mad about it.
You say you don't want people going after this person, and yet your video is full of swearing at them and calling them names, instead of just pointing out the problems in the article. I agree with your arguments and explanations, but just randomly calling them names and saying shit like "I bet they still use double equals" is just uncalled for behavior I feel you specifically started the article by saying don't do. And yet the video just devolves into a tirade against the person instead of against the argument/post.
_"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.
@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
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.
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.
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.
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 :)
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
If that is indeed your point about Tailwind then you never needed 95% of Tailwind in the first place; you could get all of the low level reusability with ‘style=“foo: bar” and all the other benefits from a minimal set of variables, mixins, and convenience classes for flex/grid/responsive stuff. Which incidentally is where the CSS world was headed when Tailwind showed up and dumped a steaming pile of 1999 on a generation of junior frontenders and pretended it was “progress”.
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.
0:51: I completely disagree. CSS cascades and that's one key element of CSS that tailwind doesn't make use of. The best CSS is when you have a default and then, when it's not the default, you build on top of that default by overwriting that default. The best CSS is actually in between what tailwind does and what tailwind says it comes to fix. In the example, you have a "uilist" and you have a "uilist-item". What's the "uilist-item" for? Just ommit it. Whatever is directly inside a uilist is its item.
The point of the video aside, How can you tell your community to not harass this guy, but then constantly cuss at him and resort to personal attacks yourself? Grow up.
Had to stop the video at 22:55 . Have no limits on this stuff in fictional media, but not much tolerance for it IRL and certainly no room for it in my professional life..
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
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.
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
Well, i kinda have a strange relationship with tailwind. I HATE those types of elements with 15-20 classes on them (that's not even a joke, that's default when you work with tailwind). It makes the code of components unreadable, a big part of your component is now just css classes. Also i like it more when css is in a separate file, makes it way more manageable. But i also like concise aliases of tailwind. So i use tailwind by still naming classes in a component using bem methodology and @apply in css files. Although tailwind is not recommending this approach - i find it best for me. Css files become more readable than default css, they have fewer lines in them, and i don't have my components clogged with tailwind classes. And maybe it's just for me, but it's way easier to debug css like that - i know exact name of the node provided by human readable css class, it's easy to find it in debugger and editor
I kind like your approach, but I like to have smaller CSS files for big SSR projects and use @apply is kind of using normal CSS with convention Anyway I will keep experimenting things
@@andreilucasgoncalves1416 i also like this approach. I think there is something to search between Tailwind (css purge and utility for some specific needs), Bootstrap (components : dropdowns, modals, sliders etc... each one in the same file or the same folder as the component's one) and Scss (advanced configurability and opened to whatever system you need).
I feel like these people are just mad that they don't understand something that so many other people love. Not wanting to use something is fine, but you can't just deny the value that it provides to other people.
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?
The thing I don't like about tailwind is the lack of abstractions. You can create custom classes but people seldom do it. The way tailwind is used on projects I worked on is just a lazy way to write inline styles. As a designer, I care about the brand and the style guide. These are business rules and I can model them with CSS. I agree semantic (content) class names are bad for components (duh), but there are steps between this and inline styles with zero abstraction
@@CodecrafterArtemisI am talking about meaningful reusable and parameterized styles and about cohesion and coupling. Typically, when you have inline media queries spread everywhere it is no longer possible to reason about different layouts for different sizes because you can't even read a cohesive set of rules, or when you move one component at a different spot and there should no longer be this or that contextual style on it (like a bigger margin because it follows an image or whatnot) there is nothing in the code reminding you to remove that style. From what I have seen, and I would love to be wrong, Tailwind inline classes kill any attempt at creating higher level abstractions, they are simply shorthand ways of writing inline styles. The points made in the video (I didn't watch it till the end) are not invalid to me, but they are no excuse for mindlessly peppering inline styles everywhere. When I talk to other devs about it they just say "I like it, it's fast". It's fast to make a mess, but then when you ask the former designer (myself) to fix inconsistent styling in their code, I can see no rule, no pattern, and it feels like a time machine brought me back 15 years ago.
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.
I haven't used Tailwind yet because none of the projects I've been working on have used newer CSS, but this video really helped make it seem VERY smart and reasonable compared with maintaining "semantic" classes which constantly become out of date. I recall learning about scoped styles when I first learned VueJS - it felt different but immediately it was apparent how much of a benefit there was in keeping your styles co-located closely with your component. Whole article seemed like nonsense about halfway through. Thanks for the laughs Theo.
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.)
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
Theo completely loses a point at the moment of the video where he asks “How the html button differs from component”? The problem arises when you actually need to style some other element AS a button without actually using a button tag (navigation link, select trigger, whatever else). That’s where the nonsense like comes from. I would say that having a JS component is actually killing the purpose of Tailwind in the first place here. I usually implement reusable components at the Tailwind configuration level, with a custom plugin which configures a button component class within the addComponents utility. This way I can still get the benefits of Tailwind (like autocomplete, style purging, etc) but now and will have the same appearance but could do totally different things Even more than that, since Tailwind is framework-agnostic, I can just copy its config from React project into Astro or Svelte and still have exactly the same UI for my html which makes this approach infinitely more reusable than just an incapsulated React Button
Browser ui: Largely moved to component based Mobile: Ditto Desktop: getting there Server side: yup, very commonly used This means that dozens to hundreds of vendors across different devices, languages and ecosystems have moved there after all independently verifying the benefits but it’s a fad apparently. Angular 1 and React were a fork in the road towards the then HTML/CSS orthogonal concern’s approach and the industry as a whole has pretty resounding chosen data-driven, declarative components. This guy sounds like those people that cried “Apple has betrayed me!” When Swift was released. Clearly a recipe-oriented thinker. Yet another ever-junior confusing tenure with experience.
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.
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 💙.
I still think that tailwind is useless, and is just the successor of bootstrap. With css modules or a system like the one implemented in svelte i really see only downsides in using tailwind.
Now that’s a rare insult “this guy still uses double equals” 😂
lmfaooooo
I feel called out.
I know in Python we now use "is"
but is the Top-G move in typescript really just ===?
@@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)`.
@@theseangle so... as always the fix in javascript is inventing something new that does the samething a little bit different?
@@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
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😂
Funny enough this is kind of how I got into it as well
me too ))
Maybe that's the intention of the author, get people thinking that his post doesn't make sense, and push people into Tailwind.
"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?
Yea lol, makes sense since custom reusable components and tailwind are abstractions for barebones html and css, literally made for each other 👍
Would love to have this as a shirt too
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.
@@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
Think of html elements and vanilla css as assembly language
Components as higher language that generates html
Tailwind as higher language to generate the Vanilla css
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
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
hi.... I see you everywhere...
Yup, that's why I love tw with Vue/Svelte - use tw for 95% cases, use scoped style blocks for the rest
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.
@@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...
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.
Try CVA. It cleans up your class names and dictates your component API at the same time.
@@beowulf_of_wall_st getting in the way of what?
"You can clean things up later." My man clearly never worked in any kind of... well, job.
Yeah "later" in programming world usually translates to "never".
@@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.
@@ChristophFloat lol so true. Backlog just becomes a dumping ground for tickets like that.
no matter what industry you're in, no one will remember to do the clean up. 😂
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.
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!
Honestly, I've used both and this time I do not even care I know the truth and will not stop using Tailwind, period.
I can't go back to plain css after 4 years using tailwind daily.
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.
Theo gon from 0 tilts to 100 tilts in 25 mins lolol.
More like 115.69 tilts.
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!
Vanilla CSS bros, are we enjoying this drama? I know I am >:->
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
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
GPT being better with tailwind is a bigger seller point
THE TAILWIND PROPAGANDA MACHINE
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.
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.
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
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.
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.
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
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.
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.
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
is antipattern in REact but somehow Tailwind is not
You have to doit with colors coming from code
I find it hypocritical how you try to monopolize the right of "harassing" the guy (publicly trashtalking, mocking him in a mildly(?) passive-aggressive way for ~40 minutes, cussing, calling his arguments stupid etc. etc.), preemptively threatening everyone else attempting... I don't know... the same? :) Or what exactly do you mean by not "giving him shit"?
That's not a very robust guiderail for avoiding your almighty permabans.
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.
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).
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....
Studying the MDN docs feels like such gate keep vibes. Just build stuff, learn based on problems you encounter while building stuff, its fine!
Tailwind does not encourage creating component. All tailwind I have seen so far spaghetti code
From the tailwind docs: "If you need to reuse some styles across multiple files, the best strategy is to create a component [...]"
They most certainly do encourage creating components. Theo also pointed this out in the video.
this is nonsensical
@@LeonBlade Creating components is good. No doubt about it. Yet, why not pushing it further also to components themselves : "If you need to use lots of utility classes across a single component file, the best strategy is to create a reusable custom semantic class name corresponding to the component" 😁😉
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 🙂
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.
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
@@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.
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.
@@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
sounds like a hitpiece for people to talk about their framework
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.
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.
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.
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.
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.
Haters gonna hate you onow
He did build his own framework :)
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.
I'm on building a new version of my own framework. :)
A good exercise to make it evolve with new techs and practices : a tool that makes sense to us, keeping good ideas from today's frameworks and getting rid of their flaws. Is that reinventing the wheel ? Yes of course (or the piston, the axle ?), like Tailwind reinvented it it's way, or React and JSX, Next or Nuxt, Symfony or Laravel 🙂. Choose the piece you feel could be improved. I won't be smart enough to produce a revolutionary tool, but hey : we're not alone 😀
Aw man, Theo...
24:24
Those statements will age like milk, believe it. This is too painful to watch
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.
Now I know why I don't like Tailwind. I am a 'static HTML' guy and I have actually mastered CSS. Some old guy was talking about how he prefers to make web and how Tailwind goes against that, and Theo was sitting there losing his mind, getting super emotional, screeching things along the lines of, "I haven't experienced web development in this way!! This doesn't fit my world view!! Large under-skilled teams using component frameworks with Tailwind are indisputably the only way that the web can be made!! You shouldn't hide CSS away in CSS files!! CSS is too hard and painful to master!! Anything in CSS I haven't mastered isn't worth mastering!! Developers are all too incompetent to be trusted to write CSS!! Tailwind made me better at CSS!! Semantic html is bulls**t!!"
This video seems to communicate that Tailwind is awesome for teams of devs that are under-skilled in CSS, struggle with file browsers and never learned what HTML is actually supposed to be and have become too invested in their way of doing things to care - which I assume is like 97% of all the devs out there.
Bro, you just hate components.
@@rapzid3536 coding css does not mean you hate component. css is a langage, component is something you can build with this langage...
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.
Theo: "this guy is making lots of reaches and he better justify them"
Poster exposing a reach from the Tailwind devs: "Semantic CSS (is) fucking bullshit"
Theo: "yeah. 100% true"
cmon dude, you are dissing the guy as being biased just for having a different point of view, and then you are just as biased as he is.
I honestly tried Tailwind as vanilla and as component library. Its not a good experience if you're maintaining a large app with tons of components. Its borderline worse than just slapping a style tag and forgetting about classes altogether. The verbosity is practically the same. And you got to be insanely biased to claim that this monstrosity: "sticky top-0 z-40 w-full backdrop-blur flex-none transition-colors duration-500 lg:z-50 lg:border-b lg:border-slate-900/10 dark:border-slate-50/[0.06] bg-white supports-backdrop-blur:bg-white/95 dark:bg-slate-900/75" every 2 lines of your html is readable and maintainable instead of just "dashboard-header". Plus any gains you had with lower css bandwidth you will lose 10 times more on html/js bandwidth.
You may claim that tailwind is more reusable, but I am not willing to pay the insane price tag on maintainability for it.
I would honestly would only use tailwind for some contractor job for some quick page that I would never have to touch again in my life. For business critical large apps its a footgun.
People forget that theo's professional frontend experience is basically Twitch. Rumor has it he has a startup that's.. Also twitch.
Prime has basically worked at Netflix his entire life on tools and small subsystems/services.
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
It's not a standard, it's just popular
@@_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.
lol it's just an abbreviation of a standard. Majority of us have already memorized the standard.
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.
As someone who has not done any front-end dev in about 4 years, that comment was very insightful. Thank you.
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)
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.
As opposed to what people used to use (SASS/SCSS processors and editor plugins, CSS module plugins, CSS linters and bundlers, etc.)?
@@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.
@@LeonBlade you can use Vite, which is popular and configure whatever you want, using npm modules just like at the gulp time, so using scss, or sprites generator etc : anything you want, i got it 😉
This is infuriating and hilarious at the same time
Not sure I follow what you mean when you say that you have no guarantees on how a element works.
Tailwind is to CSS what emojis are to normal language, while SCSS is literature. ;P
That being said... I would never degrade myself to Tailwind and its nuclear wasteland of terrible and unmaintainable HTML.
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.
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
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.
@medbenbrahim3246, I think it's because Tailwind authors tried to achieve something absolute perfection for an idea. But the absolute is paid for somewhere else (here in the markup and readability). Having some helpers/utility classes is good, but why getting rid of css components class names like in Bootstrap ? An accordeon is always the same thing, a dropdown, a modal, a card (whatever it represents) : these are components and everybody knows their function : there's no naming issue here.
Bootstrap design wasn't configurable, but Tailwind could have kept some good things in it, adding their good things (css purge, design system) instead of pushing the utility concept to an absolute that leads to divide the developpers.
That is not pragmatism, that's ideology.
Tailwind is something that I never felt the need for personally. Less and components with scoped CSS already solved the problems I personally encountered. I don't like the the huge wall of text for style-heavy designs/elements, it's a huge blob of text and seems more verbose if you need to change styles based on the state. Adding/removing a group of styles and giving them a name is more readable and intuitive than adding several conditions.
"You have to think up class names all the time" is something I 100% disagree on being a disadvantage to class-based CSS. Giving names to concepts is, while difficult, an important part of organizing and understanding code.
Another point is simply reducing third-party dependencies. It's yet another tool that I need to learn and maintain. This is something I struggle with more than most other problems, the explosion in different tools/libraries and all the struggles that comes with that.
However I see the point where it can help with bigger teams and frequent redesigns. Maybe it's just not for me.
Naming collisions is one thing and is solved by scopes. Another problem is classes trying to be generic across quite similar but slightly different use cases. This is another trap or rather tradeoff also present in other domains of programming or engineering in general.
Sometimes you want to generalize to not duplicate stuff and effort and other times you need specialized implementations to not make it overly complex and handle dozens of special cases (jack of all trades, master of none). I find it quite strange to say either case is always right.
Education may also play a role here. I see quite a lot juniors who are developers and don't know much about the fundamentals of their environment, severely limiting their tool set to solve problems. Then they stay in that role, are told to use only framework/library X without understanding what problem they are actually trying to solve or how everything works under the hood. But that is another rant.
While most people here convinced me to use TW in my next project I agree with you about naming collisions
In my 8 years working in the web I never had any problem with naming collisions even working with other people
Most of the time just use a name convention like ComponentName_box1.show that is fine
CSS modules solve the problem in another way compared to Tailwind, but no one wants to go back to having CSS cascade around like the author of the article implies. It's not "cleaner", "simpler" or anything like that.
In fact, having to deal with that shit is pure hell. You have to rely on everyone else knowing it well and being careful, and at any time someone might throw a wrench in the whole thing. It's madness, and pointless, in a component world. Good fucking thing there are CSS modules.
Yet, CSS modules are still one solution that require tooling. I do use them, I prefer them to Tailwind "usually". The con is that you write all your shit from scratch and I usually prefer to use something like Tailwind as a bootstrap. It takes a ton of time to make your own utility functions and all, and rarely clients (but it happened to me recently) have money and time to spare for you to make an entire design system from zero.
Ironically, including something like tachyons means you have still a ton of CSS classes everywhere, but at least it's zero tooling.
Re: wall of text.
If you are concerned about the same classes being repeated, you can always either create a smaller sub component (as Theo mentioned) or assign the classes to a const and then reuse it from there. If you issue is that the list of classes is too long, then just use a multi line string or join an array of strings. simple as
Re: need to learn yet another tool.
If this is your mindset why use React or any other component framework? Why not just roll your own component framework? It's less to learn, you just need to know Js, right? Except anyone who comes over to your project now needs to learn your bespoke framework. The same with Tailwind. A lot of people already know it well so they will be able to start contributing really fast. They no longer need to learn some non transferable knowledge about where you keep various aspects of your design system. Granted, its not a big deal to learn where you keep your colors, but its also not a big deal to learn tailwind. The documentation is excellent, there is autocomplete support and if you already know CSS, its actually very similar just a bit less verbose.
Re: Maybe it's just not for me
That is quite possible. But you might want to try it in a side project or whatever just to be sure. Why avoid something that is quickly becoming an industry standard?
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.
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.
What do you mean by this?
What I find interesting is that you tell your followers not to flame this guy as you quickly ramp up the flaming and vulgarity pointed at this guy. Obviously he has a severe lack of experience working with web outside static HTML pages or he's openly trolling RUclipsrs like you who get their dander up with this kind of mind-imploding drivel that appears to be written in the "adult voice" of life.
Semantic HTML is for the consumer of the HTML the USER not for the developer ???
Good point
Oh wow another day of drama on theo channel.....
tailwind guys seriously suggesting multi cursor editing to solve problems they just created jesus christ
Except that wouldn’t be something you do with tailwind in practice; you use it with a framework in a component to not reproduce the same styles over and over.
Tailwind’s selling point is ensuring your code’s maintainability, and that “problem” you’re complaining about has nothing to do with ensuring maintainability.
I bet he still uses float:left to put multiple elements in same line
It was not a fun video to watch - you hate-reading something. If you don't take it as an opportunity to teach, it just doesn't feel good.
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.
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?
@@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
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.
I'm giving Tailwind its chance to for a week now... and i feel exactly what you describe. More code, more searching in the doc : more disadvantages than advantages. I really try, and i watch lots of videos to truly understand what gain is there... but except the css purge, all other arguments (one file for all, speed, "component") doesn't seem to take all the process to make the point. It's so amazing that sometimes it looks like either bad faith or i don't know... you know that kind of enthousiasm that is about some fashion... Lots of Tw defenders say they didn't like css before styling with Tw. It seems the only true reason of all that debate. Long ago i wasn't confortable with JS so i used jQuery. Though, i didn't think i used a miracle modern solution : i knew i wasn't good enough to code full JS.
Anyway, Tailwind fans have the right to think that way, and i hope they let those who prefer standard css/scss coding thinking their way. I just enter this debate, so i find it interesting, but as it goes around in circles, sure i'll shortly have covered it.
Anyway, in the end, what the browser understands is still html, css, and js :)
You have a button with 20 classes. You have 20 buttons on a page which are SSR. Will you deliver 400 classes with tailwind?
I get all the component abstraction thingy. It makes sense from DX, but I'm not sure this is a wildcard for every case. The "primary" class abstraction that has all that CSS prevents you from repeating the same thing to be delivered to the client over the network. Unless gzip fixes that, I don't see that much benefit from tailwind.
It remains a matter of taste in my opinion.
I would appreciate a reading of an article less passionate and more constructive.
You are sending the classes only 20 times, but the class names would be sent 400 times. But if you are really in a position where you are optimizing text data this much, you probably should hand write everything without a framework at all, let alone tailwind.
Components are great. But besides Tailwind and global CSS there are:
- CSS Modules (+ no naming problems, + no performance overhead, + no mess in the markup, + almost no learning curve, - still separate file, - no easy achievable type safety)
- CSS-in-JS (+ no naming problems, + alomost no learning curve, + everything in one place, + max interactivity, + type safety, - performance overhead, - same mess in the markup)
- Stylex (haven't used it yet, but from what people say at the Internet, it is the best of both CSS Modules and CSS-in-JS)
Why everyone keeps comparing 2000-s CSS with Tailwind and completely forgets about every other way of solving the problem?
Mostly because the article was about tailwind?
@@mornwind318 not exactly. it is about why use tailwind over generic CSS. but no one uses generic CSS in big projects. and everyone knows downsides of generic CSS.
so much more interesting topic would be why use tailwind over any other styling solution out there.
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.
True, but most developers are also using React.
@@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.
Theo doesn’t seem to receive criticism gently, like a good programmer should.
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.
You are living in a world where programmers are designers. Not my world.
Why is tha author so bitter? 😅It feels like he come up with an idea he wanted to achieve then somebody was just way quicker and published the same idea and monetized it and now he is heartbroken and mad about it.
You say you don't want people going after this person, and yet your video is full of swearing at them and calling them names, instead of just pointing out the problems in the article. I agree with your arguments and explanations, but just randomly calling them names and saying shit like "I bet they still use double equals" is just uncalled for behavior I feel you specifically started the article by saying don't do. And yet the video just devolves into a tirade against the person instead of against the argument/post.
the same shit he's done with his "funny" PR in Turbo.
_"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.
@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
Tailwind saved my marriage
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.
Adam Morse did ship Tachyons and Adam Wathan was just ripping it off.
"DRY was not the right way to think about your code"? You said that pretty casually for such a hot take
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.
GPT-4 generates great React components with Tailwind classes, and that is all the reason I need to keep using Tailwind
Sorry Theo, this has to be a thumbs down - You Stay Classy
that was helpful, thanks! Learned more about the why of tailwind than in hours of searching and arguing!
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.
This is only true if you have a global selector. .Foo > dialogue {...}
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 :)
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
Classic mistake of assuming everyone is in React. Some of us actually ship HTML only.
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.
Much needed point out of discernment while reading (esp. for new devs)
jesus this theo guy must be the saltiest guy on earth, we get it dude, can say all you said while being calm. Toxic attitude
If that is indeed your point about Tailwind then you never needed 95% of Tailwind in the first place; you could get all of the low level reusability with ‘style=“foo: bar” and all the other benefits from a minimal set of variables, mixins, and convenience classes for flex/grid/responsive stuff. Which incidentally is where the CSS world was headed when Tailwind showed up and dumped a steaming pile of 1999 on a generation of junior frontenders and pretended it was “progress”.
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.
0:51: I completely disagree. CSS cascades and that's one key element of CSS that tailwind doesn't make use of.
The best CSS is when you have a default and then, when it's not the default, you build on top of that default by overwriting that default.
The best CSS is actually in between what tailwind does and what tailwind says it comes to fix.
In the example, you have a "uilist" and you have a "uilist-item". What's the "uilist-item" for? Just ommit it. Whatever is directly inside a uilist is its item.
The point of the video aside,
How can you tell your community to not harass this guy, but then constantly cuss at him and resort to personal attacks yourself? Grow up.
Had to stop the video at 22:55 . Have no limits on this stuff in fictional media, but not much tolerance for it IRL and certainly no room for it in my professional life..
I would argue that “well-designed” should also include a rule “the last style is the one that gets applied”.
ironically you come off more bad faith and biased than that article guy
Glad someone else has seen it
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
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.
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
Components are great. If I look at the tailwind classes I know immediately what to change 99% of the time.
Laravel has template components that are basically "server components". It's static HTML but you can reuse markup and UI logic
Well, i kinda have a strange relationship with tailwind.
I HATE those types of elements with 15-20 classes on them (that's not even a joke, that's default when you work with tailwind).
It makes the code of components unreadable, a big part of your component is now just css classes. Also i like it more when css is in a separate file, makes it way more manageable.
But i also like concise aliases of tailwind. So i use tailwind by still naming classes in a component using bem methodology and @apply in css files. Although tailwind is not recommending this approach - i find it best for me. Css files become more readable than default css, they have fewer lines in them, and i don't have my components clogged with tailwind classes.
And maybe it's just for me, but it's way easier to debug css like that - i know exact name of the node provided by human readable css class, it's easy to find it in debugger and editor
I kind like your approach, but I like to have smaller CSS files for big SSR projects and use @apply is kind of using normal CSS with convention
Anyway I will keep experimenting things
Pretty sure you can use import with CSS now. Otherwise look into css.modules if you haven't already
@@andreilucasgoncalves1416 i also like this approach. I think there is something to search between Tailwind (css purge and utility for some specific needs), Bootstrap (components : dropdowns, modals, sliders etc... each one in the same file or the same folder as the component's one) and Scss (advanced configurability and opened to whatever system you need).
I feel like these people are just mad that they don't understand something that so many other people love.
Not wanting to use something is fine, but you can't just deny the value that it provides to other people.
Bootstrap existed long before TWCSS, and does essentially the same thing.
@@TravisHi_YT bootstrap and tailwind are completely different. The only thing they share is that they both use CSS
My problem with tailwind is that the developers are not creating components
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?
The thing I don't like about tailwind is the lack of abstractions. You can create custom classes but people seldom do it. The way tailwind is used on projects I worked on is just a lazy way to write inline styles.
As a designer, I care about the brand and the style guide. These are business rules and I can model them with CSS.
I agree semantic (content) class names are bad for components (duh), but there are steps between this and inline styles with zero abstraction
If you're talking about colors and fonts and such, can't you define them in Tailwind components?
@@CodecrafterArtemisI am talking about meaningful reusable and parameterized styles and about cohesion and coupling. Typically, when you have inline media queries spread everywhere it is no longer possible to reason about different layouts for different sizes because you can't even read a cohesive set of rules, or when you move one component at a different spot and there should no longer be this or that contextual style on it (like a bigger margin because it follows an image or whatnot) there is nothing in the code reminding you to remove that style.
From what I have seen, and I would love to be wrong, Tailwind inline classes kill any attempt at creating higher level abstractions, they are simply shorthand ways of writing inline styles.
The points made in the video (I didn't watch it till the end) are not invalid to me, but they are no excuse for mindlessly peppering inline styles everywhere. When I talk to other devs about it they just say "I like it, it's fast". It's fast to make a mess, but then when you ask the former designer (myself) to fix inconsistent styling in their code, I can see no rule, no pattern, and it feels like a time machine brought me back 15 years ago.
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.
I haven't used Tailwind yet because none of the projects I've been working on have used newer CSS, but this video really helped make it seem VERY smart and reasonable compared with maintaining "semantic" classes which constantly become out of date.
I recall learning about scoped styles when I first learned VueJS - it felt different but immediately it was apparent how much of a benefit there was in keeping your styles co-located closely with your component. Whole article seemed like nonsense about halfway through. Thanks for the laughs Theo.
Look into css modules.
The author isn’t delusional IMO … I think he has an agenda.
There’s definitely a right place and a wrong place for Tailwind, just like with other ish
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.)
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
Wow, so much COPIUM in this video... Theo loves Tailwind soo much that's he's unable to look objectively at the arguments in this article.
Yes it's a bit painful at times. Lot's of bad faith on both sides
Theo completely loses a point at the moment of the video where he asks “How the html button differs from component”?
The problem arises when you actually need to style some other element AS a button without actually using a button tag (navigation link, select trigger, whatever else). That’s where the nonsense like comes from. I would say that having a JS component is actually killing the purpose of Tailwind in the first place here.
I usually implement reusable components at the Tailwind configuration level, with a custom plugin which configures a button component class within the addComponents utility. This way I can still get the benefits of Tailwind (like autocomplete, style purging, etc) but now and will have the same appearance but could do totally different things
Even more than that, since Tailwind is framework-agnostic, I can just copy its config from React project into Astro or Svelte and still have exactly the same UI for my html which makes this approach infinitely more reusable than just an incapsulated React Button
Browser ui: Largely moved to component based
Mobile: Ditto
Desktop: getting there
Server side: yup, very commonly used
This means that dozens to hundreds of vendors across different devices, languages and ecosystems have moved there after all independently verifying the benefits but it’s a fad apparently.
Angular 1 and React were a fork in the road towards the then HTML/CSS orthogonal concern’s approach and the industry as a whole has pretty resounding chosen data-driven, declarative components.
This guy sounds like those people that cried “Apple has betrayed me!” When Swift was released. Clearly a recipe-oriented thinker. Yet another ever-junior confusing tenure with experience.
It isn't component based though, TWCSS is still CSS.
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.
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 💙.
I still think that tailwind is useless, and is just the successor of bootstrap. With css modules or a system like the one implemented in svelte i really see only downsides in using tailwind.
Have you ever used it?