|
|
|
|
|
by verisimilidude
1779 days ago
|
|
For each project, there's a unique balance between HTML, CSS, and the greater organization. Consider a site that mostly renders Markdown or XML documents. Tailwind is probably the wrong choice. You have less control of the HTML content in this case, because it's generated. If you want to use Tailwind here, you'd need to make liberal use of Tailwind's @apply directive for basic declarations, which IMO is not the best expression of Tailwind usage. On the other hand, you have a lot of control over the CSS. It makes more sense to write the CSS directly. Now consider an organization with many separate web properties, which all require consistent branding. The organization has a UI guy who creates universal stylesheets and components for use across sites. Here you have less control over the CSS, and more over the HTML. Tailwind makes more sense. You can add all the utility classes to HTML that you want, with few overrides or other enterprise pull-ups. This latter scenario also highlights one of Tailwind's strengths. Tailwind limits your options. If you need to keep a brand consistent across a large number of properties, Tailwind keeps you in the guardrails of the style guide. I can't be the only one who's worked at an organization where there's supposed to be only one shade of blue to represent the brand, but you wind up finding 160 different shades of blue throughout the CSS. Anyway, Tailwind has its time and place. I love it when it fits. |
|