Building React and Vue Support for Tailwind UI • Hacker News Board

Re: Building React and Vue Support for Tailwind UI

#71

Post by dmt0 » Tue, Apr 13, 2021, 4:25 AM UTC

mike1o1 wrote: post #41

734129837261 wrote: post #38

Tailwind is the weirdest thing I've ever ran across. It's basically inline CSS. Personally, I write CSS this way: 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames. Only when you have troubles selecting an element based on its position in your DOM you should choose a classname. It should not be ".text-gray-500" (like Tail…

This comes up almost every time, but it's not "basically inline CSS". The best thing about Tailwind (and utility classes in general) is that it forces you to use consistent measurements across your app. "Shoot, was this 13px padding or 14px padding on the other page?" Don't worry about it, just use "p-4, p-6, etc.". Thinking in these terms becomes really powerful. Another great thing as that you just simply don't hav…

"Shoot, was this p-4 or p-6 on the other page?"

Re: Building React and Vue Support for Tailwind UI

#72

Post by qudat » Tue, Apr 13, 2021, 4:35 AM UTC

natural219 wrote: post #21

franciscop wrote: post #16

Ah I'm not a huge fan of this: I'd prefer it to be like this: I did some experimenting (I'm the owner of `react-tailwind`, please reach out if you want it!) and it's definitely possible to do that; but it does imply components are purely visual, which I'm not sure it's the way they want to go. It's also not possible to use the colon like `md:...`, but you can do `md="..."` instead, which is a good approximation IMHO

Blurring the line between attributes/react props and CSS classes seems abhorrent to me, but just my two cents

With props you get auto complete which is fantastic for this type of styling work. I’m constantly going to the tailwind website to remember their “DSL” of class names. Autocomplete would dramatically help here.

Re: Building React and Vue Support for Tailwind UI

#73

Post by qudat » Tue, Apr 13, 2021, 4:37 AM UTC

franciscop wrote: post #16

Ah I'm not a huge fan of this: I'd prefer it to be like this: I did some experimenting (I'm the owner of `react-tailwind`, please reach out if you want it!) and it's definitely possible to do that; but it does imply components are purely visual, which I'm not sure it's the way they want to go. It's also not possible to use the colon like `md:...`, but you can do `md="..."` instead, which is a good approximation IMHO

i’d prefer ``

Re: Building React and Vue Support for Tailwind UI

#74

Post by qudat » Tue, Apr 13, 2021, 4:38 AM UTC

CraftThatBlock wrote: post #17

franciscop wrote: post #16

Ah I'm not a huge fan of this: I'd prefer it to be like this: I did some experimenting (I'm the owner of `react-tailwind`, please reach out if you want it!) and it's definitely possible to do that; but it does imply components are purely visual, which I'm not sure it's the way they want to go. It's also not possible to use the colon like `md:...`, but you can do `md="..."` instead, which is a good approximation IMHO

A big issue I see with this is that having custom classes (the whole extensibility point), at least in TypeScript (without re-declaring them).

I investigated figuring this part out. Theoretically you could build a postcss plugin that generates the proper typescript types. It would be difficult.

Re: Building React and Vue Support for Tailwind UI

#75

Post by cjblomqvist » Tue, Apr 13, 2021, 5:09 AM UTC

willhoyle wrote: post #61

This is great work, congrats on shipping a great product. I use TailwindCSS on my personal website. I often wonder whether we need yet another UI framework implementation? I touched on this in my post a couple days ago: https://williamhoyle.ca/blog/2021/vue-has-too-many-ui-framew... To summarize: We have 20+ UI frameworks written in Vue. Surely there's enough common ground/code to combine the implementation details f…

Agreed! I believe the path of popper.js should be of inspiration to a lot of people! Clean separation of concern, high focus, resulting in high quality and high reusability!

Re: Building React and Vue Support for Tailwind UI

#76

Post by aniforprez » Tue, Apr 13, 2021, 5:10 AM UTC

qudat wrote: post #72

natural219 wrote: post #21

Earlier quoted context omitted.

Blurring the line between attributes/react props and CSS classes seems abhorrent to me, but just my two cents

With props you get auto complete which is fantastic for this type of styling work. I’m constantly going to the tailwind website to remember their “DSL” of class names. Autocomplete would dramatically help here.

I know it's not actually a great solution but personally I've had no problems with remebering their DSL because I use the official Tailwind extension for VSCode which also uses your config file to give you autocompletion

Re: Building React and Vue Support for Tailwind UI

#77

Post by aniforprez » Tue, Apr 13, 2021, 5:14 AM UTC

gervwyk wrote: post #63

welder wrote: post #27

Earlier quoted context omitted.

So, the dev never reads/modifies the extracted component that still uses hard-to-read hard-to-typecheck classes? Doesn't seem like a good solution.

It’s a great solution. Every class only maps to one css property setting, and they are very well named. Thus not much more difficult to read and remember than css key value pairs. Why would you typecheck component class names? If so, its all strings, seems pretty easy less error prone than inline styles.

Actually each class does NOT always map to a single property. In what I consider to be its greatest strength each class is actually designed to do some very specific thing that can actually require multiple CSS properties and settings. For eg the breakpoint classes are fairly complex but allow you incredible flexibility in building responsive UIs

Re: Building React and Vue Support for Tailwind UI

#78

Post by aniforprez » Tue, Apr 13, 2021, 5:16 AM UTC

extra88 wrote: post #53

tomc1985 wrote: post #44

Earlier quoted context omitted.

Pretty much every CSS framework under the sun relies on a pile of classnames for each element? Even the most mimimal frameworks from 10 years ago worked this way...

Bootstrap and the like don’t have one property per class name as Tailwind does.

The bootstrap comparison is awful as they both do COMPLETELY different things

Re: Building React and Vue Support for Tailwind UI

#79

Post by seer » Tue, Apr 13, 2021, 5:36 AM UTC

brundolf wrote: post #5

> We crawl this document as an AST, and actually transform it into four formats...The key to getting sensible output is really just having total control of the input format. It's still hard work, but when you can encode the intent of each example into a custom input format, converting that to another format turns out so much better than trying to write something that can convert arbitrary jQuery to React or something…

So true. The thing that put me on the path of discovering parsers was a tweet that said something to the effect of “if you want any relatively complex regex, what you actually need is a recursive descent parser”.

Now as a self thought dev I haven’t really been shown in school what those were and always thought of them as some wizardly magic that only compiler writers dabble in.

But after that tweet I looked around and discovered https://github.com/dmaevsky/rd-parse which is a 100-ish line library, and using it you can do https://github.com/dmaevsky/rd-parse-jsexpr/blob/master/src/... which is a 200-ish lib that parses all of freakin JS expression syntax.

Now whenever we have various custom unwieldy regexes to parse some input, I can refactor that into a clean and easily understandable parser.

I guess thats why you need at least a little bit of formal education in CS.

Re: Building React and Vue Support for Tailwind UI

#80

Post by nailer » Tue, Apr 13, 2021, 6:01 AM UTC

cageface wrote: post #51

nailer wrote: post #46

Earlier quoted context omitted.

That’s definitely true. I just wish tailwind encouraged consistent styling (by having a design guide and variables) rather than styling individual elements in their documentation, which means someone has to clean up the mess later.

In practice I find UI built with Tailwind to be a lot more consistent because all the dimensions are built from standard values instead of custom dimensions for every css class. The bigger problem in my experience is that most designers are too lazy to set up a type and color scheme up front and just drag whatever looks good to them in their sketch/figma files.

You mention the issue being solved is having standard dimensions.

We’ve been doing this in CSS for quite some time using variables. This didn’t require adding a fairly leaky and thin abstraction on top of CSS and adding thousands of copy pasted singleton styles to our projects.