As I’m working on the tedium of onboarding refinements, which is kind of like eating a bowl of rice a grain at a time, I’m researching frontend stacks and design systems.

Our frontend stack is currently a hodgepodge of a sass bootstrap theme, css modules, and react-bootstrap. Some of our plans require lots of frontend malleability, which our current stack cannot easily support, so we’ll be upgrading the stack as part of those plans.

Frontend systems have evolved a lot over the last few years. Developers have accepted that CSS is a mistake and headless (ie unstyled yet accepting of styles) component libraries have been dialed in. Modern frontend stacks have two independent layers now: styling systems and component libraries. If you aren’t fully prompting your frontends, picking a frontend stack requires making a decision for each layer.

What do you use for your frontend stack? Are you happy with it? Have you thought about switching and what might you switch to?

These are some of my thoughts on these layers, which have me leaning toward using stylex for styles and base ui for our component library.

stylingstyling

CSS’s hidden cascade is its biggest problem, brought by isolating form from function, presentation from content. CSS styles content from multiple origins at a distance. CSS’s isolated yet cascading abstraction is an oxymoron.

Tailwind’s classname postcss DSL soup is the most popular solution for this. But, it treats CCS’s disease with its own. If the problem with CSS is the hidden cascade, what’s needed is styling that lives with the content. Tailwind’s classname soup isn’t necessary, nor are its ex post facto ideologies forbidding abstractions of style.

css-in-js postcss systems solve this problem too and without the classname soup. Like styling with tailwind, styles in css-in-js reside with the content. With css-in-js you can build the themes, utilities, and token systems using functional javascript. The main tradeoff is that css-in-js has more, however obvious, footguns than tailwind. For crafty programmers, if you trust yourself to avoid the footguns, you can avoid CSS modules’ and tailwind’s tradeoffs.

headless component librariesheadless component libraries

There are a lot of these, many of them are excellent on the important fronts, and the good ones are tree shakable, letting you cherrypick components in a one-off fashion. Still, each of them have subtlety different APIs, patterns for accepting styles, composition, event handling, etc, so I imagine the preference is to lean on one component library as much as possible.

Choosing a component library, once you decide to go headless, appears to mostly be about choosing an API that you like. Other than that, they seem to compete on the component library’s completeness and the team/activity/philosophy like any other open source project.

thinking is datedthinking is dated

I realize that thinking is going out of fashion, but at least for now, I have resistance to quitting.

The alternative to all of this is to prompt your frontend entirely. It might use tailwind, and it might use radix, or something else, and what do you care. You can prompt a new component in the time it takes to hit your vape.

Or ... making good decisions about concepts matters more than ever.