4 ms·

How would have React adoption looked like if it wasn't backed by a tech giant? React propounds a very controversial idea: to put HTML inside Javascript. Of cour

How would have React adoption looked like if it wasn't backed by a tech giant? React propounds a very controversial idea: to put HTML inside Javascript. Of course, once you get the hang of it, it all makes perfect sense: tight coupling and composability. Tailwind, along the same lines, proposes a contrarian idea and it will only make sense once you start working with it. Here's what I have seen happen frequently: As the CSS grows, so does the bloat and repetitiveness of the same basic style. Let's say you want to position elements in the center of a component? "display: flex, align-items: center" easy. But what do you do when you encounter that same requirement again? Creating a utility class and replacing existing once will be a pain, so you add the same styles again. And that's how folks you end up with a megabyte of CSS doing a job that could be done in <100Kb. This pattern is more pervasive than you think. The fundamental problem is that we are not thinking about styling in terms of composability of basic styles. The benefits of utility classes outweigh the cons. You can iterate faster, you don't have to fight the framework, you don't have rethink abstractions at every point ("this style belongs to a component or a utility class") and as CSS becomes more expressive you'll need fewer classes anyways. I hope Tailwind takes off because styling definitely needs to be less painful than it's today.

jacamat 8y ago
The benefits absolutely do not outweigh the cons. For starters, your CSS can never compile down to a smaller size than component CSS - ever. Because of the nature of compositional classes the plateau of problems expands out almost infinitely, and the resultant inconsistencies necessitate new overrides, more code, more complexity, more misdirection. What size site do you work on? How often do you have to completely change an interface, or move a component from one place to another without it breaking at all, and how well does that work for you with Tailwind? How do you plan to scale this codebase consistently across organizations, teams, potentially platforms? Tailwind and the frameworks like it are absolutely terrible at scale. I've spent years of my life trying to remove functional css from sites trying to scale while it holds them back.
- mst 8y ago
  I'd love it if you expanded on that last comment - my instinct is that functional CSS is a footgun, but I'm not nearly good enough at CSS to really be able to unpack that into concrete problems it causes.
  - jacamat 8y ago
    Sure thing. Due to an NDA, I can’t get into granular detail about the site, but I’m more than happy to expand on the problem. When I started here, I sort of “inherited” a large stylesheet written in the classic BEM/Tachyon style of CSS. I can see why the author chose this method, because at the time the website was small and functional classes seem like a really good thing, as they help you get up and running quickly. Over the years, however, the site got more popular, and now the demands of the interface are increasing. At one point, it was perfectly OK to do, say, “container mt-5 mb-5 p-20 text-green” etc. This flexibility allowed the site to grow, and while the CSS did bloat, the impact was seen as negligible for years. Now the site sees 50-80k+ DAU, and seeing as the business is very established, it makes sense that we would want to add bells and whistles to the UI that wasn’t on the roadmap those years ago, like theming, widgets, or simply making a previously non-responsive page responsive. In Tachyons, and in Tailwind, the abundance of utility classes means that even the best, most organized authors will create inconsistencies. The original container styles from earlier might look something like “container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5” in others. It may seem trivial to just add and remove classes at will, but it isn’t. Removing a margin-bottom from one element inevitably affects the position of another on the same page, and trying to reconcile these inconsistencies _usually_ means an override, because figuring out how to rearrange functional classes without breaking anything else is a time suck. Removing this style of CSS from the project has been tedious, but necessary. Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else. And you avoid the unexpected inconsistencies created using utility classes by, well, avoiding them. As someone that used to love BEM, tachyons, Atomic CSS, etc., the lack of scope, unpredictability and huuuuge bloat created by overrides steers me away from it even for the tiniest of projects.

jacamat 8y ago

The benefits absolutely do not outweigh the cons. For starters, your CSS can never compile down to a smaller size than component CSS - ever. Because of the nature of compositional classes the plateau of problems expands out almost infinitely, and the resultant inconsistencies necessitate new overrides, more code, more complexity, more misdirection. What size site do you work on? How often do you have to completely change an interface, or move a component from one place to another without it breaking at all, and how well does that work for you with Tailwind? How do you plan to scale this codebase consistently across organizations, teams, potentially platforms? Tailwind and the frameworks like it are absolutely terrible at scale. I've spent years of my life trying to remove functional css from sites trying to scale while it holds them back.

mst 8y ago
I'd love it if you expanded on that last comment - my instinct is that functional CSS is a footgun, but I'm not nearly good enough at CSS to really be able to unpack that into concrete problems it causes.
- jacamat 8y ago
  Sure thing. Due to an NDA, I can’t get into granular detail about the site, but I’m more than happy to expand on the problem. When I started here, I sort of “inherited” a large stylesheet written in the classic BEM/Tachyon style of CSS. I can see why the author chose this method, because at the time the website was small and functional classes seem like a really good thing, as they help you get up and running quickly. Over the years, however, the site got more popular, and now the demands of the interface are increasing. At one point, it was perfectly OK to do, say, “container mt-5 mb-5 p-20 text-green” etc. This flexibility allowed the site to grow, and while the CSS did bloat, the impact was seen as negligible for years. Now the site sees 50-80k+ DAU, and seeing as the business is very established, it makes sense that we would want to add bells and whistles to the UI that wasn’t on the roadmap those years ago, like theming, widgets, or simply making a previously non-responsive page responsive. In Tachyons, and in Tailwind, the abundance of utility classes means that even the best, most organized authors will create inconsistencies. The original container styles from earlier might look something like “container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5” in others. It may seem trivial to just add and remove classes at will, but it isn’t. Removing a margin-bottom from one element inevitably affects the position of another on the same page, and trying to reconcile these inconsistencies _usually_ means an override, because figuring out how to rearrange functional classes without breaking anything else is a time suck. Removing this style of CSS from the project has been tedious, but necessary. Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else. And you avoid the unexpected inconsistencies created using utility classes by, well, avoiding them. As someone that used to love BEM, tachyons, Atomic CSS, etc., the lack of scope, unpredictability and huuuuge bloat created by overrides steers me away from it even for the tiniest of projects.