Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
react-table
🤖 Headless UI for building powerful tables & datagrids for TS/JS - React-Table, Vue-Table, Solid-Table, Svelte-Table
-
-
tamagui
Style React fast with 100% parity on React Native, an optional UI kit, and optimizing compiler.
-
-
headlessui
Completely unstyled, fully accessible UI components, designed to integrate beautifully with Tailwind CSS.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> animated example in the front page
Not the blog post, the main landing page, ie https://tailwindcss.com/
You may be interested in Chakra UI (https://chakra-ui.com), which has low-level details (including default theming) basically identical to Tailwind CSS v2 but is built around css-in-js via Emotion.
You're right as it probably won't work well with MUI [0] (formerly React Material) and similar options like Ant [1]. But they all accept a theme provider that could hook in to the Tailwind config. Never tried it though.
But a swell of less opinionated offerings [2] [3] [4] (more and more the popular anyways) work well with Tailwind. In fact, when writing your own libs, exposing a className prop makes them painlessly customisable.
0 - https://mui.com
1 - https://ant.design
2 - https://www.radix-ui.com/docs/primitives/overview/styling
3 - https://react-table.tanstack.com
4 - https://react-spectrum.adobe.com/react-aria/
You're right as it probably won't work well with MUI [0] (formerly React Material) and similar options like Ant [1]. But they all accept a theme provider that could hook in to the Tailwind config. Never tried it though.
But a swell of less opinionated offerings [2] [3] [4] (more and more the popular anyways) work well with Tailwind. In fact, when writing your own libs, exposing a className prop makes them painlessly customisable.
0 - https://mui.com
1 - https://ant.design
2 - https://www.radix-ui.com/docs/primitives/overview/styling
3 - https://react-table.tanstack.com
4 - https://react-spectrum.adobe.com/react-aria/
Shameless self-plug but if you'd like the same idea but with an optimizing compiler that outputs clean CSS at build-time, try Tamagui (https://tamagui.dev).
Some technical thoughts as someone who could care less about fanboyism:
- One point where atomic CSS frameworks are supposed to shine over conventional CSS is bundle size, since they (at least the good ones) compile to only a single rule for any used value, rather than potentially repeating rules for semantically different classes.
- Another point where atomic CSS frameworks shine is just sheer volume of banging code out. When the bulk of your output is visual, mastering tools based on shorthands like tailwind, emmet, etc can feel very productive.
- Purely atomic CSS frameworks can make some workflows more difficult, e.g. by having too granular call sites and not allowing "let's see what happens to the overall theme if I do this design change" iterative style of work, or because workflows that edit CSS on the fly via browser devtools can no longer be used to limit impact within semantic lines (e.g. "I want to change padding only on buttons, without breaking everything else that happens to depend on the same padding value"). There are both design-oriented and debugging-oriented workflows that are affected in similar ways.
- You generally don't get visual regressions at a distance w/ atomic CSS. This matters at organizations where desire for pixel precision and simultaneously fickle design teams are the norm. But conversely, "can we just change the font size to be a bit bigger across the site" can often run into issues of missed spots. On a similar note, designs may become inconsistent across a site over time due to the hyper local nature of atomic CSS oriented development.
- Custom rules may as well be written in APL[0]; they usually aren't documented and it takes a "you-gotta-know-them-to-know-them" sort of familiarity to be able to work with them (or get back to them after a while).
- There are some tools that mix and match atomic CSS with other paradigms. For example, styletron[0] can output atomic CSS for the bundling benefits, but looks like React styled components from a devexp perspective, and has rendering modes that output traditional-looking debug classes for chrome devtool oriented workflows.
The main theme to be aware of: proponents rarely talk of maintenance, so beware of honeymoon effect. Detractors often omit that traditional CSS (especially at scale) also requires a lot of diligence to maintain. So think about maintenance and how AOP[1] vs hyperlocal development workflows interact with your organization's design culture.
[0] https://www.styletron.org/
[1] https://en.wikipedia.org/wiki/Aspect-oriented_programming
There is a headless (meaning unstyled) set of components from the same authors: https://headlessui.dev/