-
Conversations about Tailwind often frame it as a new approach to CSS, but I thinks it's better understood as a new approach to *frameworks* specifically. CSS Frameworks have been popular well over a decade, & TW builds on previous fan favorites, like Foundation & Bootstrap. 🧵Permalink On twitter.com
♻️ 16 Retweets ❤️ 136 Favorites Mood +12 🙂
-
Frameworks provide shortcuts, but need to remain fairly generic. The previous generation put a focus on pre-designed components. Sass variables allowed for some theming & configuration, but many constraints are baked in. Major customization often requires selector overrides.Permalink On twitter.com
-
I see Tailwind as a reaction to that, in the same way Susy was reacting to less flexible grid frameworks. You can get the component if you want, or access _some underlying tools_ more directly. Still an abstraction over the language, but more exposed layers. More customization.On twitter.com
-
CSS frameworks have always relied on class-based APIs. There's not really another option, without adding dependencies. If you need the API to handle lower-level concepts & tools, utility classes are the only real option, & have a long history. TW just moved them front & center.Permalink On twitter.com
-
Frameworks are part of a thriving language. Sometimes they even expose opportunities for the language to improve. That's great. Those features will likely change in translation, tho. Tools are also more targeted, less universal, & will change more quickly. That's fine too.Permalink On twitter.com
-
To summarize: When you write custom CSS, there are many ways to think about architecture, selector APIs, customization, performance, &c – specific to the project. Frameworks have to work across unknown projects & environs. They are designed around totally different constraints.Permalink On twitter.com