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.

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

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

this is literally how you do styles in react native

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.

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!

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.

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.

I prefer Tailwind😁

Great video! This is an indirect way of teaching people how to go through documentation and what line of thought to follow.

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

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 really think libraries themselves should have these sorts of docs exploration videos on their sites, so good.

I just started using tailwind and rewrote small part of our product in tailwind. I felt in love with it. Haven't watched the video yet, but I hope it'll be usefull.

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

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 think its good that all these various solutions come up, there still isnt a difinitive solution to the disconnect of css from js and html but I believe we're inching closer to a proper aha moment.

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…

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

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

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

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.

btw in your opinion, as junior should i learn styleX for my portfolio? in terms of getting more chance to land a job.. ? or should i focus to learn different css framework?

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

Looks like better css modules more than better tailwind. I really like it!

Usually I’m using Stitches for styles with Framer Motion for animations. What would be the #1 reason to consider StyleX?

This looks very cool! Tailwindcss was resolving a great problem for me, reducing the styles size in my bundle, it's the best tool I've used so far for that. But Stylex seems to bring that promise while allowing us to keep our markup cleaner and the related properties grouped under a classname again. Yes, we would need to name things again, but I don't think that's a problem when we are just talking about a handful of classes per component. And furthermore, since they are scoped to the component those class names can even be repeated across components. On the other hand, I think many people here may be missing the point of Stylex. I don't think this is like emotion, CSS Modules + classnames, or like makeStyles in MUI v4. Sure, the syntax and UX may be similar, but that's it. Stylex is atomic, and the CSS output is static (like in CSS modules, but unlike emotion). Although looks like the may add some stable support for dynamic styles in the future. I'm not that into the idea of the "the last style applied always win". I get where the idea comes from, but on the other hand is counter intuitive when you are used to think in a different way. I guess i'ts just one of those nuances to get used to when using certain libraries. Overall, I'm very excited about this and to see how this project evolves. I love using tailwind, but I'd be more than happy to switch to something that wouldn't require me to define all the styles in the markup, and specially be able to compose and re-use groups of style properties again while still benefiting from using atomic classes in the bundled code.

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.

I am still using sass modules for pretty much everything. It works. I hate writing any media queries so a function does it all. I also use twbs /rfs for font sizes and container padding mainly. I don't know if I can do it without rfs in the future. I am just afraid that rfs might die one day.

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

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.

a different way to write classNames basically

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

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.

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

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.

I'm looking forward to when this is open sourced, and then we get some community packages that let you create Stylex styles in line and not name them. Then it would be really damn close to tailwind.

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.

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

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.

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

Sounds cool. But not having a solution for hover is a big gap in the capabilities. Unless they expect you to use the old css system for those?

Definitely sticking with tailwind, but thanks for covering this.

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

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

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

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

what is the deference between styled component

also not needing another lsp server for this is awesome, that is one of the greatest benefits of React's DX over Angular's in my opinion

The lack of styles-at-a-distance... Doesn't that mean that if you change the theme for example, your application now has to modify every single styled element in the DOM instead of just having the browser repaint the existing ones based on a top level class change? Or if you need to change the styling on every td in a table based on some toggle elsewhere in the application? The debugging concerns about styles-at-a-distance are certainly valid and it's a feature to be used with caution, but to throw it away entirely is something I'm very unsure about.

Seems interesting, but I love not having to think of names for classes when using Tailwind.

isnt this the same as stylesheet in react native?

what's the difference with this and CSS in JS?

Theo is good at saying what's in my mind. I like shadcn so much think whoever uses this to build a UI component library would make something crazily good to use. even better than shadcn

Probably never going to use it but good to know!

its just like old you declaring your custom class name, but now in fancy way 😌

Can you do a video on pocketbase? I would like to hear your thoughts

Cascading layers have fixed the styling order issues

It was nice to know about it

will be nice if we can define container like tailwind instead of CSS container: "flex items-center justify-center text-8xl"

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).

I like stylex features for the same reason I liked pandacss when it first came out, but switching from tailwindcss is no bueno for me. 1. I don't miss naming things 2. I dislike the object syntax for styles. Tailwind might be messy and repetitive e.g focus, active, dark mode states but it is still pretty readable. I can tell at a glance what classes are being applied on a component or easily debug issues. I really don't mind adding plugins like tailwind-merge and class-variance-authority.

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 is this different from material ui useStyles?

how different is it from the now defunct Stitches library

Variable overrides is effectively Tailwind Merge plugin?

Literally emotion. Wow..

I think i really need a very good explanation about what is the “scale/scaling” mean!!

We need an update of this video

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

SCSS with modules is the sweet spot for me.

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

yoo nice batik for batik day

What makes you think this project is about to come out? Wasn't it abandoned years ago?

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.

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.

As a big fan of CSS modules, this is going to be a great middle ground. Might even be easy enough to ditch PostCSS as well (particularly with PostCSS functions). Edit: wonder how it might integrate with something like stylelint too…

I'm in love with vanilla-extract

is this not same as unocss ?

I feel like i've been using this syntax for years with MUI and I much prefer it to Tailwind. Pretty sure it's built on emotion... Glad to see FB making this a standalone lib that is also static. The DX of MUI's style system is top tier IMO

I have just one question, like why the host is on vercel, and not on their servers! Like the meta has its servers!? Can someone respond to this!?

How is this not just a worse version of css modules with the classnames package?

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 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.

In TailwindCSS, CSS is the base knowledge, nothing more, except for the class names lol. Go to vacation and get back after 3 weeks, you likely dig again to MUI docs for reference or similar framework, It just too much of "cognitive overhead". To add, once the framework updates there are more to dig in to docs. Here's my top 2: 1. TailwindCSS for the win. 2. Styled-components

i like unocss, its plugins shorten a lot of styling!

This just looks like we are back to regular css but with extra steps.

I think this is the same think as Griffel which used by React FluentUI.

twin macro ? i'll never go back to write regular css again, so much time consuming. Stylex seems to go back in time.

Why not just use css? Because we found a way to make it more complicated. 😂 I found I dump to write html in js and now this.

The implementation looks exactly like MUI v4 makeStyles

You can do this pattern with emotion CSS already: const classes = { myClass: css` color: red; `, myConditionalClass: css` color: blue; , } return ...

Probably will see some people use both tailwind and stylex.

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

This is just CSS with extra steps.

How is this dress is this different from JSS.

Isn't this basically how react-native stylesheets work?

So its Unocss?

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?

Isn't this similar with styled-components?