I've worked with both for years at this point. Imo they each have their sweet spot depending on what kind of page you are building.
Bootstrap is a huge time-saver when you are mostly fine with the defaults it ships. Extending it means writing a CSS file, which brings up the ancient problem of "gosh dang what's again all the places where this class/subselector is used?". Even changing colors is usually a trial and error effort, because different components use different variables as their basis. If you ever were to change font sizes, you will quickly notice that paddings etc. also need adjustment, so it's not as trivial as one might assume.
Tailwind's pain & gain come from the other direction: It's super easy to have every element look the way you want, but you also have to specify it for every element, which means high chances of missing something resulting in inconsistent appearance. It's not enough that I can abstract out the <Button> component, because the font size and line spacing must be visually(!) consistent with the <Select>, so those two are semantically linked together, but tooling can't help me reliably with ensuring that. Tailwind is, in comparison to CSS also way more limited in what can be expressed. Take something like this as an example of what is not expressible in tailwind:
Tailwind is better when you actually try to put the utility classes in your own components, sure. But the reason Tailwind got popular over Bootstrap in the last 5 years is because people got sick of hand-tweaking Bootstrap components and fighting it to do so when they can only run basic CSS sticks together.
(I'm aware modern CSS is really good even on its own, and most of us under-utilise it. But I think it has become clear that most people just don't want to learn it)
When I see people use Tailwind they are adding a dozen classes to something to do what a single class in Bootstrap does.
On a component that only needs to be defined once, no big deal. But if you need to add this collection of classes on 20 elements, adding a bunch of Tailwind sounds messy and error prone.
Tweaking Bootstrap here and there sounds a lot better than using 100% tweaks. Tailwind seems like a tweak library. Add 10 tweaks to each element and you start to have a design on your hands. I often question why it exists vs raw CSS.
Which leads us to: Tailwind supports making your own components, and encourages it. But devs, either pressed for time or lazy, or by always getting a slightly too unique design from their design team, don't do it.
At the same time, not everything is a reusable component, so yeah, shove a couple dozen tailwind classes there and call it a day. Still better and less messy than hand-wringing custom selectors or custom element styling - else Bootstrap would be better for tweaking than "100% tweaks".
It's the usual OOP debate on inheritance vs composition.
Tailwind is composition, and it's clearly the favoured approach.
Fine I’ll chime in… The main advantage tailwind has is that utility css can be composed without needing to worry about hierarchy. This is not true for bootstrap.
This makes tailwind much more predictable for component based UI architecture, in your example you would define a <Button> component so that verbosity of css is explicitly defined once where it’s used, not buried within a bootstrap framework somewhere.
If you’re not using a component based architecture, then tailwind is much more verbose, but still useful, as copying/pasting tailwind HTML is insanely easy and reliable. This is not true for bootstrap.
Bootstrap has it’s place, it’s good for cases where you’ I don’t care about the details of how it looks. But with component based architectures, tailwind is a much more flexible and better abstraction in my opinion.
Your postscript explains why: using the same "btn-primary" as every other user of the framework hints that you're not building something with its own visual identity.
For the rest of us, we throw that "bg-sky-500 hover:bg-sky-600 active:bg-sky-700 text-white px-4 py-2 rounded-lg" (or whatever color and shape matches our brand) into a component with a variant=primary property and call it a day. What developers actually see on a day-to-day basis is <Button variant="primary" />.
> Your postscript explains why: using the same "btn-primary" as every other user of the framework hints that you're not building something with its own visual identity.
You know that bootstrap is trivial to customise right?
It turns out identifying primary and secondary buttons is a pretty standard thing in any kind of UI that has... buttons.
TailwindCSS is useful for applying styles to isolated components, in paper-shredder scenarios. Devs using it get to ignore the cascade, don't have to name things, and can use the predefined spacing and colors.
It is of course quite unmaintainable (good luck with updating the class soup for a bunch of components across a project).
I personally just ... cannot. CSS in 2026 is incredibly powerful and beautiful. Embracing the cascade allows for minimal CSS (see ITCSS methodology). Standardizing spacing and type with https://utopia.fyi is brilliant. Standardizing colors with custom props is trivial.
But, it seems that a lot of people are not paid to think about CSS. Tailwind embraces that. LLMs love it, because it reduces the complexity of pure CSS.
- If you just paste an outerHTML from the dev tools, AI coding agents can immediately figure out what it will look like; debug styles; etc.
I personally preferred PicoCSS for a long time. Pico was nice, but it injected a lot of CSS var noise into the dev tools and I started fighting with the breakpoints.
More recently, I've been just doing handcrafted CSS with a bit of OpenProps.
I wouldn’t put them in the same category. Bootstrap has a much stronger opinion about how you write and structure CSS, while Tailwind is a framework for building a style system and writing arbitrary CSS that conforms to it. In practice, Tailwind is actually much closer to writing vanilla CSS. It does come with a widely used default (and very good, IMO) style system, but you ultimately apply arbitrary CSS rules just like vanilla.
Tailwind is certainly divisive. It’s better suited to component-based frameworks than templates or plain HTML, so a person’s background likely contributes to how they perceive it. Personally, I’ve worked a lot with vanilla CSS, opinionated libraries like Bootstrap, and Tailwind, and opinionated libraries are the only one I have no desire to use again. I generally want Tailwind in component-based projects and vanilla CSS in template-based projects.
At the end of the day, pick what you like and use it. They all get the job done.
What fresh fucking hell is this? I can't say I've had the (mis)fortune of being forced to work with Tailwind (I've seen the name enough to know it's something vaguely "CSS framework"-adjacent though).
Seriously, though what kind of crack induced nightmare state was required for someone to think up such an abomination, implement it, and then make it public for the world to see?
Furthermore, who in their right mind saw that and said "yep this is fine"?
Not a tailwind geek myself but I think how they justify is "better to have a little extra spaghetti in your html code than create a truck load of spaghetti in your app.css stylesheet."
The alternative to using tailwind here is to define the specific style elements for each one in the css stylesheets yourself with something like this:
.bg-sky-500 {
background-color: blue;
}
Tailwind proponents argue that they avoid this "stylesheet hell" by picking ready pre-defined tailwind classes like bg-sky-500, etc. Plus they also argue that this workflow will increase productivity by standardizing "style mindsets" of your dev team who all will think "blue" means "sky-500" (for example).
Maybe it has use cases in deep or professional design work but for most backend or full-stack devs, bootstrap is definitely better than meddling with this structure.
Once you learn how to read it, it's actually pretty clear.
This element has a small amount of x and y padding that is suitable for (for example) keeping text away from the edge of the container. The text is white. The corners of this are rounded.
The background is the default intensity 'sky' colour, which darkens slightly on hover and darkens further when it's active.
You can take this from 77 characters to 189 like this:
Tailwind simplifies consistency, and frankly is pretty readable. It's not like <button type="button" class="button">Button</button> is exactly the pinnacle of human clarity and simplicity in the first place.
Of course there are other ways to do it, but this faux outrage demonstrates not that this is some 'fresh fucking hell' or some 'crack induced nightmare', but rather that you simply don't get it.
I didn't say I can't read it. I asked who thought it was a good fucking idea. I guess you've answered that implicitly.
Embedding every style directly into the style attribute is also readable, and as a side benefit it doesn't need a build step just to make your styles actually work.
I can now see exactly why OP made this post. If a client told me they don't want to use something akin to bootstrap or any other sane css library, and that instead I will need to ensure that every element has every manner of css states expressed as a faux class, I wouldn't even stop to make a coffee before telling them how far they can jump.
This sounds perfect for front end “developers" who struggle even with css, and want any reason possible to pad out their billable/working hours doing nothing productive.
Oh what's that, you want to change the style of standard button everywhere in the codebase?
No of course we can't just update a single css file you silly goose.
I feel like half the bad problems in web development are because JavaScript developers saw that j2ee guys had ant and whatnot, and said "hey what if we started inventing reasons to have a build step"?
> button class="button"
The thing is, that is more readable for a sane code base. If I can glance and know it's using the correct standard button class, it means I don't need to memorise the fucking pixel sizes and states of button paddings.
I get it alright. It's a solution looking for a problem that doesn't exist, and instead found a crowd of "developers" looking for anything shiny to pad their resume and keep themselves looking busy.
> Embedding every style directly into the style attribute is also readable, and as a side benefit it doesn't need a build step just to make your styles actually work.
Critical difference: media queries are unavailable to inline styles, making impossible to implement responsive designs this way. And anyway, CSS is so much more verbose than Tailwind that it really wouldn’t be very readable outside of toy examples.
Personally, I have used CSS since it was first created. I also have used Bootstrap and Foundation, but found them brittle and cumbersome. Now I just write 95% of styles with Tailwind.
Which everyone says is only really useful if you use in a JSX Component...
So you're writing it in XML...
But then that gets converted into JavaScript....
Which then writes out some HTML and CSS?
I will absolutely not be surprised when someone declares that the XML part of JSX is too verbose and creates a library to generate the JSX code. Fuck it who am I kidding, it probably already exists doesn't it?
100% with you on this, know you’re not the only one bewildered by the insanity of ignoring the cascade, styling everything from scratch, and placing it all in a list of classes.
Clearly you’ve made your mind up so I won’t push harder, except one point:
> Oh what's that, you want to change the style of standard button everywhere in the codebase?
Tailwind excels when you are using component based frameworks. This change should be at least as simple as updating main.css, except it’s in Button.tsx
I think these debates ultimately come down to what you’re making with these tools: is it documents or application interfaces? If it’s documents, then plain HTML, CSS and a touch of JS sprinkles on top works very well, as they were designed for this. If you’re making software, though, at some point you’re going to need some additional tooling to make it feasible.
> at some point you’re going to need some additional tooling to make it feasible.
I mean sure, most people will pick some kind of abstraction over parsing and constructing raw HTTP messages.
But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`.
Like I said earlier: so much of the folly in the NodeJS community looks like bizarre adoration of early-2000s J2EE stack.
You have a language that requires no AOT.. ah better invent increasingly convoluted and ever-changing build processes for it.
You're writing output that's essentially just a string to be sent over the wire... ah better create a wrapper for the wrapper that creates the service which renders the string.
But sure. That is totally a rational approach to development, and the nodejs community has never shown itself to be prone to chasing shiny useless things or cargo culting. I must just be overreacting.
> But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`.
I'm wondering if some of the disconnect here is that you don't have personal experience with this type of development, so you might not see what pain points it solves.
The first thing I would mention is that components encapsulate function and styling. Buttons don't illustrate this well because they're trivial. But you can imagine a `<DatePicker>` that takes a `variant` property ("range" or "single"), `month` and `year` properties, and perhaps a property called `annotations` which accepts an array of special dates and their categories (`[{date: "2026-07-04", code: "premium_rate"}, {date: "2027-07-07", code: "sold_out"} ...]`). The end result is an interactive picker that shows the desired span, with certain dates unselectable and others marked with special color codes or symbols. You're going to have a very unpleasant time implementing that with globally scoped CSS classes.
And this isn't a string sent over the wire. The "document" that the browser renders is changing continuously as you interact with it. If you were to open Chrome Devtools and look at the subtree of the DOM containing the date picker, you would see elements appearing and disappearing, gaining or losing classes and attributes, in real time as you select/deselect/skip forward/etc. That's what makes it work, rather than being a static drawing of a calendar.
I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? Sometimes we just have to do weird things because they're really useful.
> I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers?
One way is what I call the "Modular MVC pattern" that involves pure js routing and manual DOM manipulation without using any framework at all. You handle complexity in two ways: by modularizing the "controller" parts into multiple js modules for each route, and "view" parts into multiple HTML partials - and using the event bus pattern if your app gets too complex (as alternative to modern reactive frameworks like react/vue).
Shameless plug: I've tried to implement this exact pattern with limited success in Abhyasa Quiz App[1], a side project.
> you don't have personal experience with this type of development, so you might not see what pain points it solves.
That all depends what you mean by "this type of development".
Do you mean development targeting a browser? Do you mean development targeting client-side interaction in a browser? Or do you mean writing JSX/React/Whatever flavour of the week is hip with the NodeJS community?
If you meant either of the first two: I have about 20 years experience.
If you meant the last: No. If I wanted to be a masochist that badly I'd buy my wife a leather whip and a strap on.
As much as I generally avoid front-end dev when I can now, at one point it was a much greater part of my work. I've written modular/resuable client-side libraries/widgets (i.e. self-contained elements that other developers then used in their own separate projects to add functionality... you know, a "component" by another name) since IE6 was not just in-use, but current and popular. So to rebut your claim: I'm well aware of the "pain points" developing code like this for re-use.
> You're going to have a very unpleasant time implementing that with globally scoped CSS classes.
Have you ever used CSS or Bootstrap before? You know that bootstrap is meant to be a starting point for your codebase, right? Even the most bare-bones official Bootstrap "example" designs use custom CSS specific to that use-case. If you're trying to create anything beyond the most basic hello world page with nothing but bootstrap classes on your markup, you're doing it wrong.
If your argument for using Tailwind (and apparently by necessity, JSX components) is to avoid having someone write a handful of CSS rules specific to the widget you're creating, I can't help you mate.
> It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? Sometimes we just have to do weird things because they're really useful.
My argument isn't against using Javascript for interactivity on webpages/webapps. As I said, I've been doing it for a couple of decades now. I have my issues with JS, but for browser interaction it's mostly fine.
You see the "current ecosystem" the NodeJS/Javascript community has created, complain about it being "hacks upon hacks" and then still defend the batshit crazy stuff when someone calls it out.
I see the batshit crazy stuff and just ignore it. Just because something new exists, doesn't mean you have to use it. The browser environment for JS is slowly improving, gaining native abilities that we once had implement in libraries or from scratch.... and the majority of the JS-focussed community seems to continue to be obsessed with adding more and more and more layers of abstraction.
If you told 20-year-ago me that the browsers would all supported a native way to implement custom elements (i.e. Web Components) that can be initiated using regular markup in the page, it would never once have occurred to me that the JS developers of the day would then find some way to not just use the built-in capabilities and instead have a dependency chain and build system so complex there are fucking memes about it.
Why would you want to have to maintain a separate file instead of keeping it all in the same place?
Preference I guess. I’m not bashing anyone who prefers writing CSS that way. But there are a lot of people who think it’s very important to share that they don’t like how Tailwind looks.
Personally, I'm on team bootstrap. But, yes, it is subjective.
After working on several projects, I've come to realized that (atleast for me), ready-made UI kits/componenets are more important that the framework itself.
Same, it feels like Bootstrap but much, much more customizable. When I'm not using ShadCN that's what I reach for by default, it's been much nicer to work with, personally.
I've worked with both for years at this point. Imo they each have their sweet spot depending on what kind of page you are building.
Bootstrap is a huge time-saver when you are mostly fine with the defaults it ships. Extending it means writing a CSS file, which brings up the ancient problem of "gosh dang what's again all the places where this class/subselector is used?". Even changing colors is usually a trial and error effort, because different components use different variables as their basis. If you ever were to change font sizes, you will quickly notice that paddings etc. also need adjustment, so it's not as trivial as one might assume.
Tailwind's pain & gain come from the other direction: It's super easy to have every element look the way you want, but you also have to specify it for every element, which means high chances of missing something resulting in inconsistent appearance. It's not enough that I can abstract out the <Button> component, because the font size and line spacing must be visually(!) consistent with the <Select>, so those two are semantically linked together, but tooling can't help me reliably with ensuring that. Tailwind is, in comparison to CSS also way more limited in what can be expressed. Take something like this as an example of what is not expressible in tailwind:
``` .component { .listitem { p { color: red; } } .listitem.special { p { color: blue; } } } ```
It seems like Tailwind only makes sense when dealing with components. For more traditional web dev, Bootstrap makes much more sense to me.
errr, this sounds backwards, no?
Tailwind is better when you actually try to put the utility classes in your own components, sure. But the reason Tailwind got popular over Bootstrap in the last 5 years is because people got sick of hand-tweaking Bootstrap components and fighting it to do so when they can only run basic CSS sticks together.
(I'm aware modern CSS is really good even on its own, and most of us under-utilise it. But I think it has become clear that most people just don't want to learn it)
When I see people use Tailwind they are adding a dozen classes to something to do what a single class in Bootstrap does.
On a component that only needs to be defined once, no big deal. But if you need to add this collection of classes on 20 elements, adding a bunch of Tailwind sounds messy and error prone.
Tweaking Bootstrap here and there sounds a lot better than using 100% tweaks. Tailwind seems like a tweak library. Add 10 tweaks to each element and you start to have a design on your hands. I often question why it exists vs raw CSS.
Which leads us to: Tailwind supports making your own components, and encourages it. But devs, either pressed for time or lazy, or by always getting a slightly too unique design from their design team, don't do it.
At the same time, not everything is a reusable component, so yeah, shove a couple dozen tailwind classes there and call it a day. Still better and less messy than hand-wringing custom selectors or custom element styling - else Bootstrap would be better for tweaking than "100% tweaks".
It's the usual OOP debate on inheritance vs composition.
Tailwind is composition, and it's clearly the favoured approach.
Fine I’ll chime in… The main advantage tailwind has is that utility css can be composed without needing to worry about hierarchy. This is not true for bootstrap.
This makes tailwind much more predictable for component based UI architecture, in your example you would define a <Button> component so that verbosity of css is explicitly defined once where it’s used, not buried within a bootstrap framework somewhere.
If you’re not using a component based architecture, then tailwind is much more verbose, but still useful, as copying/pasting tailwind HTML is insanely easy and reliable. This is not true for bootstrap.
Bootstrap has it’s place, it’s good for cases where you’ I don’t care about the details of how it looks. But with component based architectures, tailwind is a much more flexible and better abstraction in my opinion.
Sure Bootstrap is better, for you.
Your postscript explains why: using the same "btn-primary" as every other user of the framework hints that you're not building something with its own visual identity.
For the rest of us, we throw that "bg-sky-500 hover:bg-sky-600 active:bg-sky-700 text-white px-4 py-2 rounded-lg" (or whatever color and shape matches our brand) into a component with a variant=primary property and call it a day. What developers actually see on a day-to-day basis is <Button variant="primary" />.
> Your postscript explains why: using the same "btn-primary" as every other user of the framework hints that you're not building something with its own visual identity.
You know that bootstrap is trivial to customise right?
It turns out identifying primary and secondary buttons is a pretty standard thing in any kind of UI that has... buttons.
Cant you just customize the css of btn-primary?
oof, that looks like absolute trash. i don't get why you want to use something less readable than css but to each their own i guess
TailwindCSS is useful for applying styles to isolated components, in paper-shredder scenarios. Devs using it get to ignore the cascade, don't have to name things, and can use the predefined spacing and colors.
It is of course quite unmaintainable (good luck with updating the class soup for a bunch of components across a project).
I personally just ... cannot. CSS in 2026 is incredibly powerful and beautiful. Embracing the cascade allows for minimal CSS (see ITCSS methodology). Standardizing spacing and type with https://utopia.fyi is brilliant. Standardizing colors with custom props is trivial.
But, it seems that a lot of people are not paid to think about CSS. Tailwind embraces that. LLMs love it, because it reduces the complexity of pure CSS.
One advantage I've noticed for Tailwind:
- If you just paste an outerHTML from the dev tools, AI coding agents can immediately figure out what it will look like; debug styles; etc.
I personally preferred PicoCSS for a long time. Pico was nice, but it injected a lot of CSS var noise into the dev tools and I started fighting with the breakpoints.
More recently, I've been just doing handcrafted CSS with a bit of OpenProps.
I wouldn’t put them in the same category. Bootstrap has a much stronger opinion about how you write and structure CSS, while Tailwind is a framework for building a style system and writing arbitrary CSS that conforms to it. In practice, Tailwind is actually much closer to writing vanilla CSS. It does come with a widely used default (and very good, IMO) style system, but you ultimately apply arbitrary CSS rules just like vanilla.
Tailwind is certainly divisive. It’s better suited to component-based frameworks than templates or plain HTML, so a person’s background likely contributes to how they perceive it. Personally, I’ve worked a lot with vanilla CSS, opinionated libraries like Bootstrap, and Tailwind, and opinionated libraries are the only one I have no desire to use again. I generally want Tailwind in component-based projects and vanilla CSS in template-based projects.
At the end of the day, pick what you like and use it. They all get the job done.
Better is subjective, but I will say:
Bootstrap seems to create less CSS soup, but more HTML soup. And Tailwind vice versa.
For an admin panel or something back office, I agree that Bootstrap seems simpler.
But for something user facing and working with a designer? Tailwind is easier to customise.
> bg-sky-500 hover:bg-sky-600 active:bg-sky-700 text-white px-4 py-2 rounded-lg
What fresh fucking hell is this? I can't say I've had the (mis)fortune of being forced to work with Tailwind (I've seen the name enough to know it's something vaguely "CSS framework"-adjacent though).
Seriously, though what kind of crack induced nightmare state was required for someone to think up such an abomination, implement it, and then make it public for the world to see?
Furthermore, who in their right mind saw that and said "yep this is fine"?
Not a tailwind geek myself but I think how they justify is "better to have a little extra spaghetti in your html code than create a truck load of spaghetti in your app.css stylesheet."
The alternative to using tailwind here is to define the specific style elements for each one in the css stylesheets yourself with something like this:
.bg-sky-500 { background-color: blue; }
Tailwind proponents argue that they avoid this "stylesheet hell" by picking ready pre-defined tailwind classes like bg-sky-500, etc. Plus they also argue that this workflow will increase productivity by standardizing "style mindsets" of your dev team who all will think "blue" means "sky-500" (for example).
Maybe it has use cases in deep or professional design work but for most backend or full-stack devs, bootstrap is definitely better than meddling with this structure.
Once you learn how to read it, it's actually pretty clear.
This element has a small amount of x and y padding that is suitable for (for example) keeping text away from the edge of the container. The text is white. The corners of this are rounded.
The background is the default intensity 'sky' colour, which darkens slightly on hover and darkens further when it's active.
You can take this from 77 characters to 189 like this:
Tailwind simplifies consistency, and frankly is pretty readable. It's not like <button type="button" class="button">Button</button> is exactly the pinnacle of human clarity and simplicity in the first place.Of course there are other ways to do it, but this faux outrage demonstrates not that this is some 'fresh fucking hell' or some 'crack induced nightmare', but rather that you simply don't get it.
I didn't say I can't read it. I asked who thought it was a good fucking idea. I guess you've answered that implicitly.
Embedding every style directly into the style attribute is also readable, and as a side benefit it doesn't need a build step just to make your styles actually work.
I can now see exactly why OP made this post. If a client told me they don't want to use something akin to bootstrap or any other sane css library, and that instead I will need to ensure that every element has every manner of css states expressed as a faux class, I wouldn't even stop to make a coffee before telling them how far they can jump.
This sounds perfect for front end “developers" who struggle even with css, and want any reason possible to pad out their billable/working hours doing nothing productive.
Oh what's that, you want to change the style of standard button everywhere in the codebase?
No of course we can't just update a single css file you silly goose.
I feel like half the bad problems in web development are because JavaScript developers saw that j2ee guys had ant and whatnot, and said "hey what if we started inventing reasons to have a build step"?
> button class="button"
The thing is, that is more readable for a sane code base. If I can glance and know it's using the correct standard button class, it means I don't need to memorise the fucking pixel sizes and states of button paddings.
I get it alright. It's a solution looking for a problem that doesn't exist, and instead found a crowd of "developers" looking for anything shiny to pad their resume and keep themselves looking busy.
> Embedding every style directly into the style attribute is also readable, and as a side benefit it doesn't need a build step just to make your styles actually work.
Critical difference: media queries are unavailable to inline styles, making impossible to implement responsive designs this way. And anyway, CSS is so much more verbose than Tailwind that it really wouldn’t be very readable outside of toy examples.
Personally, I have used CSS since it was first created. I also have used Bootstrap and Foundation, but found them brittle and cumbersome. Now I just write 95% of styles with Tailwind.
> Critical difference
Yeah that's the critical difference, absolutely.
> Now I just write 95% of styles with Tailwind.
Which everyone says is only really useful if you use in a JSX Component...
So you're writing it in XML...
But then that gets converted into JavaScript....
Which then writes out some HTML and CSS?
I will absolutely not be surprised when someone declares that the XML part of JSX is too verbose and creates a library to generate the JSX code. Fuck it who am I kidding, it probably already exists doesn't it?
100% with you on this, know you’re not the only one bewildered by the insanity of ignoring the cascade, styling everything from scratch, and placing it all in a list of classes.
Clearly you’ve made your mind up so I won’t push harder, except one point:
> Oh what's that, you want to change the style of standard button everywhere in the codebase?
Tailwind excels when you are using component based frameworks. This change should be at least as simple as updating main.css, except it’s in Button.tsx
Why am I not surprised this rube Goldberg style machine seems like a rational thing to people who write xml to generate JavaScript to generate html.
I think these debates ultimately come down to what you’re making with these tools: is it documents or application interfaces? If it’s documents, then plain HTML, CSS and a touch of JS sprinkles on top works very well, as they were designed for this. If you’re making software, though, at some point you’re going to need some additional tooling to make it feasible.
> at some point you’re going to need some additional tooling to make it feasible.
I mean sure, most people will pick some kind of abstraction over parsing and constructing raw HTTP messages.
But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`.
Like I said earlier: so much of the folly in the NodeJS community looks like bizarre adoration of early-2000s J2EE stack.
You have a language that requires no AOT.. ah better invent increasingly convoluted and ever-changing build processes for it.
You're writing output that's essentially just a string to be sent over the wire... ah better create a wrapper for the wrapper that creates the service which renders the string.
But sure. That is totally a rational approach to development, and the nodejs community has never shown itself to be prone to chasing shiny useless things or cargo culting. I must just be overreacting.
> But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`.
I'm wondering if some of the disconnect here is that you don't have personal experience with this type of development, so you might not see what pain points it solves.
The first thing I would mention is that components encapsulate function and styling. Buttons don't illustrate this well because they're trivial. But you can imagine a `<DatePicker>` that takes a `variant` property ("range" or "single"), `month` and `year` properties, and perhaps a property called `annotations` which accepts an array of special dates and their categories (`[{date: "2026-07-04", code: "premium_rate"}, {date: "2027-07-07", code: "sold_out"} ...]`). The end result is an interactive picker that shows the desired span, with certain dates unselectable and others marked with special color codes or symbols. You're going to have a very unpleasant time implementing that with globally scoped CSS classes.
And this isn't a string sent over the wire. The "document" that the browser renders is changing continuously as you interact with it. If you were to open Chrome Devtools and look at the subtree of the DOM containing the date picker, you would see elements appearing and disappearing, gaining or losing classes and attributes, in real time as you select/deselect/skip forward/etc. That's what makes it work, rather than being a static drawing of a calendar.
I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? Sometimes we just have to do weird things because they're really useful.
> I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers?
One way is what I call the "Modular MVC pattern" that involves pure js routing and manual DOM manipulation without using any framework at all. You handle complexity in two ways: by modularizing the "controller" parts into multiple js modules for each route, and "view" parts into multiple HTML partials - and using the event bus pattern if your app gets too complex (as alternative to modern reactive frameworks like react/vue).
Shameless plug: I've tried to implement this exact pattern with limited success in Abhyasa Quiz App[1], a side project.
[1]: https://abhyasa.pages.dev/
> you don't have personal experience with this type of development, so you might not see what pain points it solves.
That all depends what you mean by "this type of development".
Do you mean development targeting a browser? Do you mean development targeting client-side interaction in a browser? Or do you mean writing JSX/React/Whatever flavour of the week is hip with the NodeJS community?
If you meant either of the first two: I have about 20 years experience.
If you meant the last: No. If I wanted to be a masochist that badly I'd buy my wife a leather whip and a strap on.
As much as I generally avoid front-end dev when I can now, at one point it was a much greater part of my work. I've written modular/resuable client-side libraries/widgets (i.e. self-contained elements that other developers then used in their own separate projects to add functionality... you know, a "component" by another name) since IE6 was not just in-use, but current and popular. So to rebut your claim: I'm well aware of the "pain points" developing code like this for re-use.
> You're going to have a very unpleasant time implementing that with globally scoped CSS classes.
Have you ever used CSS or Bootstrap before? You know that bootstrap is meant to be a starting point for your codebase, right? Even the most bare-bones official Bootstrap "example" designs use custom CSS specific to that use-case. If you're trying to create anything beyond the most basic hello world page with nothing but bootstrap classes on your markup, you're doing it wrong.
If your argument for using Tailwind (and apparently by necessity, JSX components) is to avoid having someone write a handful of CSS rules specific to the widget you're creating, I can't help you mate.
> It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? Sometimes we just have to do weird things because they're really useful.
My argument isn't against using Javascript for interactivity on webpages/webapps. As I said, I've been doing it for a couple of decades now. I have my issues with JS, but for browser interaction it's mostly fine.
You see the "current ecosystem" the NodeJS/Javascript community has created, complain about it being "hacks upon hacks" and then still defend the batshit crazy stuff when someone calls it out.
I see the batshit crazy stuff and just ignore it. Just because something new exists, doesn't mean you have to use it. The browser environment for JS is slowly improving, gaining native abilities that we once had implement in libraries or from scratch.... and the majority of the JS-focussed community seems to continue to be obsessed with adding more and more and more layers of abstraction.
If you told 20-year-ago me that the browsers would all supported a native way to implement custom elements (i.e. Web Components) that can be initiated using regular markup in the page, it would never once have occurred to me that the JS developers of the day would then find some way to not just use the built-in capabilities and instead have a dependency chain and build system so complex there are fucking memes about it.
Why would you want all that into the html, instrad of defining it in css?
Why would you want to have to maintain a separate file instead of keeping it all in the same place?
Preference I guess. I’m not bashing anyone who prefers writing CSS that way. But there are a lot of people who think it’s very important to share that they don’t like how Tailwind looks.
It’s an argument that’s been pretty roundly responded to here: https://tailwindcss.com/docs/styling-with-utility-classes
> Why would you want to have to maintain a separate file instead of keeping it all in the same place?
The year 2001 called and is demanding royalties for copyright infringement on "How to write your first dynamic page in PHP - just one file needed".
They also want their “year X called” joke back.
Personally, I'm on team bootstrap. But, yes, it is subjective.
After working on several projects, I've come to realized that (atleast for me), ready-made UI kits/componenets are more important that the framework itself.
AI just generates all this. The true take is that this argument all together is obsolete, you shouldnt even be writing tailwind by hand anymore
This gets argued every week. It doesn't matter as long as you like what you like.
Thats what tailwind component libraries like daisyui are for
I like daisyui.
Same, it feels like Bootstrap but much, much more customizable. When I'm not using ShadCN that's what I reach for by default, it's been much nicer to work with, personally.