Comparison with existing solutions

[Dozalex]

Hello! There is a lack of comparison with existing styling solutions.

I use Linaria in my projects and don't understand how stylex could be better.

For example a syntax.

Stylex example from documentation

import * as stylex from '@stylexjs/stylex';

const styles = stylex.create({
  foo: {
    color: 'red',
  },
  bar: {
    backgroundColor: 'blue',
  },
});

function MyComponent({ style }) {
  return <div {...stylex.props(styles.foo, styles.bar, style)} />;
}

Same example with Linaria

import { styled } from '@linaria/react';

const Container = styled.div`
  color: red;
  background-color: blue;
`;

function MyComponent({ style }) {
  return <Container style={style} />;
}

Linaria syntax looks shorter and neater, especially if the component tree is larger.

Why were existing solutions not enough for you and this library was created? Why is it better?

[fredericrous]

I agree the devx is not appealing. I would also be interested to know how it compares to using @scope

image from https://twitter.com/argyleink/status/1732434431326216222/photo/1

[nmn]

@Scope is a great CSS feature but it's not an apples to apples comparison. It would solve "scoping" of styles, but you would have to write separate CSS for each component this way. This is fine, even better, for smaller apps, but for larger apps this means the CSS grows as your app grows.

Atomic styles are meant to cap the size of your CSS. After a while the size of CSS stops growing as you're simply re-using new combinations of the same classes.

[nmn]

There is a lack of comparison with existing styling solutions.

Yes, we don't want to speak negatively about the other styling solutions and we definitely don't want people to start migrating existing large projects.

Linaria is a great project and we've learnt a few lessons from them. As for why we made something new it comes down to a few small things:

1. We generate atomic styles. This is why we say we're better suited for larger apps. Linaria can do this too, but not by default. Some ex-meta people were responsible for adding atomic styles support to Linaria as they wanted to use something like StyleX before it was open source
2. Type-Safety: This is a trade-off. The syntax you prefer is what makes type-safety impossible. This was a trade-off we chose to make.
3. Compiler: StyleX's compiler can compile and cache each file individually. This helps solve the compile-time bottleneck for us internally. This may not be relevant to most non-massive projects.

Again, Linaria is great, and can be made to generate atomic styles. They're working with the folks from Microsoft on a new compiler toolchain that should improve build performance as well. If you don't care about the type safety of styles and you don't want to merge styles across files too often there is no reason to switch.

[Dozalex]

@nmn I understand correctly that if the component is slightly larger than one line, it will look like this?

import * as stylex from '@stylexjs/stylex';

const styles = stylex.create({
  container: {
    color: 'red',
  },
  title: {
    backgroundColor: 'blue',
  },
  content: {
    backgroundColor: 'blue',
  },
  item: {
    backgroundColor: 'blue',
  },
});

function MyComponent({ style }) {
  return (
    <div {...stylex.props(styles.container, style)}>
      <p {...stylex.props(styles.title)}>Title</p>
      
      <div {...stylex.props(styles.content)}>
        <div {...stylex.props(styles.item)} />
        <div {...stylex.props(styles.item)} />
      </div>
    </div>
  );
}

As a developer I would like the code to look more clean and readable. New tools should follow this rule.

Thanks for providing "a few small things" why this tool was created, I got it - they are controversial and not for everyone.
I hope this doesn't become a standard in the React ecosystem just because it's being promoted from Facebook.

Anyway, good luck in your endeavors.

[fredericrous]

I understand getting Type-Safety was a trade of against the familiar devx of using css in literals. But in which situation is it interesting to get Type-Safety? I mean, a bad style won't segfault the app.
Type-Safety looks like a nice technical achievement, but I fail to identify the need for a frontend dev working with a modern IDE with autocompletion, plus possibly a suggestion AI like copilot
Here is what my IDE shows me, I'm using intellij with no plugins. notice the value that doesnotexist is underlined in red

[necolas]

familiar devx of using css in literals

Familiarity is in the eye of the beholder. Using objects has been common in styling libraries since their inception. We've seen developers at Meta make the switch and quickly become familiar with the change.

in which situation is it interesting to get Type-Safety

Type Safety allows developers to use styles similarly to other props, and is a mechanism by which design system rules can be automatically enforced. Types allow designers and developers to define which style props and specific values can be set by consumers of a component.

https://stylexjs.com/docs/learn/static-types/

https://stylexjs.com/docs/learn/thinking-in-stylex/#type-safe-styles

[olivierpascal]

Type Safety for vars is a must imho.

background-color: var(--does-not-exist);

Won't error. But:

backgroundColor: vars.doesNotExist,

Will error.

[nmn]

This Repo is not for flamewars. You're welcome to choose one of the many alternative if they suit your tastes better.