Facebook Tried Tailwind, Then Built This Instead 

the second I see a css library that requires you to name things I get fatigued XD

From a shareable styles perspective this does look pretty cool. Dev experience wise it doesn't cut tailwinds lunch, not even close.

So we need to again come up with these lovely names like .card-primary-container just to create a flex-box column. The only thing I'm not missing is naming things.

this is literally how you do styles in react native

I prefer Tailwind😁

I like this sort of video. Even if you aren't going to use something, you can learn a lot from seeing how different projects choose different values and tradeoffs.

Just remember that Facebook made this to solve Facebook problems. This looks like a big step back to me for many other types of projects, and comes with a lot the same drawbacks that CSSinJS usually comes with. I also find the claim of colocation laughable considering all of their examples import some nonsense CSSinJS objects from the depths.

I never really understood why people shy away from just regular old (S)CSS. The project I'm working on right now just has SCSS and Vue scoped styles and I never felt like I needed a fancier solution than that. I can pump out pages with responsive layouts just as quickly as with tailwind and I'm still in the "Tailwind makes my markup look messy and horrible" camp so I prefer this approach. Overall when I think about it I probably spend less than 5% of my time styling things so I never felt that was an area where I needed a 10% improvement in my workflow. But hey, your mileage can vary.

I think this is great if you are making a component library. For apps, I will stick with Tailwind.

The fact that they said "kind of" for colocation in Tailwind triggered me. Stylex seems like a step backward but whatever floats one's boat I guess.

This feels very similar to SCSS modules used at a component level.

I still like tailwind more😅, as It maintains sweet spot between convenience and scalability.

a different way to write classNames basically

what difference between this and styled-components, I can see this is 99% similar with styled-components

This was present for a decade in material react mui and they deprecated this makeStyles as this is unusable. I dont see any benefit comparing to styled-components

I'm still impressed by what huge code monsters developers have come up with to work against the nature of CSS, instead of following the CSS path and using its strengths.

Tips for those still using BEM, if there is anyone out there, your component name is the name of the block, you anyhow have to name your component with a unique name, make that the name of your block, and then for the elements and modifiers inside of it, just use anything you would like, you are scoped to that component, unfortunately next wont allow you to import that css file to a single component, but you can still keep it in the same folder and then import it to a global css file you have included in the app or wherever, when you stop using the component, just delete the whole folder and the compiler will let you know where were the files still being referenced.

This is just CSS with extra steps.

Yeh I’m still missing the point in this, it’s just styled components v2…

I really think libraries themselves should have these sorts of docs exploration videos on their sites, so good.

Yeah this one is definitely not for me this seems like a mess overly engineered just to write css.

To me, I think you summarised it pretty well with StyleX requiring more "cognitive overhead" which is something I as a developer am not interested in.

Alternative video title: frontend continues to go downhill Tailwind was already stupid enough

tailwind shorten the styling and make it visible on the component level itself. sylex is doing that is like doing inline, split up the script into another file or section and make it difficult to see the styling like traditional styling. maybe the solution to scalable tailwind is to create classes that encapsulate number of classes

Sorry Theo... but Tailwind has no co-location at all. Inline classNames of classes you don't own is not even a single bit more co-located than inline css styling. When you need to make a change you'll grab the same old iconic "find-all replace-all" tool. It is easier to get it done because the tokens you are replacing are aliases themselves, but not more co-located because you will not ever change Tailwind CSS itself. Don't get me wrong, I'm not bitching on Tailwind, and I think I would still prefer to work with Tailwind any day.

Removing style-at-a-distance generally seems like a philosophical decision and not a practical one. In 99% of cases, doing something in CSS will be more performant than doing something in JS. Needing to use JS to calculate isOdd, for instance, instead of using a pseudo selector from a parent seems like a ridiculous (not stated) caveat. I use CSS in my projects to eject from React world when rerenders are needlessly expensive and I can just modify a CSS variable instead (think table columns on a complex table). Stylex will need to create a novel solution to maintain their opinionated approach while abstracting style-at-a-distance in a more practical way. I wouldn't consider using it without generic solutions to this self imposed limitations or repeatable PERFORMANT ways of achieving these patterns.

This is the same thing as traditional CSS - you make class names that correspond to rules and then apply them. The only difference is you write the CSS rules in js and you can use the js import/export system, which I would say is better than using CSS files, but it literally is the same exact workflow so it seems Edit: I see they got rid of styles cascading down to children elements, so that's one thing that's different, might have missed some others in the video

I always thought react native styling is superior. This looks the same. Good

does this remind anyone of just default HTML css but just ... worse?

the idea looks promising, sometimes I'm being lazy and write a const someComponentStyle = `some tailwind classes` and just reference that in multiple element/components' className and styleX might solve that(?), being able to have a centralized piece of code to update the style

Elon’s gonna be pissed when he finds out Zuck is naming his new css-in-js styleX

I don't agree that styling elements using their relationships (or as they call it "at a distance") is a bad thing. I do agree that all styles of a component should be defined in one place, but I also believe that clearly representing relationships is important. When using Sass I have always worked in a specific way, where all styles for a single component must be inside the same block, e.g .my-component { }. Meaning that I don't use `&:hover > .my-component` in the parent block, as that would violate that rule. Instead I use `:hover > &`, which is basically declaring a variant style of that component when the parent is hovered, keeping all styles related to that component in the same place and preserving the relationship between parent and child. If StyleX finds a way to preserve these use cases, then I might be inclined to take another a look, but until then, this feels like a half baked lib to me and would not be using it in a real project.

This doesn’t look great tbh. CSS in React is absolute hot garbage.

I really don't get this 'doenst scale' thing... It really doesnt make sense.

MUI has this exact thing already with the sx prop and theming

Tailwind is also on top of shipping newest css features (like :has, or the ability to use custom inline var to make framer-motion animations ‘dynamic’) and provides great documentations on how to use them, I can see they’ll come up ways to organize inline css on a code editor level and give more intellisense power to help developers. But it’s interesting on stylex is heading towards to…

For me it`s a kind of styled component 🤔

Tailwind et al. are a prototyping abstraction that shouldn't make it to production encouraging practices that erode the web in ways such as undermining userscripts and userstyles for users, inscrutable code for end users, and debug soup for developers. All these hoops will continue to be bad because of thing devs want to avoid CSS: naming things with nouns.

I like the pattern they followed, but being able to see all element's styles in one file is a huge help with Tailwind.

I think using svelte and tailwind in combination is the best of both worlds, when I need a css class for reusability or whatever reason I can declare it in the style tag.

I am so grateful for this channel! Thank you Theo for communicating all these hard concepts so concisely! I have a request for a topic on Next.js, no one seems to be talking about and breaking down the "down the tree" concepts. I don't know why but something about it is really tough for me to wrap my head around. Another rant I would love to hear would be an update on "don't use MUI with Next.js!" Thank you again for all the awesome content!

The whole concept of tailwind is that you don't have to write anything that resembles CSS, this StyleX approach could get messy very quickly and it will slow you down.

Hi Theo, Its me again, your favorite Hasura user. We are at the point of the web where its literally just about power. We keep reinventing the same shit over and over with some slight modifications. Then some genius comes along and shatters everything we took for granted single-handedly shifts us into a new paradigm. I think tailwind was that paradigm but this stylex is just a rehash of it, doesn't seem as revolutionary tw. We been already looking into atomic universal styling with TamaGUI.

I thought this was styled-components

isnt this the same as stylesheet in react native?

This feels alot closer to something like emotion or styled components (as a class name rather than component) - doesn't seem like tailwind is the best comparison to this.

Isn't that just Microsoft's Griffel?

The beauty of tailwindcss is just know ur css and you are good, you need to croup classes do it directly in the css file the traditional way with @apply, use variables or some tw plugins, having conflicts with merging classes tailwind merge is there for u, there are a lot of utility tw libraries u can leverage to achieve some tw tweaking, you u just need to know is ur css and u good. I don't agree with the idea that tailwind is not scalable, tw is the most scalable css library out There. People that complains about tailwind don't know css and don't understand the problem tailwind is trying to solve. I have one question, if tailwindcss exists why will I learn all these just to create a design, my css knowledge should be enough

I‘m still stuck with runtime css-in-js because the DX is too good. In my case styled-components + style-system. Not having to think of class names, responsive style props that can be dependent on state, the possibility of directly writing css, colocation. Tailwind was the first zero-runtime approach where I thought it could be a livable alternative, despite its cryptic class names. But writing ad-hoc custom css is really weird in Tailwind. Still waiting for a better approach to land, StyleX isn‘t it.

why not just use css?

The real problem Tailwind solves (and Stylex still doesn't) is that most CSS styles we want to apply will come in a set, and Tailwind already has the most interesting sets, with consistent naming... and that's why developers love it. If the dev wants a component to look a certain way, it's easy to think what "set" they want to use... because all projects he works on have consistent naming styles brought by Tailwind. Anyway, nobody likes writing the CSS styles so that's a huge win. Stylex will solve a whole different bag of issues worth solving, and, to be honest, making it in a type-safe and deterministic way seems like the only acceptable way of solving these issues. Thank god (Facebook)! However, I'm still not convinced that these perks will be enough to make the experience of "creating my own CSS style sets and naming conventions" a bit more pleasurable than just using Tailwind.

For anyone who likes Tailwind, keep using it. Good for you. For anyone who wants to create their own design systems, this looks like it has a lot of potential. Last style always winning is huuuuge. One of the most annoying aspects of CSS.

This is just panda css but worse

It's funny how 95% of the comments on here are people who have 0 idea what they're talking about and are extremely confident about it...🤣

🤮

It seems really close to Panda CSS

Nah, I am gonna stick with tailwind

Is this all just about not shipping css that you aren't using? I still have a hard time understanding the advantage of any of this over vanilla css (or rather SASS), i do absolutely hate when i see stuff like telerik ui shipping literally with 5mb's of CSS, but i feel like that should be avoidable with some common sense no?

- Bloated both CSS and HTML, and even JS - Unsemantic CSS and HTML - About zero typing with no autocompletion - Lots of boilerplate - Babel dependency - Braking build - Difficult debugging

It's got some interesting features as does UnoCSS and I might choose it for a greenfield project but these things aren't enough for me to migrate an existing project from Tailwind to this.

I have the same problem with this as I have with tailwind. I violates the style/markup dichotomy. That sounds like an overly philosophical hill to die on, but the thing is, most of this stuff is an entirely unnecessary complication. I understand why people think they need it. Component frameworks lead to monster doms that are pretty much impossible to style with css the way it was originally intended. And people vastly overuse class based styling. But the problem isn't css, it's the monster doms. If you have halfway sensible markup, SASS is the only CSS extension you really need in my opinion. Can you get that with a component framework? Yes but you have to care about being efficient with your markup.

Thanks I hate it. Just another rehashed `emotionjs`, `styledcomponents`, `classnames`, etc etc etc. Yet another dumb way of writing CSS inside JS files without any of benefits of Tailwindcss.

I personally still love Tailwind instead. This library is great but at this time, I don't need it for my project. but maybe it would be different when react-strict-dom stable

All i want is tailwindcss becoming a part of the HTML standart itself, write "sstyle: pt-10 pb-20" (sstyle for short-style direct css embedding).

Nothing new. However, css-in-js is created for only one purpose - cross-platform styling. And this is a big problem. We are no longer waiting for these cool CSS features in the browser. Because we are targeting the mobile platform. What a disgrace.

No source code released yet. A lot of text but mostly vagueness and half-baked comparisons about vague qualities like "composable". And absolutely riddled with typos... Doesn't feel rushed at all.

This seems like all other css-in-js solutions. Not only does Tailwind save you from having to name everything, it's also a starter kit for your design system. It's so much easier to build consistent UIs with Tailwind. Stylex you still have figure out the values for all your design tokens -- not seeing the appeal of this Grug brain developer does not approve

The implementation looks exactly like MUI v4 makeStyles

1. how is this different from jss which they already made public years ago? 2. why are they still not making css type-safe. very confusing to me how nobody has done this yet. There should be NO strings in css. Everything is an enum or a number.

That comparison table is a bit suspicious to me. Someone tried really hard to make this look better than it is. For example, styled components definitely support composition, and dynamic styles. And even the object style format (optionally).

This can't be direct compared to tailwind rather than a tool that can help tailwind write better code, instead of inline string, now tailwind can be rewritten to be more flexible in js way. Imagine, tailwindcss will be having a plugin using stylex that transform all exited classname style into javascript reference, much more dynamical than just a className string alone.

19:37 "having to come up with a name for every single thing..before you can start applying styles that's real mental overhead" Unfortunately tailwind encourages a behavior to never name things even after the starting prototyping is finished. Naming things is hard, even harder if you never practice.

Nice library from Facebook, but never gonna use it. Nothing really special about it, these improvements could have just been contributed to an existing library rather than creating yet another library. Let's innovate not create another styling library.

Definitely sticking with tailwind, but thanks for covering this.

I really do envy RU-vidrs in the front end dev space. They get a continuous stream of new frameworks for their content :)

What have they done, they just started CSS by JS frameworks......... we saw what mess that is with JS frameworks when react was created now they started the same problem with CSS, prepare for the neww CSS Framework wars

Probably will see some people use both tailwind and stylex.

Feeling underwhelmed. Besides the typing, I am unsure what I get here I can't do with css/scss modules combined with cx/classNames 🤔

it looks soo much like how react first tried to include styles

Sorry for my ignorance but, how is this different from just plain CSS clases and then use those class names? I know I'm missing something.

TW doesnt scale??? How? If you want to scale styles in component based frameworks - you are doing something wrong.

There's some nice concepts but it's such massive downgrade in every other aspect compared to tailwind. I really won't go back to naming things that shouldn't need a name.

Thanks for the feedback! I just updated the website based on it.

5:32 “it’s super counterintuitive” - talking about CSS (CASCADING style sheets)

But it doesn't solve the biggest problem that tailwind solved : magic numbers everywhere. And arbitrary names. It's just a better CSS modules. Meh.

I see no reason to use StyleX to be honest, furthermore In my view StyleX sucks kind of... Tailwind FTW!

Why do you look so scary? Are you not blinking enough, or is it the combination of blonde hair with a dark mustache? Thank you for the interesting videos!

if meta is a company with so many great software devs, then why are facebook, instagram and whatsapp absolute garbage when it comes to UX and frontend design?

I spend a lot of my day in CSS so I don't see CSS specificity as any sort of issue and if anything I appreciate it. But its interesting how often I see devs complain about it and try to get rid of it in these libraries.

This looks a lot like Panda CSS

must be nice for the guys at facebook to just experiment with different things while us normal devs use solutions to reduce the time spent because out boss breathes down our neck to finish things faster

this look like react-native and styled-component ........i like tailwind cause i don't have to name a class name or a component so meh for me

Day 102 trying to convince Theo that a moustache is not the one. If it's a bit on how Prime goes with the moustache, it suits him much better 😂😂

This just feels like regular CSS except you get to write it from within JS... imo totally pointless

doesn't vanilla-extract already provide this functionality? or am i missing something?

This is not a new pattern at all. There has been JSS since couple years already... And now there are bunch of others as well...

It doesn't scale lol? haha it's the definition of scaling with modeler components and tailwind.configs ...

Isn't this similar with styled-components?

Let’s invent the wheel that’s all facebook can do 🤦🏼‍♂️🤦🏼‍♂️🤦🏼‍♂️

Cascading layers have fixed the styling order issues