StyleX – Meta's styling library
stylexjs.com
stylexjs.com
> We created StyleX not only to meet the styling needs of React developers on the web, but to unify styling for React across web and native.
Meta friends, the names "Review" and "Restyle" were right there.
https://stylexjs.com/docs/learn/thinking-in-stylex/#framewor...
I wouldn't be surprised if they avoided starting with "re" on purpose to avoid it seeming like this was a react only framework.
I like it a lot. It lets you define a theme with design tokens like spacing and colors, then enforces using only those via TypeScript (with an escape hatch via style prop), which also gives you editor autosuggest support without hacks like the Tailwind extension.
https://stylexjs.com/docs/learn/thinking-in-stylex/
> There is no runtime overhead here
Specifically
> No runtime style injection.
There's still a runtime though
> Optimized runtime for merging class names.
We don't think the Tailwind way of styling is readable in the long term, but we see the value is being able to author that way. We're looking into a VS Code plugin, that would let you author your styles inline and extract them out when you save.
I mentioned below, I do this with mui sx right now when <= 4 styles
E.g. sx={{ alignSelf: 'flex-end' }}
I think the reason it works so well is the same reason people love tailwind (it's all in one place), so the plugin would be helpful but still take away from that workflow when it comes to reading and maintaining.
What do you mean "inline style prop," writing CSS in the HTML style attribute? That's a nightmare to manage across large apps, not composable or reusable, and this library compiles to performant styling (according to the authors/examples).
For example, I've been using it to remember shell commands and options. Now whenever I have to search for an option that I think will be useful in the future, for example `-M/--max-columns` for ripgrep, I put it in Anki (question: "Ripgrep: Search for 'clukay' and don't print columns longer than 200 bytes", answer: "rg -M/--max-columns 200 clukay"). Each day I review my cards (~5/10 minutes at most). I used to not be able to remember an option like that that I use once a week, but now I can.
For more info on how to use it effectively, I've found https://borretti.me/article/effective-spaced-repetition to be really helpful.
In addition, with robust IDE support, you can type the css attribute and get autocomplete suggestions for the relevant utility.
> you only have to memorize the names once
Yep! After that it's as simple as dark:hover:md:motion-reduce:text-base/7
> you never have to think of a class name again
Unless you're using Tailwind's custom themes, arbitrary groups, peers...
https://mui.com/system/getting-started/usage/#performance-tr...
i don't want to reuse or compose my styles, i just want to add alignSelf: 'flex-end' and then easily be able to change it and see the styles in one place, without leaving the component definition. the reusability and composition is at the component level
Not trying to hate on atomic CSS, composable classes and style tokens are good. Even one of the devs on this project commented on them here:
> We don't think the Tailwind way of styling is readable in the long term, but we see the value is being able to author that way
https://news.ycombinator.com/item?id=38540629
The docs here mention the downsides though.
Not at all, mui gives you the option to do either.
I don't want my style library being opinionated about my coding style.
This certainly inspired no confidence in that.
All I will say is that CSS has gotten a LOT better in the past 5 years and for almost every scenario I can think of you would be in such a better position if you just spent a month learning that rather than this new abstraction.
https://www.joshwcomeau.com/css/interactive-guide-to-flexbox...
I think this resource is pretty well put together from the Chrome dev rel folks https://web.dev/learn/css it obviously goes from 0 so you can pick and choose what parts make sense for you but based on both my own experience and after having talked to many others in the same scenario, if you feel like you never really “got” CSS with any sense of confidence I’d say start at maybe reviewing the box model and going on from there precisely because so much has changed all over the place since then.
How we think about layout is totally different, how we think about positioning is different, how we measure things is new, even things like colour have totally changed in big ways.
But more concretely I think a lot of the reasons that people had particularly bad experiences with CSS in the past that drove them towards things like this or Tailwind for example are now solved problems and that both this and Tailwind are kind of obsolete in many senses.
Keep in mind that this system while it was released publicly today is actually rather old technology and was built around solving a problem in a very specific way that makes a lot less sense now because it was solving problems that now have native CSS solutions with great cross browser support.
That said, we don't actually use the feature that much, vs. higher-level logical props like `<MyButton compact />`.
I know we're supposed to use build-time CSS-in-JS these days, but afaiu they don't support the rare-but-handy "just spread together ~4-5 different object literals from ~random different conditionals + props", i.e. intermixing styles some inside the component + outside the component, which emotion handles really well.
Basically this [2]. StyleX says it does "cross-file styles"...but can it support that? I kinda assume not, but I'm not sure.
[1]: https://github.com/homebound-team/truss#xstyles--xss-extensi...
[2]: https://github.com/homebound-team/beam/blob/main/src/compone...
I made Tamagui a hybrid of compile and runtime, where the optimizing compiler actually handles object spreads, conditional logic, and even cross-module imports. It's really nice to get the near-0-runtime performance while maintaining all the benefits of dynamic styles.
We're continuing to work on optimisations for StyleX, and I'll be looking at Tamagui for inspiration!
"Since StyleX depends on ahead-of-time compilation, it is important for all your styles to be statically analyzable"
"No runtime style injection."
"All styles are bundled in a static CSS file at compile-time."
---
By dynamic styles I assume we're talking about something like this:
{ backgroundColor: props.thirdPartyColor ?? randomColor() }
You can import many different styles and apply them conditionally etc.
Also, completely dynamic styles are supported. We were inspired by Linaria's solution to generate CSS vars and set their value with inline styles.
[0] https://stylexjs.com/docs/learn/ [1] https://mui.com/system/styles/basics/
Plus, I find with v5, I never touch `makeStyles` / `styled`, the utility props / sx are enough.
> just slows everything it touches to a crawl
The docs call out how there's little to no overhead with the runtime.
Is any part of your comment related to this library specifically? Or just CSS-in-JS?
They mention why I should choose it over BEM or Tailwind, why choose it over MUI though?
createTheme() (from this library) seems clunky too, but makes sense.
This appears to place more emphasis on static typing, and has less strange syntax (think of "shorthand" in Griffel).
The docs steer you away from atomic CSS, whereas Griffel's embraces them.
There are some meaningful differences in the API choices, but the high-level design is pretty much the same.
But I have, in a fairy large project (completely rebuilding all of Deere & Co's internal systems, upgrading from literal terminals to web app) with >100 developers merging in hundreds of PR's a week.
We've never needed something like this.
> <!--[if lt IE 7]>
I think that site could benefit from something like this. The CSS on that site is, um, not optimized.
Do you ever just re-read your replies and think "I'm being ridiculous" and decide NOT to post it? You should do that more often.
- No global styles stomping on each other, styles scoped to a single module unless explicitly exported/imported
- Type safety, if using TypeScript
The main downside is often performance, though
Although I’m really in love with @emotion/css where I can still write and copy paste css-snippets instead of translating into js object syntax.