I don't think so. I mean, this is not hiding tailwind behind custom classes or React components or anything, these are literally examples of tailwind usage using tailwind features. So, less of a component library and more of a nice collection of tailwind examples. I think it's a nice way of build the basic structure of your site and then you can change whatever you need.
Not really, in my opinion. I was happily surprised to see that this "component library" doesn't actually offer anything to download; it's not a library you can `npm i` to your website. It is basically a set of examples for how to recreate different design elements using Tailwind. It leaves it to you to decide what parts to use and what part to change or remove. Pretty neat.
Tailwind is not, in fact, written in SASS (also, for what it's worth it's Sass - not SASS) - it's a PostCSS plugin. Additionally, the primary use case of Bourbon was to create composable mixins - not to expose utility classes. It would only be comparable to Tailwind if you were using Tailwind's @apply rules and not composing with the utility classes directly in the DOM.
The bottom line is Tailwind is not a component library so this doesn't defeat the purpose of Tailwind any more than it would defeat the purpose of StyledComponents.
Actually Tailwind is the antithesis to BEM, so it's funny how you wouldn't compare them.
The BEM philosophy is to capture individual pieces of your UI as unique CSS classes (.Button, .Button-icon, Button-text). The "utility first" approach removes that abstraction entirely.
Anecdotally I've built hundreds of websites, and worked on many product teams building web applications all with varying team/product sizes and in my experience BEM scales very poorly. I have never worked on a BEM codebase without a shocking level amount of tech debt. Adding new UI requires creating new CSS files, refactoring existing UI requires also refactoring the separate CSS files, removing UI is the same thing. Due to this disconnect, old code tends to stick around.
One of my product teams moved from BEM to Tailwind and productivity/maintainability improved tremendously.
Adding new UI requires creating new CSS files, refactoring existing UI requires also refactoring the separate CSS files, removing UI is the same thing. Due to this disconnect, old code tends to stick around.
To me this says more about the development practices of that team than about BEM. Chiefly you should be able to automatically determine if a given block, element or modifier is still used/needed. How did they wind up in such a situation?
Meanwhile Tailwind is functionally equivalent to this:
I would say that this is nice for prototypes, but given how it disincentivises reuse, refactors take an amount of time proportional to the number of instances - that's really bad.
Also since there's no composition, just by looking at the codebase it's not clear if a change is something that should propagate to other, similar instances or land only there.