Having just started with Tailwind on a personal project, I really like it's pragmatic approach; Tailwind is stripping away a layer of abstraction that works hard against me in trying to create and manage my layout.
Tailwind's "utility-first" approach means that you are rejecting semantic styling in favor of a very in-your-face pragmatic (if verbose, with caveats) direct description of the design, layout, and (some parts of) behavior of your elements.
This is very much inline with Simple Made Easy in my mind. I'll trade opaque abstracts for verbosity nearly every time (especially when, as here, there's a mechanism to reduce that verbosity when needed).
What isn't in the discussion so far is the Node-based tooling; tailwind can be configured to watch your source files; it picks out the class names it defines that your code actually uses, and only those go into the output CSS (which is regenerated as files change). This carries through into production, so it means that the final CSS is small.
I've definitely been in projects where the use of a CSS class name drifted from its original semantic meaning, resulting in the class being locked forever, for fear of changing something elsewhere in the app without meaning too; this certainly results in CSS bloat. I've also seen cases where the volume of semantic names was too great, so that the names became nearly meaningless.
We'll see if my mind changes as I use it more, but my sense for it is quite positive.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Having just started with Tailwind on a personal project, I really like it's pragmatic approach; Tailwind is stripping away a layer of abstraction that works hard against me in trying to create and manage my layout.
Tailwind's "utility-first" approach means that you are rejecting semantic styling in favor of a very in-your-face pragmatic (if verbose, with caveats) direct description of the design, layout, and (some parts of) behavior of your elements.
This is very much inline with Simple Made Easy in my mind. I'll trade opaque abstracts for verbosity nearly every time (especially when, as here, there's a mechanism to reduce that verbosity when needed).
What isn't in the discussion so far is the Node-based tooling; tailwind can be configured to watch your source files; it picks out the class names it defines that your code actually uses, and only those go into the output CSS (which is regenerated as files change). This carries through into production, so it means that the final CSS is small.
I've definitely been in projects where the use of a CSS class name drifted from its original semantic meaning, resulting in the class being locked forever, for fear of changing something elsewhere in the app without meaning too; this certainly results in CSS bloat. I've also seen cases where the volume of semantic names was too great, so that the names became nearly meaningless.
We'll see if my mind changes as I use it more, but my sense for it is quite positive.