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