3 ms·

That's how I see it - as a sole developer on a side project, Tailwind is a great force multiplier, much like tools like Hotwire/Turbo, Dokku/Heroku for deployme

by danjac 6y ago

That's how I see it - as a sole developer on a side project, Tailwind is a great force multiplier, much like tools like Hotwire/Turbo, Dokku/Heroku for deployments, frameworks like Rails or Django etc. A large company with frontend specialists and CSS experts might not need Tailwind - and indeed they might find it gets in the way. Personally I find it lets me build and maintain decent UI layouts with minimum fuss. When I'm repeating myself with too-long class strings, I can either use @apply or wrap the markup in a component.

ratww 6y ago
I had the experience of using a similar Atomic CSS framework to a large-ish company in the past, and maintenance was pretty smooth too. In fact I would say that maintainability was the #1 advantage for us in the long term. Some people did have a visceral hatred of Atomic CSS, but even those people were able to solve problems with it very quickly, without having to dig on tens of CSS files that happened to affect a single component.
- nawgz 6y ago
  Is it normal to have tens of CSS files impacting a component!? In my world, the component styles itself, and its parent can tell it how to be spaced / positioned and themed (via CSS variables preferably). Anything beyond that seems spaghetti...
  - ratww 6y ago
    Of course it's the worst kind of rotten spaghetti. But yes, this is normal when projects are 10 years old, super large, and have been touched by 200, 300 or more developers. There's only two ways to avoid it: having very small, very cohesive, teams, or using tools and methodologies that avoid this.
    - danjac 6y ago
      I've mainly seen this happen when the site/application is very product/design (non-tech) driven and the developers pull themselves and the code into contortions to deliver very exacting requirements. The goal is to deliver a pixel-perfect result at the end of the sprint, and the unfortunate waste product is the mess of CSS, markup and JS required to deliver it: which then becomes very fragile technical debt that can only be tweaked rather than refactored lest the whole stack of cards collapses. It makes little difference whether the team started out with a UI framework or not at this point.
      - ratww 6y ago
        True! Pixel-perfect layout at any cost is harmful to the long-term quality of the codebase. The development team has to be able to say "no" sometimes.
    - nawgz 6y ago
      Fair enough, I work in small teams and independently a lot. It does make sense you need some strict architecture / tooling to prevent it in a more distributed org. This is one of those things that gives me the feeling the true "10x" engineer mostly just writes code to some reasonable architecture standard and does their best to avoid tech debt. Speed in the longer term means avoiding these situations if you ask me
- bostonvaulter2 6y ago
  > ... without having to dig on tens of CSS files that happened to affect a single component. Hmm, that would be interesting data to use to analyze the CSS quality of a site. If you used the sourcemaps along with a rendered html page you could find which elements had styling from the most separate css files which might give you clues on where to improve your CSS.
runawaybottle 6y ago
I’d say even at a large company this can be advantageous. Since most devs are moving into fullstack, it’s obvious to me when more backend centric people are doing frontend. I’d rather they reach for standard classes than do their mish mash of css brainstorming.
AltruisticGapHN 6y ago
Disagree with 2nd statement. Tailwind is awesome for frontends, the way forward is to learn to compose. As long as you use bem style convention, with simple "flat" selectors, you can use both sass and tailwind and write less css (instead of no css, which I find extreme and impractical). However that also means its perfectly ok to have one’s own system (cf. twitch, github...). Why not use a standard though? Tailwind saves us so much time coming up with a solid consistét utility set. And then combine it with Sass

by danjac 6y ago

ratww 6y ago

I had the experience of using a similar Atomic CSS framework to a large-ish company in the past, and maintenance was pretty smooth too. In fact I would say that maintainability was the #1 advantage for us in the long term. Some people did have a visceral hatred of Atomic CSS, but even those people were able to solve problems with it very quickly, without having to dig on tens of CSS files that happened to affect a single component.

nawgz 6y ago
Is it normal to have tens of CSS files impacting a component!? In my world, the component styles itself, and its parent can tell it how to be spaced / positioned and themed (via CSS variables preferably). Anything beyond that seems spaghetti...
- ratww 6y ago
  Of course it's the worst kind of rotten spaghetti. But yes, this is normal when projects are 10 years old, super large, and have been touched by 200, 300 or more developers. There's only two ways to avoid it: having very small, very cohesive, teams, or using tools and methodologies that avoid this.
  - danjac 6y ago
    I've mainly seen this happen when the site/application is very product/design (non-tech) driven and the developers pull themselves and the code into contortions to deliver very exacting requirements. The goal is to deliver a pixel-perfect result at the end of the sprint, and the unfortunate waste product is the mess of CSS, markup and JS required to deliver it: which then becomes very fragile technical debt that can only be tweaked rather than refactored lest the whole stack of cards collapses. It makes little difference whether the team started out with a UI framework or not at this point.
    - ratww 6y ago
      True! Pixel-perfect layout at any cost is harmful to the long-term quality of the codebase. The development team has to be able to say "no" sometimes.
  - nawgz 6y ago
    Fair enough, I work in small teams and independently a lot. It does make sense you need some strict architecture / tooling to prevent it in a more distributed org. This is one of those things that gives me the feeling the true "10x" engineer mostly just writes code to some reasonable architecture standard and does their best to avoid tech debt. Speed in the longer term means avoiding these situations if you ask me
bostonvaulter2 6y ago
> ... without having to dig on tens of CSS files that happened to affect a single component. Hmm, that would be interesting data to use to analyze the CSS quality of a site. If you used the sourcemaps along with a rendered html page you could find which elements had styling from the most separate css files which might give you clues on where to improve your CSS.

runawaybottle 6y ago

I’d say even at a large company this can be advantageous. Since most devs are moving into fullstack, it’s obvious to me when more backend centric people are doing frontend. I’d rather they reach for standard classes than do their mish mash of css brainstorming.

AltruisticGapHN 6y ago

Disagree with 2nd statement. Tailwind is awesome for frontends, the way forward is to learn to compose. As long as you use bem style convention, with simple "flat" selectors, you can use both sass and tailwind and write less css (instead of no css, which I find extreme and impractical). However that also means its perfectly ok to have one’s own system (cf. twitch, github...). Why not use a standard though? Tailwind saves us so much time coming up with a solid consistét utility set. And then combine it with Sass