Hacker News Reader

Comment by antihero | Hacker News Reader

Yeah because you’ve jumped in on the attack on a post about something built with a tool that clearly gives a lot of people joy, in order to hawk your own thing. Getting whiny about people defending their own thing in response is kind of disingenuous.

People got tired of vue people continuously doing the same thing about anything vaguely related to react, too.

View on HN

No, what I'm actually getting tired of is people getting on the hip new proprietary but trendy JS/CSS thing like Tailwind and leaving other devs to clean it up in a few years.

And your Typescript CSS in JS thing using some new thing? TW is at least well documented and widely used and based on a fairly formalised bunch of classes that builds upon a concept that’s been used for 10+ years.

It's not my thing, I didn't make it, for one.

Then just use CSS at that point, it's been here 20+ years then. I simply don't understand how it can be superior to regular CSS in any way simply because it maps one to one onto CSS properties anyway.

> I simply don't understand how it can be superior to regular CSS in any way simply because it maps one to one onto CSS properties anyway.

Could just read the docs. https://tailwindcss.com/docs/utility-first

I did, I even read Adam's initial post here on Hacker News itself. Just because they say it's better doesn't make it actually better. Indeed, to me, it is strictly worse.

> Just because they say it's better doesn't make it actually better.

They didn't say it's better. They said go ahead and use it first, before pulling out opinions. I perfectly understand your position, I've been there too but it's a complete 180 experience after you build just 1 project with it. It's a "won't go back" experience.

I think you missed my previous comments saying how I've used it extensively the past few years for employers. It's like a bell curve, you like it and think, wow, this is amazing. Then as the years pass and you start having to maintain it, you steadily dislike it until you get to not wanting to use it anymore at all. The people who currently like Tailwind might simply not have gotten to this later stage yet.

> Then as the years pass and you start having to maintain it, you steadily dislike it

> The people who currently like Tailwind might simply not have gotten to this later stage yet.

And yet somehow the projects you were assigned did? I don't mean any disrespect, but I find it a bit questionable that any big project that uses Tailwind has had maintainability issues when Tailwind itself is pretty new to the scene.

It'd be hard for you to prove this to be honest, while on the other hand, I could give you hundreds of thousands of testimonials countering your argument.

Hundreds of thousands of testimonials from companies using it in production and had been for the past few years and as not a new project? Sure, send me a list. I expect to see all of the hundreds of thousands of them on the list. My email is in my profile.

It's anecdotal experiences at this point. As I said, I was using Tailwind from the beginning and loved it at first. Then the problems started.

I do bare CSS for quick POCs but never on real projects. Vanilla JS & CSS sounds romantic when you solo but in a team setting it's better to use something we're all familiar with.

At work we switched over from SCSS modules+global styles to Tailwind last year and it has been great so far: 1. No more custom CSS. No need to think how to name your classes. No more unused CSS. 2. Code completion (VSCode plugin for TW classes) 3. Well documented. Even our BE developers are able to jump in and do minor changes.

The long CSS class name strings look funny but nobody complained about it in our team. Choose whatever works for your team. Tailwind has been nothing but a pleasure for us.

Tell me how it goes in 5 years time because that's what I'm dealing with currently.

Tailwind is under the MIT license. In what sense is it proprietary?

I should have meant proprietary as in non-standard, not non-open-source. By proprietary I meant that they wrote their own DSL and in the future if it needs to be ported over, it will be much harder. It's like CoffeeScript versus Javascript/TypeScript.

So it's a criticism which applies to literally every use of some library or framework to make writing web apps easier.

Sure, you could see it that way. That's generally why I also don't use libraries that haven't shown themselves to be durable; I'll use React because it's ten years old and has enough support so that if people do decide to migrate later on (due to technological improvements à la jQuery to pure JS and TS), it's easy to do so, and it's why I don't use much newer libraries like Svelte or SolidJS.

How exactly do things get proven to be durable if people don't use them in the first place?

People can use them, I don't though.

Reply on news.ycombinator.com