Tailwind: style your site without writing any CSS • Hacker News Board

Re: Tailwind: style your site without writing any CSS

#181

Post by owenmelbz » Sun, Nov 04, 2018, 8:44 AM UTC

Too much to read xD if anybody gets this far then remember this...

1. People arguing against this are arguing against utility classes and not arguing against tailwind.

2. Tailwind is different - it’s a toolset allowing you to build your own framework - you can use the tailwind config to define your variables and use BEM or what ever you want.

3. Tailwind is utility “first” - so it provides all the utilities you need, YOU decide how to use them, put them all in your HTML if you like, or make components out of them, include them into an existing project, etc.

So everybody here who is being negative towards tailwind regarding utilities is wrong - because they haven’t understood tailwind. - your arguments may be valid for utility classes, but this topic is about tailwind, so your spreading misinformation.

Re: Tailwind: style your site without writing any CSS

#182

Post by lmm » Sun, Nov 04, 2018, 11:13 AM UTC

icebraining wrote: post #110

lmm wrote: post #61

Earlier quoted context omitted.

> So if you have a large number of buttons or other elements with the same class you will be repeating yourself over and over. In the HTML, sure. But so what? It gets compressed in transport so there won't be significant overhead there (similar to how remote desktop protocols that send images with compression turn out to be just as efficient as those that tried to send intelligent drawing commands), and the browser h…

What frameworks treat HTML as an output format, and what is the input? When I see samples of React code, all the HTML (in the form of JSX) is still handwritten, just combined dynamically.

Sure - you write the html snippets by hand (and those are still very maintainable if you use inline styles). But you don't maintain the final page that might have e.g. twenty buttons, so that's not a case to optimise for.

Re: Tailwind: style your site without writing any CSS

#183

Post by trwhite » Sun, Nov 04, 2018, 2:44 PM UTC

Several people here say "this doesn't scale" but I'd be curious to find out:

- The 'scale' at which they think a framework like this doesn't work (number of users, devs etc).

- The scale of the projects they work on.

Who even says a framework needs to be adopted by tech giants or work at 'scale' to have any credibility?

A utility-based approach has been adopted at the last 2 companies I've worked for and it's been very effective, often when working with very complex designs on medium-sized sites (that serve less than 100k users/month).

Some of my previous colleagues and I work on https://github.com/friendsthatcode/flavourcss, which was inspired but some of the ideas behind Tailwind and our own work.

Re: Tailwind: style your site without writing any CSS

#184

Post by armandososa » Mon, Nov 05, 2018, 6:15 PM UTC

chrisweekly wrote: post #150

armandososa wrote: post #140

This is not for me. I am very good at, and very comfortable writing CSS since I've been doing it since the CSS Zen Garden days. But I understand the pains this is trying to solve and I think that this is the wrong approach and also the wrong abstraction. - If you don't like CSS, this will not help you write less CSS, it will only make you write it inline and using a weird syntax. - If you want to do the sensible thin…

Tailwind and CSS-in-JS are not mutually exclusive! On the contrary, they're a terrific match!

Hmm. That's an interesting syntax. I still don't like it and would hate to work on a codebase that used that for styling but I'm happy to know that it exists as an option for people who like tailwind!!

Re: Tailwind: style your site without writing any CSS

#185

Post by neurotrace » Tue, Nov 06, 2018, 7:00 PM UTC

jacamat wrote: post #165

neurotrace wrote: post #141

Earlier quoted context omitted.

In what way is it not? You'll consistently get 10 or 12 colors instead of getting an inconsistent set of colors, for example.

But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray? these inconsistencies compound, especially across teams.

Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.