Comparing Modern CSS Solutions (Tailwind vs MUI vs Bootstrap vs Chakra vs...)

Summary

A passionate and thought-provoking exploration of the role of UI libraries and frameworks in web development. The speaker delves into the benefits of Tailwind CSS and how it revolutionized their approach to building user interfaces. They contrast Tailwind with other popular solutions like Material UI, styled-components, and Chakra UI, highlighting the unique advantages of Tailwind's CSS utility-first approach. The discussion touches on topics such as design flexibility, developer experience, and the importance of prioritizing user experience over reliance on opinionated libraries. With a mix of insightful analysis and personal anecdotes, this video offers a fresh perspective on the challenges and opportunities in crafting exceptional web applications.

Takeaways

• 🌐 The speaker categorizes UI libraries/frameworks into three main types: CSS extensions (like Sass, Less, Tailwind), behavior libraries (like Headless UI, Radix UI), and style systems (like Bootstrap, Material UI).
• 🎨 The speaker strongly advocates for using Tailwind CSS as it gives developers more control over styling, is easy to use, and doesn't impose a ceiling on design quality like other UI libraries.
• 🚫 The speaker argues against using opinionated UI libraries like Material UI or Bootstrap as they limit the potential design quality and often require extensive workarounds when their built-in components don't meet requirements.
• 🧩 The speaker recommends combining libraries from different categories (e.g. Tailwind for styling, Headless UI for behavior) to build a custom UI system tailored to the project's needs.
• 💡 The speaker believes front-end developers should take ownership of the styling and UI architecture instead of relying on third-party libraries that dictate the structure.
• 🧠 The speaker highlights the cognitive overhead of learning and working with complex UI libraries like Material UI or Chakra UI, which require developers to understand the library's internals and conventions.
• 🚀 The speaker finds that Tailwind CSS allows for a more efficient and enjoyable development experience, enabling developers to focus on building great user interfaces without being constrained by the limitations of a particular library.
• 🎨 The speaker emphasizes the importance of separating logic, behavior, and styles in components, and appreciates Tailwind's approach of keeping these concerns separated while allowing flexibility in how they are combined.
• 🤝 The speaker notes that Tailwind is appreciated by designers, back-end developers, and front-end developers alike, making it a more collaborative and inclusive solution for building user interfaces.
• 🌟 The speaker believes that users deserve the best possible user experience, which can be achieved by taking control of the UI architecture and not settling for the limitations imposed by third-party libraries.

Q & A

What are the three core types of UI libraries discussed in the script?

The three core types of UI libraries discussed are: 1) Extensions of CSS (like Sass, Less, and Tailwind), 2) Behavior libraries (also known as headless UI libraries, like Radix, react-aria), and 3) Style systems (component libraries with built-in styles, like Tailwind UI, Daisy UI, Material UI).

What is the main difference between Tailwind and Material UI (MUI)?

Tailwind is an extension of CSS that provides a better way to write CSS, while Material UI is a style system that offers pre-designed components with built-in styles. Tailwind allows developers to build their own style system, while MUI limits the quality of design to its opinions and predefined components.

Why does the author prefer Tailwind over other UI libraries?

The author prefers Tailwind because it makes them faster at developing style systems, improves their CSS skills, and doesn't impose a ceiling on the quality of their application. Additionally, Tailwind is loved equally by designers, back-end developers, and the author themselves.

What is the catch with using Tailwind?

The catch with Tailwind is that it's inline CSS, so everything is defined at a component level by default, making it less reusable by design. However, developers can choose to break out reusable styles if needed.

How does the author describe the experience of using styled-components?

The author describes the experience of using styled-components as painful and bottlenecking the developer experience. It forces developers to rip out DOM elements just to apply styles, making it difficult to track down the source of UI bugs and breaking other parts of the application when making changes.

What is the author's opinion on using component libraries like Material UI?

The author believes that using component libraries like Material UI can limit the maximum quality of the application. They argue that as front-end developers, they should own their style systems and solutions, rather than being limited by external dependencies.

What is the role of behavior libraries (like Radix, react-aria) in the context of UI development?

Behavior libraries handle the behaviors of UI components, such as dropdowns, modals, and accessibility requirements. They don't define styles but ensure that the components behave correctly on the DOM according to expectations and accessibility needs.

How does the author suggest combining different types of UI libraries?

The author suggests combining Tailwind (an extension of CSS) with Tailwind UI or Daisy UI (style systems built on top of Tailwind), and using behavior libraries like headless UI or Radix to handle component behaviors. This approach allows developers to build their own style system while ensuring correct component behavior and accessibility.

What is the author's stance on writing user interfaces and owning the style system?

The author emphasizes the importance of front-end developers owning their style systems and solutions. They believe that as developers building user interfaces, they should not bottleneck the quality of their applications by relying solely on external dependencies that limit their control over the design and architecture.

What advice does the author give to those who find Tailwind challenging or prefer not to write user experiences?

For those who find Tailwind challenging or prefer not to write user experiences, the author suggests trying Daisy UI (a style system built on top of Tailwind). If that doesn't work, they recommend using Material UI, but with the understanding that it comes with a limit on the maximum quality of the application.

Outlines

00:00

🌐 An Introduction to UI Libraries and Frameworks

The paragraph introduces the topic of UI libraries and frameworks, specifically discussing the author's journey with different solutions like Bootstrap, styled components, Material UI, Chakra UI, Radix, and React Aria. It highlights the author's initial disinterest in Tailwind CSS but eventual love for it after using it on a team project. The paragraph sets the stage for exploring the roles and types of UI libraries.

05:01

😡 Misconceptions About Tailwind and Material UI

This paragraph addresses the common misconceptions about Tailwind CSS and Material UI. It emphasizes that Tailwind is a better way to write CSS, providing a more flexible and customizable approach than opinionated component libraries like Bootstrap. The author argues that comparing Tailwind to Material UI doesn't make sense as they serve different purposes. Tailwind enables developers to build their own style system, while Material UI enforces a predefined set of styles and components.

10:01

📐 Categorizing UI Libraries and Frameworks

The paragraph categorizes UI libraries and frameworks into three core types: extensions of CSS (like Sass and Less, including Tailwind), behavior libraries (like Headless UI, Radix, and React Aria), and style systems (like Tailwind UI, Daisy UI, and Mantine). It explains the differences between these types and discusses the importance of building a component library for consistency across an application. The author advocates for using solutions that combine Tailwind with libraries like Tailwind UI or Daisy UI for better control and flexibility.

15:02

🧩 Understanding the Roles of Behavior Libraries and Style Systems

This paragraph delves deeper into the roles of behavior libraries and style systems. It clarifies that behavior libraries like Radix UI and React Aria handle accessibility and interaction behaviors, while style systems like Tailwind UI and Daisy UI manage the visual styles. The author emphasizes the importance of separating these concerns and using the appropriate tools for each aspect of UI development.

20:04

🚀 The Power and Flexibility of Tailwind CSS

The paragraph discusses the author's approach to writing CSS with Tailwind, which they call "Zen mode CSS." It highlights how Tailwind allows for faster and more consistent styling without enforcing a specific design system. The author contrasts this with the limitations of style systems like Material UI, which impose a predefined range of design possibilities. The paragraph also touches on the benefits of using Tailwind in combination with behavior libraries like Headless UI.

25:06

🏗️ Architectural Considerations with UI Libraries

This paragraph examines the architectural implications of using different UI libraries. It highlights how solutions like Material UI and styled components force developers to structure their applications around the library's architecture, potentially leading to bottlenecks and limitations. In contrast, Tailwind allows developers to own their application's architecture and make decisions about how to break down and organize components and styles.

30:07

💚 The Benefits of Tailwind and Embracing CSS

The paragraph outlines the benefits of using Tailwind CSS and embracing the responsibility of styling applications. The author argues that as front-end developers, they should own their style systems and not be limited by external dependencies. Tailwind is praised for making the author faster at developing style systems, improving their CSS skills, and not enforcing a ceiling on the quality of their applications. Additionally, the paragraph highlights how Tailwind is loved by designers, back-end developers, and the author alike.

35:08

🎉 Concluding Thoughts and Recommendations

In the concluding paragraph, the author encourages viewers to try Tailwind CSS or consider alternatives like Daisy UI if they don't want to directly write styles. However, the author cautions against adopting libraries like Material UI, which can limit the maximum potential quality of an application. The paragraph emphasizes that users deserve better than being constrained by opinionated libraries and encourages front-end developers to take ownership of their style systems and user experiences.

Keywords

💡UI Libraries

UI Libraries refer to pre-built sets of user interface components and utilities that developers can use to construct websites and applications. The video discusses different types of UI Libraries, such as CSS extensions (Sass, Less, Tailwind), behavior libraries (Headless UI, Radix UI, React Aria), and style systems (Tailwind UI, Daisy UI, Material UI). These libraries aim to streamline the development process by providing reusable UI elements and design patterns.

💡Tailwind CSS

Tailwind CSS is a utility-first CSS framework that provides a set of low-level utility classes to build custom user interfaces. The video presenter is a strong advocate of Tailwind and discusses how it has changed their approach to styling and building user interfaces. Tailwind is presented as a CSS extension that offers greater flexibility and control over styling compared to more opinionated component libraries like Material UI or Bootstrap.

💡Component Libraries

Component Libraries are collections of pre-built UI components that developers can use in their applications. The video emphasizes the importance of having a centralized component library to maintain design consistency across an application. However, the presenter argues for building one's own component library or using libraries built on top of more flexible CSS primitives like Tailwind, as opposed to relying solely on opinionated component libraries like Material UI.

💡CSS

CSS (Cascading Style Sheets) is a style sheet language used to describe the presentation of a document written in a markup language like HTML. The video highlights the importance of understanding and mastering CSS for front-end developers. It argues that Tailwind CSS enables developers to write CSS more efficiently and consistently, while avoiding the pitfalls of overly abstracted component libraries that can limit design flexibility.

💡Design Systems

Design Systems are collections of reusable components, design patterns, and style guidelines that help ensure consistency and coherence across an application or suite of applications. The video discusses the tradeoffs between different approaches to building design systems, such as using opinionated component libraries, custom CSS-based systems, or a combination of both. The presenter advocates for owning and building one's own design system to maintain control over the architecture and quality of the user interface.

💡Inline Styles

Inline styles refer to the practice of applying styles directly to HTML elements using the `style` attribute. The video argues that inline styles, which were previously frowned upon, can be a valid and efficient approach when used judiciously. Tailwind CSS, in particular, encourages the use of inline utility classes to style components, as opposed to relying on external stylesheets or CSS-in-JS approaches like styled-components.

💡Accessibility

Accessibility refers to the practice of ensuring that websites and applications are usable by people with disabilities, including those with visual, auditory, motor, or cognitive impairments. The video discusses the importance of using behavior libraries like Headless UI or Radix UI, which encode accessibility best practices into their components, ensuring that users with disabilities can interact with the application effectively.

💡Developer Experience

Developer Experience (DX) refers to the overall experience and productivity of developers when working with a particular technology, framework, or tooling. The video argues that Tailwind CSS and building one's own design system improve the developer experience by providing more control, flexibility, and a better understanding of the underlying CSS and architecture. In contrast, opinionated component libraries can bottleneck the developer experience by imposing limitations and requiring intimate knowledge of the library's inner workings.

💡Zen Mode

The presenter uses the term "Zen Mode" to describe the experience of writing styles with Tailwind CSS. It refers to a state of flow and focus, where developers can quickly and efficiently style components without being bogged down by complex abstractions or external stylesheets. The video suggests that Tailwind CSS enables developers to achieve this "Zen Mode" state, leading to increased productivity and better-looking software solutions.

💡Architecture

Architecture refers to the overall structure, organization, and design of a software system or application. The video emphasizes the importance of owning and controlling the architecture of one's application, particularly when it comes to the user interface. The presenter argues that relying too heavily on opinionated component libraries can limit architectural flexibility and force developers to conform to the library's design decisions, potentially hindering the quality and scalability of the application.

Highlights

Tailwind is a better way to do CSS and own the style system, as opposed to using opinionated pre-designed components from libraries like Bootstrap or Material UI.

Material UI limits the quality of design by capping how good an application can be, while Tailwind expands the range of achievable design quality.

As front-end developers, we should own our style systems and solutions, building applications that aren't limited by the libraries we choose.

Tailwind makes writing CSS consistent, fast, and enjoyable, entering a 'Zen mode' for styling, unlike previous frustrating experiences.

Material UI, styled-components, and Chakra UI force developers to break out components and styles in ways that bottleneck the application's architecture and development experience.

Tailwind allows developers to own the architecture and relationships between components, logic, and styles, without being limited by external dependencies.

The catch with Tailwind is that styles are defined at the component level by default, which can be less reusable by design but significantly improves the developer experience.

Headless UI and Radix UI provide unstyled, accessible components for building behaviors, while Tailwind, Daisy UI, and Mantine handle the styling aspect.

Tailwind UI shows how to combine Tailwind with headless UI components, providing both styles and behaviors.

Styled-components pushed forward the ability to build component systems in React, but ultimately forces developers to break out styles in a way that harms the architecture.

Inline styles, as enabled by React Native, are actually good for quickly and efficiently applying styles to user interfaces.

Developers should separate the logic and behavior of a component from its styles, making the styles section focused on presentation and the user experience.

Tailwind made the speaker care more about styling and user experiences, as opposed to previously shrugging off the conversation.

Tailwind is loved equally by designers, back-end focused developers, and front-end developers, unifying different roles in building user interfaces.

Users deserve better than being limited by the maximum quality enforced by libraries like Material UI, which is a scary thing to adopt.

Transcripts

let's talk about UI libraries and

Frameworks and how we build our user

interfaces in web applications

I am pretty well known for my love of

Tailwind what I don't think I'm known

for as much is my history with other UI

Frameworks and specifically the lack of

care I had for most of them when I

started doing web development the go-to

solution was bootstrap and it was fine

when I got back into web development and

got into the react World we were just

starting to move into styled components

and it was fine I then started playing

with things like material UI chakra for

a bit dove into Radix and react Aria a

whole bunch but this thing kept popping

up called tailwind and I looked at it

it's like oh this looks like bootstrap

but worse I don't think I'm going to be

interested in this so I ignored it for a

while then I used it on a team that I

was working on because another one of

the developers liked it and generally

when I'm running a team I don't care

enough about UI Frameworks to take a

strong stance and I would let other

teammates bring on the things they cared

about and holy [ __ ] I fell in love with

Tailwind fast it didn't feel like a

component Library like this big

opinionated thing forcing me to do stuff

in a certain way it was way more focused

it was just CSS but easier to write and

it's fully changed my understanding of

what the role of libraries is in my UI

design and I wanted to go over a bit how

I have changed my own thinking on what a

UI Library even is much less like its

role in a code base and how we build

around them what are the types of

component libraries

let me open up everyone's favorite app

Quick component

or I should say rather than the

component Library UI libraries I think

that there are three core types

we have extensions of CSS this would be

things like SAS less and I will argue

throughout this Tailwind we have

Behavior libraries otherwise known as

headless UI libraries pretty often

things like headless UI

Radix

react Arya and there's tons others that

I'm sure I'm forgetting and glossing

over and I apologize to all of them this

is less about any one specific Library

more about the types of libraries and

how to make good decisions around them

the third and one that I see people

talking about the most often is style

systems so component or so libraries

that have styles built in things like

Tailwind UI Daisy UI Mantine and you

could argue that mui Falls here but

we're going to go into that in a bit so

I wanted to start with the premise that

these are the three core types of

libraries that exist or at the very

least the three spaces that a library

can exist within that all said libraries

don't have to live in exclusively one of

these so here I made a quick Venn

diagram splitting these three types up

into CSS plus plus so things that are

like CSS but better Behavior libraries

which are things that encode behaviors

like a drop down a button focus and all

of the chaotic accessibility types of

things behind that and then style

systems which are things like bootstrap

that are very much component systems

that you apply on top of your Dom to

quickly just drop some things into these

like we can put Tailwind in here but we

could also throw like sass in here for

Behavior libraries I mentioned Radix

headless UI react Arya

so react Arya

all right reactor is not one of these

this is bootstrap it's probably the best

thing for here I think it's very

important to recognize where the tools

you're looking at using and comparing

fall on a chart like this also throw

Tailwind I guess actually telling you if

it's somewhere more interesting the

thing that I keep having come up that

has been increasingly frustrating to me

is material UI mui and people keep

asking me why am I using tailwind and

not using mui why would I use Tailwind

when it's basically just bootstrap when

I could use mui instead do you see why I

get confused when people say Tailwind is

like bootstrap so you should use my UI

instead do you see why this line of

questioning annoys me it does not make

any sense at all Tailwind is a better

way to do CSS I picked Tailwind because

I want to do some CSS I want to have a

stylus system that I own I want to build

my own style system using Talent

bootstrap is a style system itself a

single class in Tailwind usually results

in one line of code of CSS so if I go to

the Tailwind docs quick and I'll just

pick a random piece we'll go to justify

content you see here all the justifies

mapped to exactly one line of CSS now

let's go to the bootstrap docs they have

some amount of like helpers in their uh

layout stuff like these are kind of

helpers

however what they expect you to use are

their buttons

button

let's see how much CSS it provides they

don't even tell us in here button

primary adds all of this [ __ ] button ads

all of this [ __ ] can you customize

bootstrap sure are you going to have fun

customizing 50 lines of CSS because you

want to change how the button behaves

and you committed to bootstrap no you're

gonna have a miserable time bootstrap

gives you opinionated pre-designed

components that if you're happy with

cool but the reason people kept going to

bootstrap was a combination of CSS being

hard to write design being hard to pick

up and developers being lazy one of

those has been resolved by tailwind and

developers can who are lazy are more

likely to you or get things done

properly with tailwind and then there

are also now Solutions like Daisy UI

which I bring up a lot on stream because

Daisy UI is built on top of Tailwind

instead of being built on top of

traditional CSS which means you can take

a component here use their button and

underneath it is a bunch of Tailwind

classes and you can even here take a

look at the HTML I thought they actually

dumped the CSS that it creates for you

generally though the cool part of Daisy

UI is that rather than being built on

top of CSS with tons of chaotic stuff

jcwise built on top of Tailwind

personally I prefer the way Tailwind UI

does this I mean yeah I'm a Tailwind

Fanboy but tail and UI although it costs

money I'll be clear yes this costs money

does good design cost money it's the

thing you'll learn quickly as you like

start running companies and Building

Things the code examples here like the

stuff you get from Taylor UI you don't

npm install it don't npm install your

style system please don't npm install

your style system your website deserves

better they just give you the source

code

so when I use Tailwind UI I go through

here I look at these class names and

then I copy paste things into my code

base and that's how you use Tailwind UI

it's great yes I did buy it I actually

bought the team license at ping because

it was worth it for us it is something

we use heavily we care a lot about so we

bought the team license fun fact word

wraps a Thing If long lines are the

thing your character you're complaining

about

you just don't write

a lot of UI like lines get long this

lets me write everything very fast I

I'll go into pros and cons of all these

Solutions in a bit but I want to keep

placing things where they they live and

discussing the the value that they bring

in those places so in here we can put

Tailwind UI because it is very

specifically a style system but it shows

you how to combine headless UI and

Tailwind which is really interesting

because Tailwind UI is arguably here but

it lives here it looks like honestly if

we were to put Master somewhere it would

probably go here because it's trying to

be a combination of a style system and

building their own virtual CSS language

it's interesting I'm not sure how I feel

about it just yet but it's a very

interesting development and I'm excited

to see where it goes what else is there

uh Mantine I think Mantine is basically

just like a new flavor of mui focus on

react 100 plus components yeah it looks

like Mantine definitely fits within here

so I'm gonna do something important

we're going to label this section here

this is component libraries a harsh

reality is most companies need a

component library of some form whether

it's one that they built themselves or

it's one that they npm installed from

somewhere else component libraries allow

for a centralized place to unify a

design language across an application so

buttons consistently look the same so

drop downs consistently look the same

Etc I would argue this is our job as

front-end developers we are building

user interfaces I personally think we

are giving up one of the most important

parts when we npm install a solution

from here and even if you don't want to

build your own component Library I think

it gives you significantly more control

and flexibility if you use the component

libraries that are built they're the

style systems that are built on top of a

better CSS primitive so if you combine

something like Tailwind with Tailwind UI

or use tail ended headlessy why to build

your own thing or grab Daisy UI which I

guess kind of fits like here and here

it's using Tailwind but what Daisy UI

itself is just here but by using tail

end it fits between the two but using

these types of solutions to get you to

here

because we all kind of want to live in

the middle we all have to be in the

middle to some extent with the things

that we built entailment is just giving

us this one thing here and I think this

is where a lot of the pushback on

Tailwind comes from is people think it's

here and they get mad because they don't

like things here it's not here and they

get mad because it doesn't do the things

that are here and they're used to being

here and they don't see any reason to

leave I think those are the core reasons

why Tailwind gets so much [ __ ] and I

think all of those are are pretty unfair

and come from a place of bias the bias

being I don't have to think about my

Styles or we're building websites we're

building interfaces we're building user

experiences we should think about our

styles to me not doing this would be the

equivalent of a back-end engineer not

thinking about their data like you

should think a decent bit about where

your data goes and how you work with it

there are packages that will make that

easier for sure but abstracting that

away into something like this just means

you have to learn way weirder [ __ ] when

you have a problem that the libraries

that are provided do not solve there

have not been any problems we have had

at ping with Tailwind that we couldn't

solve with Tailwind or around Tailwind

very easily when it comes to heavier

component libraries you need to know

them very well and you need to know

their limitations very well in order to

work around them at all simple things

like resetting a sub input in a field or

in a form in mui requires an intimate

knowledge of react and intimate

knowledge of forms and an intimate

knowledge of mui's weird prop passing

behaviors so you can actually get a ref

down to the input underneath those

problems are pretty damn common in mui

land and in this component Library space

when I have those problems I go to my

designer developer team that builds the

component library right now that team is

Brynn previously that team was a

fantastic group of Engineers at twitch

but you should own this even if you

aren't particularly familiar yet with

how to build these things maybe for your

first ever app if you're okay with

things not working exactly exactly how

you need them to npm install mui use

that for a little bit and as soon as you

start running into problems and

frustrations on your next project drop

it there is very little need for anyone

other than like a back-end leaning

developer that's trying to ignore the

front end as much as possible to use

something like mui I don't want to shout

out one person in particular the one mui

user that I'm okayish with him using mui

Aiden the creator of fossibot he's a

back-end engineer he wants to focus on

back-end engineering he wants to build

Crazy infrastructure and crappy

interfaces to get to it mui lets him do

that very very quickly on a website that

looks

but that was the goal mui and things

like it are choosing to limit the

quality of your design to the opinions

of mui and what it's providing

so if we were to do another my favorite

chart types a spectrum now let's say we

have zero ugly on the other side we have

10 beautiful I think all of these

Solutions enable very different ranges

of capability so let's start with just

vanilla CSS I think vanilla CSS can get

you

this whole range easily I think

something like Tailwind cuts off the

lower half with some of the opinions

encoded if you really want to you can

make Tailwind ugly but it's like it

takes a good bit of effort because the

things it provides are solid so Tailwind

gives you a slightly better starting

point in terms of how ugly your things

can be like makes consistency much

easier and then gives you a way higher

cap something like material UI starts

you off at a slightly better place but

it caps off incredibly hard because at

that point you're gutting mui and

building your own thing you can do that

I'm not going to say you can't I'm just

going to say you'd be way better off

starting with almost anything else that

is not going to be the best path to what

your goals are I can I can promise you

that much and if we look at what our

other Solutions do we have in here yeah

don't use bootstravis 2022 you know

better I think this summarizes this

particular point I wanted to make that

like Tailwind greatly expands the range

of quality of design that you can create

but you are creating it material UI is

committing to live within a certain

range and depending on your goals like

if your goal is I've been here for too

long and I want out right now maybe

material UI is an okay solution but if

your goal is to build something and move

it to the right as hard far as you can

over time material UI is not going to

help you get there all material UI is

going to do is get you out of this range

once you're out of that range it's very

limited with how much further it's going

to help you I think there's one more

important sub-branch to go on here and

somebody just called it out in chat

styled components actually we'll go back

to talk about somebody else asked I

apparently I wasn't clear enough what

the difference between headless UI and

Daisy UI that's a very good point I want

to be very clear about the difference

between these things these are CSS these

are JavaScript these change how things

look these change how things work Daisy

UI is a bunch of pre-written Tailwind

classes so that you have a button that

looks a certain way headless UI is a

bunch of unstyled components and hooks

to make a drop down look and work the

right way with accessibility to make a

modal look and work the right way with

accessibility these are how you actually

construct the elements on the Dom with

behaviors in JavaScript that handle your

like behaviors for your components these

are how they look I would argue these

two have way less in common than

anything else I I hope this helps

clarify the difference between them but

something like Tailwind UI for example

in their code

uh this one doesn't have it uh maybe if

I use react it will

no it won't on some of the examples in

Tailwind UI uh I don't know if they're

going to show any here maybe they have

like one drop down or something okay so

this might work uh the heading maybe

they have code in this one

yes they do so in here you see menu and

transition are being imported from

headless UI that's because these

components include behaviors they don't

include Styles so when you do menu as

div you're using menu the JavaScript

helper that the Tailwind team wrote as

part of headless UI

to make this correctly appear in the Dom

as a menu nav element such that these

buttons behave correctly and these

transitions introduce and remove items

correctly according to Ada expectations

and accessibility needs so this is the

JavaScript behaviors that you should be

writing in order to make your things

accessible and behave correctly provided

as a component Library if you go to like

Radix UI or react Aria I think Radix UI

is the one that I see people talking

about the most that's pretty dope Radix

UI does not have any Styles at all they

even call it out here it's unstyled

accessible components for building high

quality Design Systems and web apps in

react these Primitives handle things

like an accordion so when you open and

close it

things appear underneath and still

adhere to

expectations around Aria labeling and

such

this doesn't Define how it looks at all

this purely makes it behave correctly

and it does

nothing else Behavior libraries are for

how things behave style systems are for

how things look CSS plus is for how you

make them look a certain way somebody

asked what do I do if I need a date

picker or a similar component with

Tailwind usually I start on Tailwind UI

it looks like they don't have a date

picker so a Google search react dick

picker I look at this I can see if it's

fine and I use it date Pickers are the

weirdest example ever because date

Pickers uniquely suck and should be

provided by the browser and aren't

I would npm install a date picker

because it's a very complex piece of UI

I don't feel like [ __ ] building it

falls in a very very unique category in

that way oh we did not talk about chakra

so if I understand correctly chakra also

falls under here but it like Blends into

the style system a bit I've only played

this chakra a bit and kind of annoyed me

oh it looks like it has a very it almost

looks like this actually

chakra's exactly like Mantine no Mantine

is way more like fully featured

components like it has a hundred plus

components

this is not that that chakra has like 20

components at most if I recall yeah they

don't have anywhere near as much stuff

ah it kind of is all three though

because it has its weird like CSS plus

Syntax for its margin definitions and

[ __ ] it kind of has Styles built in that

you have to be familiar with to work

around it has hooks for behaviors and

things like that when I said we want to

be here I meant we want to build here we

want to build the thing by combining the

best parts from these areas I I have

tried or I haven't tried Mantine I've

tried chakra a little bit and it felt

like

another component system to learn and

another CSS solution to learn and

another style system to learn another

Spectrum we could look at here of like a

vertical it's CSS and on the top here

it's some weird [ __ ] and on this

spectrum tailwind's pretty low

it's pretty close to just being CSS I'd

even say bootstraps not too much further

I hope it starts a little further but

something like chakra just hangs out up

here alongside mui like these aren't

like when you learn chakra or mui you're

learning chakra and mui when you learn

Tailwind you're getting better at CSS if

your goal is to avoid CSS if you want to

like draw a line here and say I will

never go below here because I'm a

back-end developer I don't care about

what lives underneath there sure go hang

out in this land telling me you use

chakra UI and that it's like Tailwind

but better is like telling primogen

you're using node.js it's like rust but

better we care too much to feel that way

which is the difference in goals and

objectives here it's just it's so much

to learn I don't know if you all don't

see it because you've been using it a

bunch

but use color mode value is a hook

that is specific to chakra that you have

to know and understand the behaviors of

and then combine with additional react

hooks that live within react and then

understand how these all interact with

the components that are provided and the

behaviors inherent to that it took me a

bit to figure out how you actually enter

like trigger this like tabs has an on

change that calls with an index and I

guess whatever you put in tab list is

inferred as the children that tabs will

call with but is there a way for me to

put a custom value here instead of an

index maybe I want to pass like an ID

and have the ID get put here instead if

I did that there's no way it would be

typesafe because the definition isn't

smart enough to go that way but no you

need to understand chakra

deeply to use chakra if you use chakra

every day and you've never used these

then you're installing a bunch of

JavaScript that you're not using I can't

say for sure how tree shakeable chakra

is but by the the string slash

JavaScript nature my assumption is not

very like I cannot imagine a lot of

these behaviors being tree shaken

because they're keys on the props and

the components that you're using the

lock in here is absurd the not just like

code base locking but brain lock-in you

start to to use your brain the chakra

way not the browser way with Tailwind

you're only using the things that you

use when you add a new class name and

Tailwind or in your UI when you're using

Tailwind the tail and compiler sees that

and it adds that Tailwind

into the CSS file that gets compiled out

time for the styled components rant

style components was very important

styled components

pushed forward the rate at which we as

developers could build our own component

systems in things like react and big

applications when at twitch we moved

away from Rolling our own chaotic State

[ __ ] to build our own component library

and started using styled components as

the way to apply and change Styles and

components style components was a pretty

powerful primitive for building a

component library at a place like twitch

so revolutionized how we build component

Libs in react this is also the problem

with styled components similar to

storybook it is only good at that styled

components were talked about very very

positively by many people including

myself because it was one of the easiest

ways to build a component system to have

a blob of I'll pull up some code

examples for us to look at so here's an

example of a styled component in a

styled component you can just write CSS

like these little back ticks and also

call the props that get passed in that

are properties maybe you have like in

this case primary which adds in

background white color black what's

funny here is the even in their example

here it is improperly highlighting

things like this should be highlighted

the green color and it's not or this

shouldn't be highlighted green and it is

it's funny that like the home page

example doesn't parse correctly for a

highlighter because it is such a

bastardization of CSS and JS it is a

messy combination of the two

and the type scripts like definitions

around it can be obnoxious as well the

reason I bring this all up

is because when I had to make a button

that had

15 different properties and those

properties resulted in slightly

different CSS this was one of the best

ways to do that and for a while it was

the only quality way to do that the

problem is what if I have

a div in line and I want to add two

classes to that quicker I want to add

two properties to that quick I want to

add flex and I want it to align right

now I have to take that div break it out

from the return make a styled const I

have to come up with a name which is one

of the hardest underrated Parts you have

to come up with a name for whatever

you've broken out this container to be

now this container is named Flex right

and I have made cons Flex right equal

style dot div apply all of those

properties then render that in the

component then I have another component

that needs to flex left instead I shrug

I copy paste the flex right I rename it

Flex left I change the one property and

I reuse that until when do you just

write a string the harshest reality that

we got out of styled components and

honestly I think style components for it

the best thing we learned from style

components inline styles are actually

good for a long time

we hate it inline Styles inline styles

are actually good I personally learned

this when I started doing more react

native Dev and inline styles were pretty

much the only way to do things inline

Styles enabled us to quickly and

efficiently apply styles to a thing when

we were building our user interfaces and

the philosophy I quickly developed let

me just write a quick demo component

here the thing that I learned from react

native very quickly that made me a much

faster react developer when I started

thinking about things this way man did I

get way faster as a developer this is

the section that describes how a thing

looks

this is the section that describes what

the thing does

and if you do your best to think about

your components in this way suddenly

class equals a bunch of [ __ ] goes here

you just feel less bad about it because

that's the role of this section the goal

of your return Isn't to look pretty as a

developer it's to look pretty for the

user this is the part that describes

what the user sees I couldn't give less

of a [ __ ]

about what this looks like as a

developer as long as it's readable

understandable and my developers can

make changes quickly within it and here

is where the logic goes for behaviors

like logic fetching data whatever else

and this control flow below the return

is what your how it looks above the

return is what it does means that being

forced to break out const special div

equals style dot div display flex line

items right this just sucks like being

forced to move this out of your

component flow is good if you were going

to anyways if everything you're doing in

here is a reused piece

sure but the vast majority of the time

I'm building user interfaces I'm

spending more time on the padding and

the flex behaviors than I am on the

button styled components specializes in

making reusable buttons we specialize in

making user interfaces the reason

Tailwind is great is it keeps you from

having to think about your logic your

components your breakdowns and all this

other [ __ ] when you're just trying to

make the thing look right for the first

time I stopped thinking outside of all

of these parts and when I had logic I

was here when I had Styles I was here

otherwise I was done and that was so

nice I started to like CSS way more when

I started thinking in this way when I

stopped having to go to a different file

and I stopped having to join things out

when I stopped having to reference a doc

and see how Mantine feels about this

type of way like I could just write the

style full-on Zen mode and once you get

used to the Tailwind syntax and cheat

she's like this just show you all the

class themes super quick so you could

scroll through it fast I just keep this

open on my monitor on the side when I

was learning tailwind and it's very

quick to be in here and see like flexbox

Flex

you can click display and see Flex

display flex and line flex and line Flex

it's very nice to quickly see the class

names that you need and not have to like

dig through a big dock to find them

highly recommend something like this as

you get started but what you'll see here

is almost all of these map to one class

of CSS I got way better at CSS because

of this and funny enough

the Tailwind docks

I mentioned I'm not in them too much

there is one exception I use the

Tailwind docks a ton when I am not using

Tailwind because I'm not in tailwind and

I want to remember what the actual CSS

that class does is usually colors like I

want to like I want to use red 700 so

I'll hop in here and grab the red 700

hex if I want to do like if I remember

like the one thing that you could argue

is maybe worse is I don't think in real

padding amounts anymore like I don't

think in 24px I think in Tailwinds

padding this is customization I don't

want the customization I just want I'll

just go to the cheat sheet because this

is easy for things like this cool

padding is right here and you can see P1

is 0.25 REM P2 is 0.5 M8 Etc so I just

think about these people are asking if

there's a catch with Tailwind kind of

the catch is it's inline CSS so

everything's defined at a component

level unless you break out they're like

like an individual component level

unless you break those out so it's more

reusable by default but less reusable by

Design which is an interesting

compromise to make

but it does make life significantly

better once you buy into it you get to

Define your own boundaries a lot of this

is an argument of how do you want to

break up your styles from your

components the way I like to think of

things is

I have a component and this component

inside of it it has logic and beneath

that logic or I guess arguably next to

logic so component has within it logic

and styles so I like to think that a

component and this all lives within my

application I like this I like that my

app has components that contain logic

and styles these can contain

sub-components that contain logic and

styles but I get to choose the breakdown

from here if I want to move the Styles

out and then import them in

I can do that

if I want to move this logic and style

out make a sub component and then pull

them in there I can it's my choice but

by default

it's incredibly simple

my components have logic and styles if

we have a app that uses mui then we have

a separate box out here that is mui and

this box has a bunch of these mini logic

style component combos that I have to

use to make

my component

so in here I might just have [ __ ]

like this one actually I know what I can

do that I'm like this nice and funny

we'll do one layer of that one which

contains a layer of this one

which contains this one again

and this one next to it and if anybody

thinks this isn't what happens in

component libraries you're wrong this is

what it feels like to use mui this is

what you're doing and you have to know

about this box well enough to take these

parts and drag them into your

application your architecture of your

app is based on material UI and how it

decides to break things up you cannot

architect your application outside of

how mui designed their architecture with

something like Tailwind because it's

just the CSS part you can choose where

the breakdowns occur you can choose how

to architect things you own your

architecture and as a front-end

developer I want to own that

architecture I want to be in control of

the relationships between these things I

want to have Primitives that I can

assemble in the ways I need to develop

great software for my users I do not

want to bottleneck the quality of my

application of my architecture of my

development and of my users experiences

on an external dependency I want the

only bottleneck for the quality of my

app to be my developers and when you use

something like material UI

you are bottlenecking the quality of

your UI on the Developers

or on the material UI instead of your

developers and when you use something

like styled components or I guess in

this case mui your

forced to break things out in a way that

makes your architecture worse than it

theoretically could be I'm going to make

one last one here of app that uses

styled components the big difference

here you would probably Define a

different thing for this lower class

because you wouldn't realize that was

reusable and you would build all of this

chaos internally inside of your app in

another directory so we will name this

slash components and pretty much

everything you do either goes in there

or goes above this file so I'll call

this component dot TSX and this is like

the actual component you're rendering

you might have one of these defined in

the same file this is a really hard

control flow to follow if I am building

an application and I want to figure out

like let's say I have a UI bug and

something's too wide I want to figure

out why it's too wide I inspect the CSS

on the browser and I see it has a

certain CSS property

I go to this file

component.tsx that has that component

and I can't see that class name anywhere

or anything that would logically be

including it so I go component by

component I go to the component from our

component library and style components

until I find the thing that's applying

that line of CSS I don't want and then I

delete it and it breaks something else

somewhere else it's painful your

developer experience now is bottlenecked

by how well you architect these things

and how good your developers know that

architecture you have a bottleneck your

delivery your ability to solve bugs and

generally architect applications is now

bottlenecked on the way style components

forces you to rip out a Dom element just

to apply styles to it it's rough

if you are building this already and

you've committed to building something

like this as a company style components

wasn't kind of is an okay primitive to

do that I think there are now Solutions

like vanilla extract that do a way

better job at that I am pretty happy

with how vanilla extract solves these

particular problems I don't think it's

like a necessary solution but it is an

option for sure and if you want to have

an architecture problem you should think

through the architecture problem

if you don't you should probably just

use Tailwind have I covered the things I

wanted to cover with this do I go deeper

on why I like Tailwind I feel like I've

covered like I've touched on Tailwind

enough throughout this that I don't need

to go deeper on it but generally

Tailwind is the easiest way to write CSS

in a consistent way it has a lot of

really nice behaviors within it it is

the first time I have not just felt good

but felt great writing styles after a

decade of web development and various

Solutions Tailwind makes me very very

fast at Styles and it's the first time I

I call it Zen mode CSS and that's really

how it feels you just go fast and

deliver great looking software Solutions

like material UI styled components and

chakra even Mantine and these new

component libraries I keep seeing and

hearing about solve a very specific

problem I don't want to style my

application I think that as front-end

developers we should sum amount own our

style systems and our Solutions and

build applications that aren't limited

by the libraries that we choose the

reason I like Tailwind is it's the first

style solution that makes me faster at

developing style systems makes me better

at CSS and doesn't force me at a new cap

of how good my application can be it

doesn't enforce a ceiling for the

quality of what I can ship unlike all

these other Solutions too tailwind's the

first design solution that my designer

my back end focus devs and I myself all

love equally it is so cool in those ways

so yeah sure you could view this video

as a love letter to Tailwind but it

really is it made me care so much more

about these things when before I would

just shrug at the conversation so

seriously tailwind's changing a lot of

things and how we architect our

applications if you haven't already

tried it give it a shot and if you find

after that that you just still hate

writing user experiences and want to get

back to back end

give Daisy UI a shot and if that doesn't

work for you sure use mui but generally

mui and things like it are a scary thing

to adopt because you are choosing the

new maximum for how good your

application can be and I think our users

deserve better than that thank you again

taking the time to watch this one

subscribe on YouTube if you haven't

already very surprisingly low number of

you have and we're so close to hitting

that 40K mark

had a lot of fun with this rant the

community contributed heavily to make

this one happen and appreciate y'all

immensely see you in the next one peace