@@andrueanderson8637 its like stealing a girlfriend... so this isn't going to takes developers from tailwind, at least not ones that care more about dev experience than shareability
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.
And this is exactly the reason why tailwind is a no-brainer. It’s better than bootstrap, easier to write with. If you need to reuse styles, just put them into string variable and use interpolation in classname. The only drawback to that approach is that you’ll need to name it something. And that you have several pieces depending on the same variable, but that’s fixable by overriding what’s needed
@@andrewkosenko2757 The comparison with bootstrap is offensive at this point, Bootstrap provides uncostumizable components tailwind gives you classes to use like pure css, there's nothing in common
It seems like with stylex, you are allowed to just repeat yourself, so you may not have to come up with uniformed names... If your resulting style object is the same, it will compose the same way, regardless of its name. During pre-compilation, style objects with the same props and values end up with the same css class name across the project.
@@boenrobot you will still have to create names for unique things, which is an overhead, tailwind allows you to remove this overhead completely AND is still mostly easily readable (except some obscure cases with millions of props per div)
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.
@@seghirissam2662 and this is why the warning from @Drybones111 is justified. Too many devs jump on every hype train and cause massive amounts of tech debt, bloated slow applications for the end user, and tonnes of friction on starting up new projects. Nothing wrong with using this or React, but the caution is to introduce new tech when/IF you need it.
@@seghirissam2662 Sure, but it turns out React is a steaming pile of garbage that is dragging the frontend ecosystem to a standstill for a lot of developers
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.
The whole time I watched this I was thinking the same thing. I recently made a couple of SvelteKit apps and just rolled with the component scoped css + a global file. All this over-engineering to avoid writing css seems a little ridiculous. Even at work, where we have a very large codebase, the internal component library was completely done with styled components, which is basically just giving you scoped css in a Reacty way. The premise of “writing css is confusing/not scalable/time consuming” really isn’t true if you… know how to write it.
if you think that plain scoped css is good, then your are definitely missing what tailwindcss can do for you. which is basically the same as plain CSS but with super-mega-dupper powers. No, seriously, if you take the time to play with it you'll see.
ScopedCSS does solve some of the same problems Tailwind solves but not all of them - the main one being that with ScopedCSS 2 components with similar CSS will create 2 separate CSS "modules". That's not the case with Tailwind, ALL of your styles are reused do to its atomic nature. This leads to smaller bundle size.
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.
Yeah, but there was a big disclaimer over that section... that might have been one person's spur-of-the-moment judgment, thinking "well, the actual CSS rules are elsewhere". So maybe they'll change that. To me, Tailwind has BETTER colocation... the styles are on the elements, not just in the same file.
@@MarkJaquithThat’s exactly what it was. That table is the least complete part of the docs. It’s not released yet, I was just trying to get some early feedback. PandaCSS checks all the boxes too for example.
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.
Nope. Using just CSS is fine but when building out reusable components you need a library to help you out and speed up the development. Personally, I rely on CSS/SCSS modules and Tailwind to keep it simple but libraries like this are great for building reusable component libraries.
It's really strange hearing Theo say @17:09 that the way css cascading works isn't intuitive at all... I think the only way that viewpoint makes sense is if you learned tailwind before learning normal css. It makes perfect sense if you've ever written more than one .css file. I do get that Tailwind makes this more confusing, because Tailwind creates an extra layer between the developer and the actual css. I can even see how styleX's approach could make css cascading a lot more simple(like many other css-in-js solutions). But saying that css cascading isn't intuitive and doesn't make any sense is pretty dang silly. Yes a css library like this might make things easier, but in no way is css cascading "nonsense".
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!
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
That's what I do in svelte with postcss & tailwind. I can just do .myclass { @apply px-2 py-1 text-lg } to apply a long list of tailwind classes under my own class name. Just makes writing styles a lot faster (and it's still in the same file as the markup and scripts)
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…
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
Another difference is that you can reuse names since they are bound to their own scope. This means you don't have to use methodologies like BEM just to have understandable CSS.
@@CottidaeSEA With CSS modules (or vanilla CSS @scope) you can achieve the same behavior where the style you define only applies to the component/element tied to it without fear of affecting other elements even if they share the same class names.
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.
Yeah, them saying "It is currently impossible for a child element to have conditional styles when it's parent is hovered, we already have some ideas to make these patterns possible in the future," was really weird IMO. Disabling one of the core feature of CSS to potentially reinvent it afterwards?
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.
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
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 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.
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.
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.
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.
I don't get it also, when I saw the video title I thought "oh! something to challenge tailwind and be possibly better? I have to check it" and then I see 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?
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.
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
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 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‘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.
Me too, I only use emotion or styled Components. By using these the best thing I get is naming it always forces me to create good names and also all the class name crap is removed and only important stuff are visible in main component
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.
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.
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
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.
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?
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.
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.
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.
- 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
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.
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.
We've recently migrated one UI library from Stitches to Panda and I'm in love with what Panda did to improve on Stitches. I strongly believe that it's a peak CSS-in-JS solution that's statically compiled, especially and specifically for building component libraries. Stylex looks to me like it can get ugly real fast when building a UI lib.
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
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
This just feels like another extra unnecessary step. We're going backwards to create names for classes and then in the code/component, we'll have to look up the classname, find where that classname is declared, update it and then check if anywhere else has been affected. Tailwind may not be perfect, but if everything is split into components, you can be reassured any style changes will only affect that specific block
So True! Just reading this giving me PTSD look up the classname, find where that classname is declared, update it and then check if anywhere else has been affected.
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.
![Ice On My Teeth - ATEEZ エイティーズ 에이티즈 [Music Bank] | KBS WORLD TV 241115](http://i.ytimg.com/vi/c-n92OgbbwA/mqdefault.jpg)
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.
cut their lunch? never heard that phrase, is that a bad thing?
@@andrueanderson8637 It doesn't even come close, is what it means.
It translates to "Make a move on someones territory". Typically used in the pejorative but not in this case.@@andrueanderson8637
@@andrueanderson8637 its like stealing a girlfriend... so this isn't going to takes developers from tailwind, at least not ones that care more about dev experience than shareability
@@andrueanderson8637meaning it can't compete with tailwind
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.
finding correct names for the components is enough of it self lmao
And this is exactly the reason why tailwind is a no-brainer. It’s better than bootstrap, easier to write with. If you need to reuse styles, just put them into string variable and use interpolation in classname. The only drawback to that approach is that you’ll need to name it something. And that you have several pieces depending on the same variable, but that’s fixable by overriding what’s needed
@@andrewkosenko2757 The comparison with bootstrap is offensive at this point, Bootstrap provides uncostumizable components tailwind gives you classes to use like pure css, there's nothing in common
It seems like with stylex, you are allowed to just repeat yourself, so you may not have to come up with uniformed names...
If your resulting style object is the same, it will compose the same way, regardless of its name. During pre-compilation, style objects with the same props and values end up with the same css class name across the project.
@@boenrobot you will still have to create names for unique things, which is an overhead, tailwind allows you to remove this overhead completely AND is still mostly easily readable (except some obscure cases with millions of props per div)
this is literally how you do styles in react native
haha fr
was about to write the exact thing @@halilsmith8162
which I'm really pleased about, I really don't like the Tailwind approach personally
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.
Just remember facebook create react to solving their problems too
But you used it any way or other developers used it
@@seghirissam2662 and this is why the warning from @Drybones111 is justified. Too many devs jump on every hype train and cause massive amounts of tech debt, bloated slow applications for the end user, and tonnes of friction on starting up new projects. Nothing wrong with using this or React, but the caution is to introduce new tech when/IF you need it.
@@seghirissam2662 You made my point for me.
@@seghirissam2662 Sure, but it turns out React is a steaming pile of garbage that is dragging the frontend ecosystem to a standstill for a lot of developers
@@seghirissam2662 React is unnecessary for most websites, so I do not see the issue.
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.
The whole time I watched this I was thinking the same thing. I recently made a couple of SvelteKit apps and just rolled with the component scoped css + a global file. All this over-engineering to avoid writing css seems a little ridiculous.
Even at work, where we have a very large codebase, the internal
component library was completely done with styled components, which is basically just giving you scoped css in a Reacty way.
The premise of “writing css is confusing/not scalable/time consuming” really isn’t true if you… know how to write it.
if you think that plain scoped css is good, then your are definitely missing what tailwindcss can do for you. which is basically the same as plain CSS but with super-mega-dupper powers. No, seriously, if you take the time to play with it you'll see.
ScopedCSS does solve some of the same problems Tailwind solves but not all of them - the main one being that with ScopedCSS 2 components with similar CSS will create 2 separate CSS "modules". That's not the case with Tailwind, ALL of your styles are reused do to its atomic nature. This leads to smaller bundle size.
Tailwind is a lot less fancy than SCSS lol, but I agree Stylex is just like all the other css in js solutions: overengineered
I can not live without tailwind now. Why make your life harder without it
I think this is great if you are making a component library. For apps, I will stick with Tailwind.
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😁
ReactJS from FB is enough :))
I still like tailwind more😅, as It maintains sweet spot between convenience and scalability.
This feels very similar to SCSS modules used at a component level.
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.
Yeah, but there was a big disclaimer over that section... that might have been one person's spur-of-the-moment judgment, thinking "well, the actual CSS rules are elsewhere". So maybe they'll change that. To me, Tailwind has BETTER colocation... the styles are on the elements, not just in the same file.
@@MarkJaquithThat’s exactly what it was. That table is the least complete part of the docs. It’s not released yet, I was just trying to get some early feedback. PandaCSS checks all the boxes too for example.
I really think libraries themselves should have these sorts of docs exploration videos on their sites, so good.
what difference between this and styled-components, I can see this is 99% similar with 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.
lol yes I feel the same.. instead of just using css.. just because people don't know how to name elements or just don't even know how to use css.
Nope. Using just CSS is fine but when building out reusable components you need a library to help you out and speed up the development.
Personally, I rely on CSS/SCSS modules and Tailwind to keep it simple but libraries like this are great for building reusable component libraries.
@@axa993 How exactly does this make it easier than just using css modules for scoping and a package like classnames to do dynamic classes?
It's really strange hearing Theo say @17:09 that the way css cascading works isn't intuitive at all... I think the only way that viewpoint makes sense is if you learned tailwind before learning normal css. It makes perfect sense if you've ever written more than one .css file. I do get that Tailwind makes this more confusing, because Tailwind creates an extra layer between the developer and the actual css. I can even see how styleX's approach could make css cascading a lot more simple(like many other css-in-js solutions). But saying that css cascading isn't intuitive and doesn't make any sense is pretty dang silly. Yes a css library like this might make things easier, but in no way is css cascading "nonsense".
Using css feel like driving bicycle vs tailwind is like a car
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!
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
That's what I do in svelte with postcss & tailwind. I can just do .myclass { @apply px-2 py-1 text-lg } to apply a long list of tailwind classes under my own class name. Just makes writing styles a lot faster (and it's still in the same file as the markup and scripts)
@@zbik but post css may need to do cleanup for those duplicated and overwritten classes, not sure if it does that
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.
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 believe the StyleX styles are also in one file? Unless you mean something else.
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…
There's something that ships the newest CSS features even more BLAZING fast
plain ole CSS 💨🔥 🚀
Facebook can’t do that because they support old browsers so can’t always keep up to cutting edge CSS features
I really do envy RUclipsrs in the front end dev space. They get a continuous stream of new frameworks for their content :)
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
Another difference is that you can reuse names since they are bound to their own scope. This means you don't have to use methodologies like BEM just to have understandable CSS.
@@CottidaeSEA With CSS modules (or vanilla CSS @scope) you can achieve the same behavior where the style you define only applies to the component/element tied to it without fear of affecting other elements even if they share the same class names.
Thanks for the feedback! I just updated the website based on it.
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.
Yeah, them saying "It is currently impossible for a child element to have conditional styles when it's parent is hovered, we already have some ideas to make these patterns possible in the future," was really weird IMO. Disabling one of the core feature of CSS to potentially reinvent it afterwards?
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.
MUI has this exact thing already with the sx prop and theming
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
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.
Man I agree with this. I wonder if these companies just shell out money to get the coverage
Isn't that just Microsoft's Griffel?
isnt this the same as stylesheet in react native?
Alternative video title: frontend continues to go downhill
Tailwind was already stupid enough
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.
Great video! This is an indirect way of teaching people how to go through documentation and what line of thought to follow.
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.
5:32 “it’s super counterintuitive” - talking about CSS (CASCADING style sheets)
We need an update of this video
This is just CSS with extra steps.
doesn't vanilla-extract already provide this functionality? or am i missing something?
Cascading layers have fixed the styling order issues
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.
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.
its just like old you declaring your custom class name, but now in fancy way 😌
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.
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
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?
Looks like better css modules more than better tailwind. I really like it!
Definitely sticking with tailwind, but thanks for covering this.
Yeh I’m still missing the point in this, it’s just styled components v2…
I was thinking the same, but I guess the difference is that this is framework agnostic. But then again, so is CSS.
I don't get it also, when I saw the video title I thought "oh! something to challenge tailwind and be possibly better? I have to check it" and then I see 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?
Elon’s gonna be pissed when he finds out Zuck is naming his new css-in-js styleX
Fb announced StyleX way back React Conf 2019 😅
@@denniscual4618 damn so that must be where Elon came up with the new name for Twitter!
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.
it looks soo much like how react first tried to include styles
I thought this was 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
Seems interesting, but I love not having to think of names for classes when using Tailwind.
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 always thought react native styling is superior. This looks the same. Good
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.
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).
Isn't this similar with styled-components?
What makes you think this project is about to come out? Wasn't it abandoned years ago?
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...🤣
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.
Me too, I only use emotion or styled Components. By using these the best thing I get is naming it always forces me to create good names and also all the class name crap is removed and only important stuff are visible in main component
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.
A global CSS module file may get you exactly what you’re looking for.
Just use a global css file?
Can you do a video on pocketbase? I would like to hear your thoughts
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.
How is this not just a worse version of css modules with the classnames package?
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
I think i really need a very good explanation about what is the “scale/scaling” mean!!
what is the deference between styled component
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.
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?
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.
Probably will see some people use both tailwind and stylex.
how different is it from the now defunct Stitches library
The implementation looks exactly like MUI v4 makeStyles
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 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!?
Usually I’m using Stitches for styles with Framer Motion for animations. What would be the #1 reason to consider StyleX?
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 concur
- 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
This just looks like we are back to regular css but with extra steps.
What is even the whole point of this library? We already had something similar with JS styles
I would like to see a section called “these problems are we solving in 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.
Variable overrides is effectively Tailwind Merge plugin?
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.
Why is this different from material ui useStyles?
You can do this pattern with emotion CSS already:
const classes = {
myClass: css`
color: red;
`,
myConditionalClass: css`
color: blue;
,
}
return ...
Lol right, I was gonna say this just looks like Emotion-lite.
We've recently migrated one UI library from Stitches to Panda and I'm in love with what Panda did to improve on Stitches. I strongly believe that it's a peak CSS-in-JS solution that's statically compiled, especially and specifically for building component libraries.
Stylex looks to me like it can get ugly real fast when building a UI lib.
Ugly how?
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
will be nice if we can define container like tailwind instead of CSS
container: "flex items-center justify-center text-8xl"
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.
SCSS with modules is the sweet spot for me.
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
This just feels like another extra unnecessary step. We're going backwards to create names for classes and then in the code/component, we'll have to look up the classname, find where that classname is declared, update it and then check if anywhere else has been affected. Tailwind may not be perfect, but if everything is split into components, you can be reassured any style changes will only affect that specific block
So True! Just reading this giving me PTSD
look up the classname, find where that classname is declared, update it and then check if anywhere else has been affected.
@@zdeneksc2895That’s just not how it works though
Feels a lot like like writing React Native/CSS-in-JS. Tailwind is still the best option.
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.