Coming to Terms with Tailwind • Hacker News Board

Re: Coming to Terms with Tailwind

#31

Post by hnedeotes » Wed, Jul 07, 2021, 4:39 PM UTC

Wolfr_ wrote: post #17

hnedeotes wrote: post #12

Earlier quoted context omitted.

Yes I did, that's why I'm of that opinion. What it does is force you, as other frameworks, to learn all its intricacies, design decisions, use an heavy and complex development environment (that besides that reads files it doesn't have anything to go about reading?) so that you don't need to learn the underlying language. Then it nudges you to write a soup of classes (that you need to learn, and need to learn the conf…

We're trying to find the balance between semantic classes and utilities now with @apply. I've always found layout to be easier with utility classes (regardless of Tailwind, this counts for Bootstrap 4 too). I like "atom"-like components better with semantic classes. In BEM/ITSS I'd make a component for -everything-. But in Tailwind we'd only make one for common "atoms" such as buttons, tags, inputs etc. Code example:…

So yeah, I agree with pre-processing utilities - but this is just the same problem as with CSS and I think the apply idea is actually pretty neat...

But... I need to know all those classes to know why the final rules are put in place, I need to know that they don't have conflicting properties, or if they have, their priorities. And when you add your own custom apply's in there, then it can also break just the same. And when you customise your tailwind classes it ends the same problem. So when you're trying to figure out why rows in a table with the same number of headers and same number of td's have different sizes because some no-breaking space class was applied, and why your a.btn isn't getting the same styling as your button.btn and etc, I always feel like I've wasted more time than I should (perhaps because I know css and used it extensively)

I might have been a bit harsh on saying "dementia" as it's disrespectful for those who've put the work in writing it and releasing. It's better than all previous frameworks - I just personally think that it's problem searching for a solution as you can't really win.

Re: Coming to Terms with Tailwind

#32

Post by mrcwinn » Wed, Jul 07, 2021, 4:39 PM UTC

As someone who's building an MVP, I just want to express how unbelievably grateful I am for Tailwindcss, Tailwindui, Heroicons, and HeadlessUi. Fantastic work.

Re: Coming to Terms with Tailwind

#33

Post by vehemenz » Wed, Jul 07, 2021, 4:40 PM UTC

theflyinghorse wrote: post #23

Sr_developer wrote: post #9

Earlier quoted context omitted.

This is the thing, not all projects are super giant web applications being maintained by hundreds of front-end developers. For a dummy like me who curses at the laptop every time he needs to center a div and whose style sense pretty limited, tools like tailwind are a bless. I do a small library of components, copy what people who knows more than me does (taking examples from here https://tailwindcomponents.com/ ) ada…

I personally wouldn't trust a person who can center a div on the first try - something isn't right with them! What makes me concerned with tailwind is that its yet another API to remember. Why would I pick it over material UI with some theming or chakraUI? Why Did you pick tailwind over material or chakra?

For one, Tailwind has a minimal learning curve if you already know CSS. That's a huge thing going for it.

Secondly, UI frameworks are more suitable for full-blown applications, whereas Tailwind can be used for anything—applications, Wordpress themes, static sites, etc.

Re: Coming to Terms with Tailwind

#34

Post by hnedeotes » Wed, Jul 07, 2021, 4:42 PM UTC

brightball wrote: post #28

hnedeotes wrote: post #22

Earlier quoted context omitted.

But honest question, wouldn't those years of wrestling with the right UI framework be better spent learning the underlying CSS rules and adopting a simple pre-processor that gives you programmatic generation for repetitive bits? Because in the end, tailwind is better than bootstrap, but it's still the wrong way and incentivises wrong patterns. And by making it "standard" it makes everybody new to the field start with…

Honest answer: I already knew them. I’d used plain CSS for years following the Zen of CSS approach which I was very fond of and I was a big fan of SASS for simplifying it too. Dealing with browser quirks got old though. The issue is that most CSS is approached from a perspective that you’re going to reuse a specific part over and over in your HTML as a single tag. Tailwind realizes that this happens, but simply argue…

Yeah, I don't feel the same pains though.

Re: Coming to Terms with Tailwind

#35

Post by manojlds » Wed, Jul 07, 2021, 4:42 PM UTC

Wolfr_ wrote: post #27

cldellow wrote: post #25

Earlier quoted context omitted.

Well, you mentioned being blocked, so I searched your name + tailwind. Probably the company monitors the tailwind and tailwindcss keywords, saw those tweets, and decided that their signal-to-noise ratio for doing customer engagement would be better if they blocked you. It's not a statement about your twitter account in general, or you as a person. It's just that their corporate objective wasn't served by your tweets.…

I was just using my other Twitter accounts to stay up to date, it's not a big deal. I just genuinely wonder if blocking people that don't agree with you is a good strategy. I guess over time things also changed, Tailwind 2y ago was not the same as Tailwind now. They hired a bigger team and became much more of a company.

Those tweets are not just disagreeing.

Re: Coming to Terms with Tailwind

#36

Post by Wolfr_ » Wed, Jul 07, 2021, 4:42 PM UTC

stanmancan wrote: post #29

Wolfr_ wrote: post #27

Earlier quoted context omitted.

I was just using my other Twitter accounts to stay up to date, it's not a big deal. I just genuinely wonder if blocking people that don't agree with you is a good strategy. I guess over time things also changed, Tailwind 2y ago was not the same as Tailwind now. They hired a bigger team and became much more of a company.

There’s a difference between disagreeing and being an ass. If you wanted to engage with them then try to have a conversation. All you did was say how terrible it was and not to use it. Big difference. Nobody owes you their attention.

I agree, but none of those tweets were directed at the authors. They were just talking about Tailwind in general. One was a poor joke.

My 3 blog posts were a genuine attempt at trying to dissect what I didn't like about the framework. Many people wrote in to thank me for that perspective.

I find it unfair to single out two historical tweets neither of which is directed at the authors.

Re: Coming to Terms with Tailwind

#37

Post by Keats » Wed, Jul 07, 2021, 4:43 PM UTC

I still don't get Tailwind either but I found https://github.com/seek-oss/vanilla-extract recently which solves the TS/CSS modules nicely. All the styles are extracted at compile time so no overhead like most CSS-in-JS.

Re: Coming to Terms with Tailwind

#38

Post by 0xcoffee » Wed, Jul 07, 2021, 4:45 PM UTC

hnedeotes wrote: post #22

brightball wrote: post #7

Earlier quoted context omitted.

After years of wrestling with what the “right” UI framework was and marrying your project to the syntax and rules, Tailwind has entirely removed that concern from my life. https://www.brightball.com/articles/thank-you-tailwindcss

But honest question, wouldn't those years of wrestling with the right UI framework be better spent learning the underlying CSS rules and adopting a simple pre-processor that gives you programmatic generation for repetitive bits? Because in the end, tailwind is better than bootstrap, but it's still the wrong way and incentivises wrong patterns. And by making it "standard" it makes everybody new to the field start with…

In the article, it points out that some ideas being used by Tailwind are being considered as standards: https://www.w3.org/community/design-tokens/

I think this is an important point, good standards evolve by adopting real world proven practices. If everyone only used 'the standard', then it would never improve.

Re: Coming to Terms with Tailwind

#39

Post by Kaze404 » Wed, Jul 07, 2021, 4:46 PM UTC

theflyinghorse wrote: post #23

Sr_developer wrote: post #9

Earlier quoted context omitted.

This is the thing, not all projects are super giant web applications being maintained by hundreds of front-end developers. For a dummy like me who curses at the laptop every time he needs to center a div and whose style sense pretty limited, tools like tailwind are a bless. I do a small library of components, copy what people who knows more than me does (taking examples from here https://tailwindcomponents.com/ ) ada…

I personally wouldn't trust a person who can center a div on the first try - something isn't right with them! What makes me concerned with tailwind is that its yet another API to remember. Why would I pick it over material UI with some theming or chakraUI? Why Did you pick tailwind over material or chakra?

Material-UI React specifically has terrible performance. It's been a known issue for a while and it's still causing problems on the latest version. One of my projects has a seemingly random 400~500ms render time on any component that uses even a single Material-UI component, which I believe to be an issue with their styling engine. It's incredibly frustrating.

Since Tailwind is literally just CSS classes, at the very least I know I won't ever run into this.

Re: Coming to Terms with Tailwind

#40

Post by handrous » Wed, Jul 07, 2021, 4:47 PM UTC

tambourine_man wrote: post #16

> Just like I don’t like React I will probably never really like Tailwind. >But that doesn’t mean that I can’t be a professional and write the best Tailwind code I can if that’s what’s asked of me. This is something that I can’t understand. Maybe it’s just me, but we’re incredibly fortunate to be in a market with huge demand. It’s not like we live in a React only world. You can make a pretty good living writing in wh…

Some tech is easier to sell than others, depending on your market. If you're an agency chasing startupy clients, for instance, the more technical people on the other side of the table want to hear that you're going to use tech that they think will look good on their résumés and/or enable them to easily hire startup-type developers, so making sales means choosing some subset of that tech that will make them nod in agreement when you name-drop it, and also enables you to deliver working software efficiently—even if you think there are better tools for the job. For several years this has meant talking about how much your teams just looooove React (whether they actually do is irrelevant).

Same holds for ordinary jobs. Depending on the kinds of jobs you want, it can be a reasonable choice to settle on tech you don't really like, just because the hiring market's hot for that tech, so it's much easier to get hired and/or to command a higher salary.