> StyleX is a CSS-in-JS solution, not a CSS-in-React solution. Although StyleX been tailored to works best with React today, It's designed to be used with any JavaScript framework that allows authoring markup in Javacript. This includes frameworks that use JSX, template strings, etc.
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.
I really enjoy when libraries or languages have a “Thinking in X” post of some kind. I find it really helps orient me once I actually get to writing some code. If anybody has any “Thinking in X” examples that you have found particularly useful, let me know!
It was React Conf 2018 in Nevada when they first talked about StyleX and said they planned to open source it. Though I thought it was going to come much sooner than 5 years, I am so glad it has been released! 2018 was peak css-in-js era and StyleX approach of deduping classes and remove runtime JS was a really performant approach and it sounded like the DX was nice as well.
Just at a cursory glance, this looks pretty verbose and clunky. Existing React ecosystem styling solutions are many, so it’s not immediately evident to me when you would accept the trade offs introduced by this tool over any existing ones that seem much nicer to not only integrate, but also have to work with day to day.
You'll be glad to hear that MUI is zeroing in (pun intended) on a zero runtime solution right now as an alternative to Emotion [0], although that GitHub issue doesn't capture just how far it has come. Expect more soon!
This looks interesting and I'll play around with it. It will be tough to replace CSS modules and plain CSS for my React apps though. CSS is so much better now. Did you know you can nest in CSS natively now?
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting
Hey! I'm the maintainer of StyleX and I just wanted to say that you would probably like PandaCSS or Tamagui.
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.
Fair enough, that would be a good start. I just see such a smooth workflow in being able to do styles for elements with only a few custom styles inline.
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.
You already have to name your CSS classes, and atomic CSS libraries are chock full of names you must learn.
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).
To anyone for which learning lots of names of things that you use semi-frequently is a bottleneck: you can use spaced repetition (https://en.wikipedia.org/wiki/Spaced_repetition) to remember them way more easily. I use Anki (https://apps.ankiweb.net/), SuperMemo is another option (with other features, and lots of interesting articles on their website).
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.
Nitpick, but most atomic css libraries name things fairly consistently. In addition, you only have to memorize the names once. After that learning curve, you never have to think of a class name again.
In addition, with robust IDE support, you can type the css attribute and get autocomplete suggestions for the relevant utility.
So we're told every time. Is it "2xl" or "xxl" for the breakpoint again? It depends on the library (hopefully you didn't customize it!). Was it Tachyons or Bulma that has "ns" for "not small?"
> 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...
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
Part of me was holding out hope that React and it’s surrounding ecosystem might at some point end up back on a path that is somewhat more aligned with the rest of the web and had some meaningful sense of interoperability with everything that’s not React.
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.
I think Flexbox specifically
is around about the time a lot
of people last looked at CSS and it’s actually everything after that that I was referring to.
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.
Nice! We copied StyleX's "type-safe extensions" in Truss [1] so things like `<MyButton xss={Css.mt5.$} />` are allowed (setting margin is fine) while disallowing `<MyButton xss={Css.dg.$} />` (anything "not margin") that would mess up the components internal impl details with a compile error.
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.
StyleX is compiler-time only, so yes misses out on dynamic styles.
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.
I got the impression it was not dynamic values? Just that you can combine static objects dynamically. If I’m wrong I’ll re read the docs but someone else pointed that out to me and linked part of the docs that seemed to indicate that.
Cool, thanks Naman. It’s really great work overall, congrats on the launch. Maybe those couple places could have wording that indicates it supports dynamic as well.
It always surprises me the lengths people are willing to go to avoid writing CSS. If organization is the issue, there's BEM (https://getbem.com/). This just looks like another layer of complexity on top of an already convoluted front-end stack that just slows everything it touches to a crawl and only works moderately well on the developers beefed up latest MacBook Pro's, and sucks horribly on any regular person's computer.
waited a long time for this since they first demoed it at react conf 2018? in vegas. this was the last piece in the SSR + streaming + suspense holy grail. looks like the pieces are all finally done. congrats on the launch
I for one don’t. I appreciate the incredible amount of effort the developers put into it, but I really dislike the basic affordances as prescribed by Material Design and end up customizing it a lot… and it clearly show its limits the
React is one of these things that was designed to be unbeareable tonuse without custom syntax, but at least it is possible. This looks looks like it does not work without custom syntax at all. Type safety is a nice to have, but it should not need an exotic compiler plugin.
I'm assuming your question is loaded in an attempt to say "You haven't worked on any large teams then"
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.
Ah yes, a 5 year, hundreds of engineers, multi-million dollar project to take 1980's terminal computer ordering system for millions of Deere dealerships and bring it to the modern ages through a web app is just a simple crud app that barely needs styling.
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.
We're solving the performance pitfall of CSS-in-JS libraries by making a compiler instead. In the vast majority of cases, there should be zero runtime cost to using StyleX.
> 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.