CEO doesn't care about your CSS strategy, as long as you use Tailwind(ideas.krishnan.ca)
ideas.krishnan.ca
CEO doesn't care about your CSS strategy, as long as you use Tailwind
https://ideas.krishnan.ca/your-ceo-doesnt-care-about-your-css-strategy-as-long-as-you-use-tailwind
17 comments
A classic version of calling for Mom.
I don't do front end, no dog in this fight. But when someone starts talking down to you, explaining in small words why "business is ultimately in charge", you know they lost the first argument and are now threatening to tell Mom on you.
I don't do front end, no dog in this fight. But when someone starts talking down to you, explaining in small words why "business is ultimately in charge", you know they lost the first argument and are now threatening to tell Mom on you.
It's even worse, it's arguing that since mom only cares that the room looks clean, it's totally better to sweep stuff under the carpet real fast.
The author having worked with 100s of teams is already a tell he ain't around for long term debacles. It paid to ship on time, the rest isn't his problem. The mention that even non developers can develop with tailwind is a tell.
Cons of using Tailwind:
- In addition to knowing CSS you now also have to learn all the Tailwind class names that map to CSS styles.
- Development starts fast because you just drop Tailwind’s utility classes into HTML elements but then you end up with a long list of classes and things become unreadable, and worse, you have to repeat yourself if you want to apply the same style to other elements. Better group the list of Tailwind classes into a custom class. Wait, we have just re-invented CSS classes but need additional build tools.
- In addition to knowing CSS you now also have to learn all the Tailwind class names that map to CSS styles.
- Development starts fast because you just drop Tailwind’s utility classes into HTML elements but then you end up with a long list of classes and things become unreadable, and worse, you have to repeat yourself if you want to apply the same style to other elements. Better group the list of Tailwind classes into a custom class. Wait, we have just re-invented CSS classes but need additional build tools.
I think Tailwind really shines alongside a tool like React where you don't abstract out a class of Tailwind classes, but a whole component with minimal to no functionality. If you end up with too many of those then maybe it's a sign your design language is getting too complex?
Is this a parody? Is this deliberately designed flame bait? It reminds me of adequacy.org back in the day. I don't think I should discuss this post on its merits, because (I suspect) that's exactly what they want you to do.
Looks like someone trying their hand at satire but failing miserably...
I don't understand this article, it presumes tailwind as a sane default without really justifying it. It kind of comes across as someone who's trying to justify a bad decision and they know the the facts are not on their side.
This is despite the fact I also think tailwind is the right choice, and I'll be living my life as if tailwind is the modern replacement for bootstrap.
> Tailwind has large (200kb) JS payloads
My tailwind deployment is 7kb css (before gzip+min) and 0kb js (0 files).
But that aside, there are known studies that statistically speaking, users leave if your page is slower.
> Senior leaders care about cost, not artistry, when assessing technical decisions
so we'll continue using the thing that existed before tailwind, then? I think my CEO would get mad and fire me if I rewrote all my bootstrap stuff into tailwind.
I would really like to read articles that give strong arguments in favor of using tailwind.
This is despite the fact I also think tailwind is the right choice, and I'll be living my life as if tailwind is the modern replacement for bootstrap.
> Tailwind has large (200kb) JS payloads
My tailwind deployment is 7kb css (before gzip+min) and 0kb js (0 files).
But that aside, there are known studies that statistically speaking, users leave if your page is slower.
> Senior leaders care about cost, not artistry, when assessing technical decisions
so we'll continue using the thing that existed before tailwind, then? I think my CEO would get mad and fire me if I rewrote all my bootstrap stuff into tailwind.
I would really like to read articles that give strong arguments in favor of using tailwind.
The problem is that CEOs without full context can fall victim to cargo cult trends. "Everyone is using Tailwind, so we should too."
In my experience, Tailwind is great, and improves productivity, IF you are building an SPA with a modern javascript framework like React, that uses "components" as the primary UI abstraction. In that context, utility classes make a lot of sense.
But if you're doing traditional static content with semantic markup, then the traditional CSS stylesheet is still the better abstraction, and tailwind hurts developer productivity.
In my experience, Tailwind is great, and improves productivity, IF you are building an SPA with a modern javascript framework like React, that uses "components" as the primary UI abstraction. In that context, utility classes make a lot of sense.
But if you're doing traditional static content with semantic markup, then the traditional CSS stylesheet is still the better abstraction, and tailwind hurts developer productivity.
You're right; this is dishonest argumentation, designed to discredit their target in front of a higher level of authority.
Here's a story: Two railroad engineers are tasked with blasting an opening along the edge of a cliff. The senior engineer says it will take thirty sticks of dynamite. The junior engineer says it will take ten sticks of dynamite. They debate it for hours without coming to agreement, and ultimately it's the senior engineer's decision to make. So the junior engineer goes to management and says, "This guy doesn't get it. He goes on and on about geology, and pressure waves, and cliffs he has blasted before, and his precious sticks of dynamite. But me, I understand that the purpose of blasting this cliff is to build this railroad on time, and that's why I say we should use ten sticks of dynamite." So management orders the senior engineer to use ten sticks of dynamite.
The blast fails, construction falls behind, and management is plagued with worries. Management ruminates on the failed blast and the two engineers, and remembers that the junior engineer was concerned about the construction schedule. "That guy had his head in the right place. He understands what I'm going through! If I had somebody like that in charge, I wouldn't have these troubles. The senior engineer is just concerned about his goddamned rocks and dynamite. No wonder we're not on schedule." So management fires the senior engineer and promotes the junior engineer to replace him.
It's an important lesson for developers to consider. If somebody runs to Mom, you have to go with them and make your case. If they are allowed to frame the problem for management, it won't matter whose technical judgment is vindicated in the end; management will remember them as the one who had their priorities straight.
Here's a story: Two railroad engineers are tasked with blasting an opening along the edge of a cliff. The senior engineer says it will take thirty sticks of dynamite. The junior engineer says it will take ten sticks of dynamite. They debate it for hours without coming to agreement, and ultimately it's the senior engineer's decision to make. So the junior engineer goes to management and says, "This guy doesn't get it. He goes on and on about geology, and pressure waves, and cliffs he has blasted before, and his precious sticks of dynamite. But me, I understand that the purpose of blasting this cliff is to build this railroad on time, and that's why I say we should use ten sticks of dynamite." So management orders the senior engineer to use ten sticks of dynamite.
The blast fails, construction falls behind, and management is plagued with worries. Management ruminates on the failed blast and the two engineers, and remembers that the junior engineer was concerned about the construction schedule. "That guy had his head in the right place. He understands what I'm going through! If I had somebody like that in charge, I wouldn't have these troubles. The senior engineer is just concerned about his goddamned rocks and dynamite. No wonder we're not on schedule." So management fires the senior engineer and promotes the junior engineer to replace him.
It's an important lesson for developers to consider. If somebody runs to Mom, you have to go with them and make your case. If they are allowed to frame the problem for management, it won't matter whose technical judgment is vindicated in the end; management will remember them as the one who had their priorities straight.
The guy is spot-on. Some devs are too quick to assume that technical perfection / purity is what they're paid for. Sometimes that approach and mindset serves a really valid purpose but often not.
What happens if the main developer used Tailwind and has to pass it on to the next developer? (As in, the main developer got hit by a bus). Does the next developer have to learn Tailwind?
My opinion,
I'd hope they use the standard at the company.
If it's a new developer, then yes.
Just standardize on something. That way you don't need to learn the 50 ways the same thing is done on different projects.
I'd hope they use the standard at the company.
If it's a new developer, then yes.
Just standardize on something. That way you don't need to learn the 50 ways the same thing is done on different projects.
Yes. No different from literally any other tech stack, be it Tailwind, Bootstrap, React, Vue, Spring Boot, Micronaut, or Actix.
Is there any tech work where this doesn't apply?
How is it different from most things we do?
yes
For me, it's the epitome of "Don't knock it until you try it."
(Close second is TypeScript. Which was less that I found it revolting, and more that I didn't understand the point properly.)
I think, of every developer I know the arc has always been the same (with the exception of 2 who still don't like it):
It's the tooling/IDE experience that really does it IMO.
Tailwind took the "Java/Go" approach of standardization and top-notch IDE integration + Dev workflow. You don't have to think about anything, because it's all been thought out for you, yet not in a way that's limiting (bunch of tiny composable pieces and allows you to go outside the "happy path" defaults if you want).
Looking back at the start of my career, it now seems caveman -like that you would onboard on to a project, and they would each have these massive CSS files with class names that ONLY had meaning to that particular project + were entirely subjective. And transformed over time, too.
Sure:
Reads easier, but I have no idea what that actually _means_
With Tailwind, WYSIWYG, and it's all fully autocompleted + gives you color previews inline and helpful visual cues for positioning etc.
I'm sure something better will eventually come along, but Adam really nailed it with this one as far as I'm concerned.
Signed,
Former Nonbeliever