StyleX: Meta's Solution To CSS At Scale
Вставка
- Опубліковано 8 чер 2024
- StyleX is Meta's new library that gives you the tools to make rock solid component systems at scale. StyleX has been in use at Meta for three years. Now it's open sourced. Learn all about how to build StyleX components today!
Code: github.com/jherr/stylex-demo
Original App Router Boilerplate Code: github.com/nmn/nextjs-app-dir...
👉 Upcoming NextJS course: pronextjs.dev
👉 Don't forget to subscribe to this channel for more updates: bit.ly/2E7drfJ
👉 Discord server signup: / discord
👉 VS Code theme and font? Night Wolf [black] and Operator Mono
👉 Terminal Theme and font? oh-my-posh with powerlevel10k_rainbow and SpaceMono NF
0:00 Intro
0:44 StyleX Basics
4:46 Restricting Style Changes
6:23 Can Tailwind Do This?
8:39 StyleX Themeing
11:30 Conditional Styles
12:21 Dynamic Styles
12:40 Outro - Наука та технологія
CSS in jsx is just big no-no. For super simple examples sure. Any bigger project and devs will cry because of unnecessary clutter this creates.
Debugging styles will also not be any fun. How much easier is to find a class than a stylex object that has the same keys repeated in every other component
Pretty sure I'd consider Facebook, Instagram, Threads, etc. as "big" projects with a lot of developers. And they use StyleX exclusively.
Yo have to be living in the stone age, CSS has become commnplace in the React world.
@@coherentpanda7115 They were using something like CSS modules before the complete rewrite that used StyleX for the styling. There was so much CSS in the original version that they had to dynamically load it, and that caused serious precedence problems as they styles being applied were dependent on the page/feature traversal order. Now they have 170Kb of CSS that drives the entire experience regardless of what you do and it's cacheable and once it's loaded it never needs to be reloaded.
The first version of the rewrite produced 130Kb and after three years of adding features it's 170Kb, so the velocity of size increase is ideal. StyleX handles intelligently reusing classes across a huge codebase.
The architecture is no different than CSS modules really. And finding the source of styles is pretty much the same as well.
@@jherr
Sorry Jack but this comment is meaningless and kinda rubbing me the wrong way so I will be a bit edgy with my reply. I apologies in advance but I will try to keep it short, don't want to mumble for too long.
These companies are the same company, lets be honest here. Also that does not speak of individual developer opinions.
I can see some of the benefits these css libraries provide but lets first get out of the way with the fact StyleX is not the first nor will be the last such library to exist, plenty more are out there - Styled Components, Emotion, Aphrodite, Glamor, Radium, Linaria, Stitches and they are pretty much the same things.
I get the appeal of why big companies would want to use such libraries having multiple developer teams working on dozens of projects each then fine makes sense. But you know very well most developers don't work at such companies.
State of CSS survey clearly also shows these css in js libraries are hugely in decline while css modules has been on top without a sign of declining ever.
So I don't even have to explain why these libraries suck, statistics already clearly indicate they are not great, and what I dislike about your comment is that kinda indicates like maybe we should all use these since 'BIG companies are using it'.
It infuriates me because I know a lot of Junior devs and potentially devs that havent even started will watch this and say woah this is great, Im gonna use it and later on regret it because chances are they will work at a place where as usual they will be using plain normal css/sass (as they should) and then they will hate it, because they think its archaic and bad so it must sucks.
Sorry for being kinda an ass. It is what it is.
Maybe we can draw a positive as I would recommend and I think you will find this also interesting when you are presenting new tech to also talk about who is that tech really useful and if for example juniors should mostly not sync their time in it for example. I think you should get the point. That would be quite insightful for other people.
This is awesome!!!!! Jack I just see you do a *fatal* mistake in every video and it's time I correct you. You always use the color "red" instead of "tomato". One big (and only) advantage of tomato is that it's funny every time. Please take this into consideration for your next videos.
I will indeed.
yay, tomato here is underrated indeed
Great ending! Stylex looks very promising
Great video, hopefully we start moving in the type-safe CSS direction again
Great video and Outro! :D
This is exactly what I have been looking for!
Panda is also another CSS-in-JS that generates CSS at build time
was unsure until the theme part, that's really cool. to do the same in tailwind is a bit of a mess to set up
Would have taken me some time to get it. Thanks for the succinct explanation.
Amazing Jack! Thank you
Finally! I've been waiting for it since it was announced 2 years ago 😀
I’m sorry it took us so long. A lot of the design decisions were completely changed for open sourcing. We didn’t want to release something where the core design wouldn’t be solid.
@@NamanGoel34No need to apologize. I'm glad it was open-sourced after all 😃
this is so much better than tailwind. all these comments have no idea what they talking about.
You should bring that special guest back!
This is great!
I love it Jack!!!
This is awesome! The only thing it's missing--IMO--is the ability to expose CSS custom properties from a component to allow styling from CSS in addition to the JS API. As a library author, the ability to expose both APIs helps to significantly increase adoption.
This is actually possible. You can use named variables as string in styles. We don’t recommend it because there is no easy way to catch typos etc, but you can do it.
You can basically achieve this in Tailwind using tailwind-merge + clsx + class-variance-authority.
(Plus you still get all of the benefits of Tailwind)
Great video though. Good to see great tools becoming open-source.
tailwind-merge is horrible for performance on large scale projects, so be careful with it.
We do not use it in our project and just get away with component variants props and some very rare !important on classes.
But when I tried to apply tw-merge to some common components (did it just to see how big the performance impact would be), the first render took A LOT longer, than the class combinations got cached. And it didn't matter that in 98% of cases the classes I passed didn't even need to be tw-merged, but since there is no way to know that, tw-merge does all its calculations anyway. tw-merge has to do a lot of splitting and, I guess, regex matches to determain which classes to keep and which to change in order to "merge" everything properly.
There are no benefits in tailwind, it’s unsupportable mess.
@@MrREALball I guess that's true, had some strange ick about tw merge. Just the idea of eliminating classes in tailwind itself is bizzare imo
@@buc991 we have a realy big project and it works perfectly for us and I don't see what could be the issue with it?
No type safety compared to css-in-js? It could be easily mitigated with eslint plugin. Merging is not an issue, since you shouldn't be doing that anyway (it is an anti-pattern) and prefer variations.
with tailwind you can accept values instead of classes and pass props into style as css vars like this style={{'--color': props.color ?? defaultColor}} so you can use them like this className="bg-[--color]"
You should not use bg-[--color] because the tailwind will not recognize the class and will not include it in the purge css file.
@@Pilosofia check the "Adding Custom Styles" section of the tailwind docs:
When using a CSS variable as an arbitrary value, wrapping your variable in var(...) isn’t needed - just providing the actual variable name is enough:
@@qqwwee8383 if you want to use CSS variables you should do bg[var(--color)].
Its been years and I am still to see any tool that comes even close to tailwind in writing CSS at scale.
Great outro haha
I dispute your claim at 7:30 - tailwind _does_ let you do that. Either with variants, shadcn/ui, OR you can do a more typescript driven way to expose different modes of a component to allow control.
The key is whatever solution you come to, the emitted tailwind css class names string has to be in your source code somewhere.
This.....
StyleX feels like v2 of vanilla-extract.
I don’t love NextJS or Vercel, but I do appreciate their influence leading to more interest in compile time CSS libraries.
This is Meta…
Vanilla-Extract has to be in it's own file, not written in the component. And is why I chose not to bother with it.
This has nothing to do with NextJs or Vercel.
My comment lacked context. One of the reasons we’re seeing more interest in compile time CSS is because it plays much nicer with SSR. Next is by far the biggest driver of React SSR adoption.
Would you ever do a tutorial on theming and customization in Material UI please?
In Tailwind this is normally done with variants. There could be a ready-made variant like "primary", "secondary", "destruction" etc.. Shadcn/ui does this in a very good way.
No shadcn does it poorly, it only supports single component variants no support for multi components. So 90% of the components can't use variants
I have made a custom version of shadcn ui which does support it by using tailwind-variants. This library is much better than cva as it has slots. I simply made a wrapper around TV that includes context so that you can define the styles from the root and pass them down to the children.
Have a look at park-ui, they have a similar solution except using panda
@@dawidwragaDoes it use radix ui under the hood?
@@VinayKumarSupervisor park-ui is using panda css + ark ui under the hood and it has a very proming future but Im not sure if its ready for prod.
My custom solution for adding variants to shadnc ui is using radix ui + tailwind-variants.
I am in the process of making a video on this topic to share it with more people as I've found a very nice solution that makes shadnc ui better
@@dawidwraga I also want to be shadcnui to be better customizable
See, here's the thing. I'm a CSS-in-JS convert over to tailwind and am loving it. Now that I've been exposed to the beauty of tailwind, I just don't know if I want to go back to writing "normal" css.
We, on the StyleX team, aren’t trying to convince all Tailwind users to switch. Tailwind has the same overall performance as StyleX and if the API works you, great! If you’re making heavy use of utility functions like `cn`, that could become a performance bottleneck, but otherwise you should probably stick to what you like. Our initial goal is to help devs transition away from anything that relies on runtime style injection.
@@NamanGoel34 Ahh okay. Well, thank you for the reply! That makes a lot of sense, I definitely support getting devs away from runtime injection. Keep up the good work!
Tailwind is just glorified inline CSS. I understand the appeal to juniors, but it quickly becomes an unmaintenable mess.
@@ipojuca22 I don’t think it’s a skill issue at all. I’d be willing to maybe give credence to that argument for large code bases, but that’s about it.
I like the idea of the overriding. But I understand that there is no theme and I have to create from scratch ? Is there a way to copy themes from somethere online and use it so that I don't have to create it ?
I'm also thinking of using Shad/cn with Tailwind. How do yo think if we compare StyleX with Shad/cn + Tailwind ?
Looks cool. But it also looks like it’s inlining all the styles. Is that true? Or does it compile it down to a stylesheet in the end?
Yes. It compiles to a single CSS file. The JS only contains class names after compilation.
Hey Jack, it would be great to hear your opinion on StyleX vs PandaCss, which you feel is better, or do they have different use cases? Thanks
StyleX to me is unique in it's exactness and restrictiveness. It's more exact in that you can't use shorthands like `border: 1px solid black` you have to set each attribute on its own. And the ordering of application of the styles is exact and defined. And it's restrictive in that you can specify exactly which attributes can be overridden in a shared component. Both of these traits are ideal for very big development efforts either in companies or OSS because in those environments if you really want a design system it's going to have to be pretty strict and other technologies make it too easy to work around them.
PandaCSS is an excellent build time CSS system that is less strict than StyleX. It also has good built in Tailwind style shorthands. A good list for smaller teams with less structuring requirements.
Hopefully that helps a little bit. What's your take?
Hey Jack, would love to hear from you how to implement it into qwik
Hi dad! Could I barge in ? Yep, my pleasure
. Well done, dad ;)
I wonder what vscode theme is this and also what font
It looks kinda like the StyleSheet in React Native
I wonder if any of those media query string can be intelli sensed…
I don't understand why the example given for TailwindCSS is a problem at @7:22.
Just restrict the allowed values into that particular prop that defines the background colour so that no one can "accidentally" pass a margin there instead of a background colour. Use Typescript and maybe a list of Enums populated by all possible TailwindCSS bg- colors? (I'm not a Typescript expert or even competent for that matter but it seems like this is one way of doing it).
Although I would argue at that point couldn't they just prevent that in code review? Or have a memo somewhere "don't insert random Tailwind classes into that prop that is literally called backgroundColor"?
I don't know... it seems like like such a non-issue in my opinion.
That's a ton of work just to handle all the possible colors for the typing. And that doesn't even factor in any custom colors you might have or generate.
@@jherr but wouldn't large scale projects already have a design system in place? In that case you would just define those custom colours in the Tailwind config file by extending the theme.
I haven't worked on such large scale projects so I trust your opinion. I just can't see the full picture of why this is better than Tailwind and why would people just accidentally pass different inappropriate classes to props.
@@murtadha96 It wouldn't be a mistake, it would be a feature team working around a "limitation" in the design system to satisfy their product manager or designer, by going outside the lines of the design system without consulting the design team to get clarification on the right use of the component. Do that enough times and you get a super bespoke design system which isn't really a system at all and which is super hard to maintain. Tailwind is a literal free-for-all in this regard.
Flipping it around to the positive, an enforced design system allows more folks to help build the UI since the components because if designers ask "occasional UI" developers to make structural changes to the components they can just say; "No. I can't do that. Talk to the design components team."
FWIW, the scale I'm talking about is at least 10 teams and at least a hundred developers and from there on up. Those are the levels of scale where you can't have someone looking at every single use of a component in a PR to make sure it's used the right way.
i didnt expected end of the video part. brought me smile. 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?
I think it's important to know a CSS-in-JS framework and in 2024 this is the best one.
@@jherr got it. thanks
string literal types could narrow it down at least on the type level, StyleX don’t do more than limiting on type level right?
love your videos Jack
This is not for small-mid/solo projects at all. More typing demands can tire your fingers and brain. The advantage of TailwindCSS is that it is straightforward, requiring less typing, so it's less tiring on the brain.
It should perform better but it requieres babel and for a nextjs project swc won’t be activated what actually makes the performance worse.
Is that what react-native use???… amazing content as always
Not yet on React-Native. It's coming though.
Thanks Jack ! Any links to styleX documentation?
stylex-docusaurus.vercel.app/
I dont see any benefit for style x above panda css. Let me me know if im overlooking something but it seems that its actually just a downgrade from panda...
Thanks Jack. Can this be useful for React Native?
Not at the moment. It's coming though.
Exciting
Thanks for that great explanation! But for me I see it as another CSS in JS library like Chakra UI, which is coming with its performance overhead on both bundle size, caching of the styles so it will be great if you explain more about its bundling and performance point of view.
Also I need to highlight a point that you mentioned, it gives good constraint for the component input props so that is a great win but also it leave the internal implementation of the component itself not restricted to a design system which makes me prefer tailwindcss.
By the way I was able able to achieve the same for a design system ecosystem that I am working with tailwindcss. I gave restricted type to the input props that I am using for the component as following:
type myConstraintClasses = `m-${number}` | `mt-${number}` | `mb-${number}`
myLayoutClassName: myConstraintClasses | myConstraintClasses[]
That way I restrict the developers to misuse the component
This is a build-time CSS-in-JS solution, there is no performance or bundle size impact. Actually the opposite the performance is as good or better than Tailwind because of the limited number of classes (usually one) applied to an element.
7:22 yes, it's true that Tailwind does not allow you to do something like this... but what prevents you to step outside Tailwind and use regular style props as an interface for customizing design system built on Tailwind?
Performance?
@@jherr I don't know enough about it, can you tell me more please?
@@sadkebab If you apply styles at runtime you are going to cause a lot of unnecessary re-painting. Styles directly on a specific tag should be reserved for genuinely dynamic styles (e.g. top, left, width, height, etc.)
@@jherr ok I think I understand, I guess this is caused by the virtual dom logic in React, so I guess it's only a React related issue or am I wrong?
@@sadkebab No, tweaking a style attribute in any framework is going to cause a re-paint. Plus you have CSS specificity issues. Really, honestly, I don't see that point. It's fine not to use StyleX. But it's also fine for StyleX to exist to fit it's market. And it seems more than likely that you aren't in that market. There's no reason why all styling has to be done with Tailwind. I like Tailwind. I use it in my projects. But I can see the need for alternatives when the requirements call for it.
Why is it, that it breaks in the official next example, when I remove the globals.css file?
I asked this already but pasted a link to my repository, sorry for that, I guess the comment was deleted because of it.
This is a limitation of the NextJS plugin. It needs that one css file. We’re working with the Next team at Vercel to try to fix this problem. This was impossible to do until StyleX was open source.
Also, there’s an issue with this exact problem on the repo that you can follow for updates.
thank you very much for your reply@@NamanGoel34
Can it be used in react native?
looks cool, but tbh for me I just like tailwind or scss 😐, but ofc I need to try it
it feels like we are being led to something universal: similar methods are used in react-native. correct me if I'm wrong
Definitely react-native support is in the works. Not sure if that means "universal" or not. I don't think there is any intention to make some kind of univerals CSS or something.
Can someone pls help to understand the difference between stylex and styled-components ? For me it looks almost identical
styled-components are runtime. this is build-time. huge difference in performance.
Thanks Jack for clarifying it.
JavaScript engineers will literally make a strongly-typed style framework before learning CSS.
Hmm stylex's documentation?
Cool. but to be honest. I'm a big a fan of SASS and i'd like to think off myself of being quite good at this . last year i've used tailwind + sass primairly and now on my job where we have a very big SaaS we use styled components. I really can not find the motivation nor see the purpose to yet again learn another flavour of styling which will get replaced in some months to years..
This is basically how styling is done in React Native
@jherr hi, writing this 3rd time in a row 😄 I guess your channel's policies are restricted to external links, thanks for the video as always, I'm currently looking for css framework to replace emotion in one of my projects, recently I've found a css-hooks (I was wanted to give a link, but I guess that's why my prev comment was gone), I feel like this one might be quite interesting to compare with newly open-sourced Meta's StyleX. If you can take a look and maybe share your opinion on it - I'd appreciate it, maybe community will be also interested in their approach
it's relatively new, but imo DX is great and looks very promising, so I'm thinking some noise might give it a favour.
I just looked at css-hooks. It's hard to compare from the documentation on css-hooks. It's pretty vague on how it works outside of the API documentation. And how it works is pretty important as well. Also css-hook is super new, has relatively low usage and a single contributor. So that's worrisome.
yes that’s all true, thank for taking your time
Does this library belong to Facebook Meta? is it new?
Yes and yes.
Não Tenho experiencia em grandes empresas. Não ficou nítido a do porquê usar StyleX ao invés de Tailwind
No vídeo ele demostrou… o stylex garante um controle muito maior e além disso ele tem uma typagem muita mais forte comparando com o tailwind
So someone could also put some incorrect value to a backgroundColor property and it will not work properly, it's not that StyleX will save you from doing something wrong. So why is it any better as you mentioned it in example with Tailwind approach? Pretty weird argument...
An invalid value for the color wouldn't work for the component consumer. So I don't really see the point of that one.
@@jherr the point is that in both approaches you can pass something that would work not as intended
@@antonbyrna3388 In the Tailwind case you can completely jailbreak the component and do whatever you want. That's not the case with StyleX. You could send an invalid value for an overridable style and the results would just be an invalid CSS on that one style attribute.
@@jherr again the point is that you can mess up with both approaches, but one gives you opportunity to customise your component freely when the another restricts it completely while still not preventing you from making an error
I'm not sure about the media query!
Sure about it in what way?
@@jherr Does it support responsive media queries?
@@MDABDULMOMINRiyadh Yeah, they work just fine.
Something like react native stylesheet styling
MUI
Another MUI with lots of rules and cumbersome code, maybe useful if u build your own UI library, but not for projects, even if you start a complex project u usually start with something easy like scss, styled components or tailwind, well mantine maybe if u are not too bothered by the design, but bringing such a monster into app will not be effective
Similar like Chakra ui
Any way we could get a set up tutorial, with a React Vite project?
An official Vite plugin is in the works. There are some challenges in making it work correctly with the dev-server. If you’re just working on a client-side React app, there is a package called `vite-plugin-stylex` created by community member already.
Good Video, But seems like too much work compared to tailwind.
Tailwind is already great at quick prototyping and authoring styles quickly. We’re optimizing for long-term readability and maintainability. We’ll see what we can do about typing quickly later.
Looks like a compute of cva + clsx nope 🤔😅
They basically fixed CSS-in-JS.
tailwind enough with little plugins. I don't know why i should use stylex
open sauced? where's the github repo?
It's alright but i'll stick to tailwind
Adopting Elon Musk's naming convention, X 😂
I'd use Flutter instead of that!
What's wrong with Tailwind?
Looks fake to me. Like 6:09 why he didn't show that vscode will give you a type error if you don't match the type? I'm not bothered to try, css in js is not for me
I'm not sure exactly what you are looking for, but there was definitely a jump cut for time. It's just not clear to me literally how this library could be "fake". Like honestly, anyone in the world right now can install this library and use it. How could that be "fake"? And why?
@@jherr Honestly I did not mean it "fake" literally just raising my eyebrows at that moment. He presented this type narrowing as an advantage, hence I would expect to show that you get IDE error otherwise the feature is useless.
Ah, gotcha. Yeah, I should have shown it freaking out about the wrong types if I added something else.
First😅
Regarding your comment about design system overrides. Shouldn't a design system disallow random color overrides like that? It seems like just letting devs override colors would lead to 50 different buttons, which makes design system pointless. For a general purpose library like MUI or Mantine I think it's ok because you have to cater to infinite color schemes, but for a company design system I'd say that doesn't make sense at all. I think a design system should have a prop like "variant" on Button and you as a dev just specify what variant you want to use from a set of predefined variants, instead of manually overriding something. Although I do have to admit I like how stylex handles themes, this vars approach inheritance looks great.
Regarding stylex in general, I was hyped when first information about this was released few years ago because I was excited for Facebook/Meta to finally release an official styling solution for React apps and end all css in js discussion. Unfortunately, seeing it now after few years, I'm not that hyped anymore because I've been using Tailwind for some time now and I'm really happy with that. Maybe I have to try stylex to see if I'd like it to make a proper decision.
It was an abitrary example. Picked primarily because colors don't effect the layout of the component.
@@jherr Understood!
I pass and will keep using tailwind :)
Wasn't it better to make a video about how tailwind avoids doing all this?
nice video except the screamer at the end that made me loose my shit
absolutely love what they're TRYING to do. But after using this for a commercial project. It feels extremely flakey and i muyst say I'm really disappointed.. They need to fix the issues to make this viable
looks like a React Native
Comparing it to TailwindCSS is not fair. Tailwind is good only for beginners who haven't learned real CSS. Better to compare it to other CSS-in-JS libraries like Emotion, StyledComponents, or MUI (React Material UI library) "sx" prop. When comparing apples to apples, StyleX is rotten. So verbose and boilerplate and awkward. I don't see any benefits.
Good luck with maintaining this in real world with limited resources. Also comparing this with tailwind to promote narrative of "how much better it is" is not fair as tailwind is, in solution terms, a different concept. This should be compared to, for example, CSS in JS, Styled components and so on.
I agree with the limited resources. If you are at a small company or at a shop where folks aren't sold on the idea of design system components then, yeah, that's gonna be a problem. It's still an invaluable tool for shops that actually can handle it and want the types of structure it provides.
And IMHO, I was pretty open about how Tailwind was very good for shops that aren't looking for a solution like this.
Just don't like CSS-in-JS one bit. Never works in the absence of design system which is majority of websites.
Ok. So what about the minority of sites that DO have a design system? Maybe we should evaluate this tool based on their needs, right?
@@jherr Yes. For those sites, this looks like a better solution than the currently existing css-in-js solution. In terms of performance, I have to check.
Wanna isolate your styles? Use css modules. Wanna decrease the css code size? Set up your bundler to make it for you ( minify, etc ).
If it is still a problem - split your app by chunks or microfronteds.
Actually I got tired if these new "css killer" technologies.
You can't "prevent" people from overriding styling on your component. All this crap does is encourage them to use hacks like !important or super specific targeting like "html body .some-el {...} " to override it. This is a shining example of solving a problem that doesn't need to be solved. And by "solving" it, you're actually making the issue worse when it inevitably causes end-users code to become littered with unmaintainable code to override your "fix".
Plus, this "fix" violates the conventions of how CSS works. One of the major points of CSS is that it can be overridden.
That is true, you can't prevent people from defeating stuff. You can't prevent folks from writing crappy code in React. But we still find value in React. Folks can do ts-ignore all over a codebase, or do force `any` for everything. But folks still use TypeScript.
We don't generally engineer around folks who are trying to defeat the system. We expect that reasonable engineers will want to properly work within a system that provides them value.
StyleX makes the styling API of a component extremely clear to consumers who want to use it properly.
Tailwind master race.
🫡
cool thanks, but tailwind is better
This feel way more complicated than it needs to be and encourages bad practices that are likely so deep into meta workflow they have to build a solution around it. You should always own the design, as soon as you allow a component style to be override you just lost, in the future you might want to do a rebranding and it will be a nightmare.
Tailwind might be less type safe but it keep things simple and let's you move much faster and stay consistent. Unstyled libraries + tailwind are here to stay.
Yeah, owning the design is exactly what's happening here. The infra team makes a button that has its own very clearly defined styling, theming overrides, and then provides a very clear limited set of overridables. Is it the colors being open ended that you have a problem with? If so that was a choice I made in the example. I could have done variants. If being able to rebrand reliably without code updates then this is the answer for you.
Im just not seeing anything new here, been using emotion for a while, and aside from the media selectors in the theme, theres really no improvement i can see here... i myself prefer string literal styles as youre writing pure css, it feels far less abstracted...
Emotion is runtime CSS, StyleX is build time CSS.
@@jherr I'd like to see the benefits really, usage wise i still prefer emotion, it feels easier and less abstracted - however I'd like to see the output difference being bundled at build time vs runtime
@@jherr also - styleX still has runtime logic - it would have to, to run dynamic update based on props/state, additionally, emotion is less than 20kb in size, i really don't see the benefit here so far, but thanks for the video anyways!
@@JlNGLEZ Right. It's a difference of being fully dynamic, like emotion, which doesn't work with the app router. Versus fully build time unless you opt into dynamic, but only for that specific component.
@jherr emotion still works with app router, dynamic imports - different approach I guess as it's prebundled the right way I guess, less overhead
Another CSS in js😅
is it if it compiles to css ?
@@jeffreysmith9837yep
Not quite, it has a build step that compiles all those styles into class names
It looks so cluttery, messy and confusing... not a good first impression. For gaining little bit of control, introducing tons of new bugs...
What bugs would it introduce?
I can see why really big projects might be interested but I hate it. Way too verbose. I'll stick with tailwind. Maybe a tailwind library that allows restrictions on overrides would be nice.
horrendous
why is it giving me this error: Uncaught Error: stylex.create should never be called. It should be compiled away.
at Function.stylexCreate
The syntax is ugly and cumbersome in my opinion, it made me remember Styled Components (the horror). I much rather using Tailwind or SASS with a good architecture.
HELL. NO.
so just MUI..
Ugh, yet another styling library.
Do we need the `import * as...` syntax? Can we just `import { create } from "@stylexjs/stylex"`?
You can.
is suckerberg a fan of elon musk by using the x letter like space X? lol