How is it different from Linaria?

[zaguiini]

Hi! Great project!

I'm trying to understand how this project differs from existing solutions, like https://github.com/callstack/linaria for example?

[layershifter]

We are building library that works, scales and is performant for UI libraries/frameworks & applications. And this affects its design and goals. We use Atomic CSS to solve specificity problems and order of appearance. This is the key difference/similarity to other libraries.

Here is a sample CodeSandbox (https://codesandbox.io/s/order-of-appearance-puzzle-svwi8) that shows why order of appearance matters 😉

In terms of competitors the closest ones is Compiled and Stylex. It's hard to compare with the second, but compared to Compiled we have significantly better runtime performance:

(👆 I plan to publish this benchmark later somewhere, the same as in react-native-web & in fela but contains more libraries)

We don't have similar metrics as Meta with Stylex, but once CSS extraction #53 will be supported we expect to see the same bundle size curve: more styles => less bundle size.

vs. Linaria

Linaria overall is a perfect library we even reuse their module evaluation for our build time transforms ❤️

From API

• Griffel has syntax based on JavaScript objects: Linaria uses template strings with CSS

  const useHeaderClasses = makeStyles({
    root: {
      textTransform: "uppercase",
      fontFamily: "Segoe UI"
    }
  });
  // vs.
  const header = css`
    text-transform: uppercase;
    font-family: Segoe UI;
  `;

• Griffel uses Atomic CSS: Linaria uses monolithic classes
• Griffel works in runtime, it's zero config like other CSS-in-JS (Emotion, Styled components). This helps customers to use it instantly with complicated setup

From implementation perspective

There are other competitors on this field that are similar to Linaria (for example, vanilla-extract), but in fact they are more or less "wrappers" around CSS modules. There is nothing wrong with that approach, but it does not scale for reusable libraries well.

Let's take an example from Linaria docs, there is a basic button Button and LargeButton that uses styled API:

We can notice that the library uses a trick with increased specificity to ensure that styles from LargeButton will win. This solves the problem with order of appearance for first party components. Another basic pattern in Linaria is to refer components in styles:

const Article = styled.article`
  ${LargeButton} { color: white; }
`;

It's a moment when order of appearance strikes with async imports and increased specificity does not help:

Although Griffel does not anything with specificity for composition (classes merging and deduplication happens in mergeClasses() function) it also does not depend so much on order of appearance (there are still might be rare edge cases 💥 ). The result is correct:

• Linaria CodeSandbox: https://codesandbox.io/s/linaria-demo-forked-lf3wzs
• Griffel CodeSandbox: https://codesandbox.io/s/hardcore-sea-61zvfk

While the order of appearance looks like an edge case that will be more common soon with increasing usage of React.Suspense.

P.S. There was a recent check in of Atomic CSS approach (callstack/linaria#867), but I didn't manage to check & compare.