Facebook Tried Tailwind, Then Built This Instead
Вставка
- Опубліковано 5 вер 2024
- Much more into StyleX than I expected. Genuinely hyped on their philosophy and general direction. Learned all the right lessons from Tailwind, Vanilla Extract, Styled Components and more. Turns out the React team really does pay attention 🤣
Link to the site stylexjs.com/
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Ph4se0n3 for the awesome edit 🙏
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)
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
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.
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 prefer Tailwind😁
ReactJS from FB is enough :))
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.
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...
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!
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.
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 think this is great if you are making a component library. For apps, I will stick with Tailwind.
I really think libraries themselves should have these sorts of docs exploration videos on their sites, so good.
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
a different way to write classNames basically
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
I still like tailwind more😅, as It maintains sweet spot between convenience and scalability.
I really do envy UA-camrs in the front end dev space. They get a continuous stream of new frameworks for their content :)
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.
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.
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
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!
what difference between this and styled-components, I can see this is 99% similar with styled-components
Alternative video title: frontend continues to go downhill
Tailwind was already stupid enough
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
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?
Thanks for the feedback! I just updated the website based on it.
5:32 “it’s super counterintuitive” - talking about CSS (CASCADING style sheets)
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
Cascading layers have fixed the styling order issues
Great video! This is an indirect way of teaching people how to go through documentation and what line of thought to follow.
- 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
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.
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
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
it looks soo much like how react first tried to include styles
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 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.
Definitely sticking with tailwind, but thanks for covering this.
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.
This is just CSS with extra steps.
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 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.
Looks like better css modules more than better tailwind. I really like it!
its just like old you declaring your custom class name, but now in fancy way 😌
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.
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?
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
For me it`s a kind of styled component 🤔
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.
yoo nice batik for batik day
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‘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
Seems interesting, but I love not having to think of names for classes when using Tailwind.
You are hyped a lot. And when you’re hyped I am hyped.
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.
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.
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.
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).
I always thought react native styling is superior. This looks the same. Good
It seems really close to Panda CSS
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
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.
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?
As someone who would rather chew glass than write tailwind, I appreciate this. Reminds me a bit of Mantine's approach via Emotion.
We need an update of this video
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.
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 ...
Lol right, I was gonna say this just looks like Emotion-lite.
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
SCSS with modules is the sweet spot for me.
What makes you think this project is about to come out? Wasn't it abandoned years ago?
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.
In everything, we've lost the wisdom of attempting to do something at the most basic level and only applying complexity when it's needed. Instead, we take for granted that we need a large, convoluted ecosystem of tools to accomplish everything, which most often results in denial about the cost of maintaining that ecosystem not being worth the benefits it provides.
isnt this the same as stylesheet in react native?
Probably will see some people use both tailwind and stylex.
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.
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.
Isn't that just Microsoft's Griffel?
Last I checked the eslint validator didn’t work at scale.
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
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.
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 really don't get this 'doenst scale' thing... It really doesnt make sense.
"When I deep dive" - means "when facebook send me money"
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?
This just looks like we are back to regular css but with extra steps.
will be nice if we can define container like tailwind instead of CSS
container: "flex items-center justify-center text-8xl"
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
This looks a lot like Panda CSS
I'm in love with vanilla-extract
I would like to see a section called “these problems are we solving in css”.
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 😂😂
Probably never going to use it but good to know!
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
Feels a lot like like writing React Native/CSS-in-JS. Tailwind is still the best option.
I think i really need a very good explanation about what is the “scale/scaling” mean!!