My background story on CSS tools

It started with a strong sense of unease about my product built with existing tools.

The Beginning (Direct CSS Writing)

CSS is a flawed language with missing elements, isn't it? No, it's not even a language. This is how the conversation between two people began. Looking back now, that conversation is still fresh in my memory. At this point, I faced the reality that I wanted to solve the CSS problem altogether.

Beginner's Mind (Tailwind)

I built a React SPA using Tailwind. However, every time I looked back at it later, I only regretted it, wondering why I did it this way, realizing I couldn't refactor or migrate it, and maintenance stalled.

(If the class is long, even finding and changing the characters within the tags becomes difficult.)

Start (A Small Compiler as the Beginning)

One day, two people were discussing the usability of CSS-in-JS and UI libraries. Inspired by the suggestion to create a Melt Extract (inspired by vanilla-extract), they started developing a small compiler (a JS to CSS transpiler).

StyleX was Babel-based, so it was assumed that it would be built using SWC.

Later Implementation (Accelerating the Development)

The suggestion from the other person to align with StyleX gave the push for the development phase.

From version 0.13.0, they transitioned from semantic to atomic. Here, they carefully studied StyleX's non-destructive sequential design and gradually incorporated it into the compiler.

Branding (Where Does It Differentiate It from StyleX?)

StyleX offers flexible styling.

They used StyleX to understand what was good and what wasn't.

Those familiar with StyleX will know that there are cases where a hash map remains.

To eliminate cases where a hash map remains, we used a two-layer scan and a dedicated table in the build layer, and achieved complete removal of the hash map in all patterns.

This is not just a differentiation from StyleX alone, but also from CSS Modules and vanilla-extract and Linaria, which use CSS Modules internally. (See: CSS Solution)

Reaching No-Runtime

This shows that anything is possible if the compiler is smart enough.

The absence of a hash map eliminates the need for runtime binding functions like stylex.props() and Linaria:cx.

Having the compiler handle these was not easy.

Towards the Concept of No Bundle Size

All that's needed for analysis is syntax; if the type is available, the syntax can be reproduced.

In short, simply bundling the types allows it to run as CSS-in-JS through build tools.

Since the core doesn't include runtime code, the bundle size is "none."

The Emergence of RSD (React Strict DOM)

This library achieves the clear goal of a single codebase that can move between native apps and the web. The maintainer is also the creator of StyleX, and I was deeply moved and influenced by this philosophy.

Nicholas's vision of the ultimate RSD is overwhelmingly powerful, so branding needed to be strengthened.

Enhanced Linting

Here, we focused on the anxieties that accompany manual codebase development.

By strengthening linting as strictly as possible and limiting type completion to auto-completion only, we were able to unify the JavaScript and TypeScript development experience.

And we could confidently say, "The purpose of Plumeria is to reduce the burden on developers."

Conclusion

This story is true and was developed concurrently with StyleX.

I would like to express my gratitude to Locomoco for giving me the motivation, to Piro for giving me the push I needed, and to Nicolas, the creator of StyleX and RSD.