Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vanilla JavaScript support for Tailwind Plus

tailwindcss.com

Post reply on HN
Print view View original

101–110 of 202 posts

Re: Vanilla JavaScript support for Tailwind Plus

#101

Post by Brajeshwar »

emmanueloga_ wrote: post #84
ricardobeat wrote: post #67

Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.

In real projects I typically group the classes in a way that makes it easier to read, something like this: ... I currently do this manually but it would be nice to have some tooling to automate that kind of format.

I do this to this day, when I’m writing manual vanilla CSS. I group spacings, fonts, texts, borders etc together so it is easier for me to debug without using too many tools.

Re: Vanilla JavaScript support for Tailwind Plus

#102

Post by yoz-y »

gnarbarian wrote: post #94
ricardobeat wrote: post #67

Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.

We need a total and complete stop to all front end development until we figure out what the hell is wrong with them.

Some people (I suspect a lot of young and motivated developers) think that UI development should be easy and elegant.

But consider that a UI is 100% state management and side effects (so fundamentally imperative and asynchronous). On top of that it takes about three revisions for any tool to require bespoke display of something (everybody has an opinion). They also bring a layout engine which is best expressed in constraints.

And somehow we are trying to shoehorn all this into a functional paradigm.

Re: Vanilla JavaScript support for Tailwind Plus

#103

Post by Brajeshwar »

ricardobeat wrote: post #67

Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.

I have a feeling that Tailwind started with a good intention to be a utility classes CSS framework, akin to “Bourbon on Steroids”, but people began to accept and use their prototype/sample/example codes way better than they had intended, and they ran with it.

I stumbled on Tailwind in 2018 and introduced it to a team looking to revamp a pretty massive project. I remember that the initial proposal I made was to treat it like Bourbon[1] and write classes that build on Tailwind’s utilities. That way, you can still have `.button`, `.button-primary`, and `.button-primary__accent` etc without the cryptic classes in the HTML.

However, after reading Tailwind, the team found it much easier to write the pre-built classes and stack them as they progressed. And it worked; if I don’t care about how the code is written, things were consistent. It reminds me of “Pixel Perfection” before the responsive design era, when things looked as designed in Photoshop and printed for clients during presentations.

1. https://www.bourbon.io

Re: Vanilla JavaScript support for Tailwind Plus

#104

Post by paradox460 »

skydhash wrote: post #90
paradox460 wrote: post #75

Earlier quoted context omitted.

People would rather have to parse out a big dumb list of classes than look at the actual list of what properties affect something, with a clear ability to drill down into them. Its madness, akin to carpenters giving up hammers, preferring to use glue, because they hit their thumb a few times by accident

Based on the code I've seen, including written by old me, it seems more like designing the architecture of the CSS styles (and sticking to it) is something people don't like to do. Tailwind is just a tool that is nicer than using the style attribute on the element. I strongly prefer "button is-primary is-fullwidth" over the long list of tailwind classes.

Same. And all the arguments about using component libraries, like the op, fall flat when you realize components can have scope local styles

Re: Vanilla JavaScript support for Tailwind Plus

#105

Post by MrJohz »

lemonberry wrote: post #89
reactordev wrote: post #85

Earlier quoted context omitted.

But at what cost? If it’s not a CSS builtin, it’s going to use JS - it may not be something you care about, but it will be there. There’s no other way.

I believe it's regular old css. The :has() pseudo class. https://developer.mozilla.org/en-US/docs/Web/CSS/:has

It's not even :has, it's just how child selectors in CSS have always worked.

    // Not actually needed, here
    // for competition
    .group {}

    // Child selector
    .group:hover group\/hover\:bg-black {
      background-color: black; 
    }

    // Which is essentially the same as
    .group:hover child {
      background-color: black; 
    }

Re: Vanilla JavaScript support for Tailwind Plus

#106

Post by iambateman »

Jaygles wrote: post #100
AstroBen wrote: post #97

Earlier quoted context omitted.

I just can't fathom how someone can look at this and think "yeahhhh thats some good clean code". How did tailwind get so popular? Learn plain CSS. It's really good now

I've worked in many different FE codebases with a variety of CSS "strategies". This sort of thing is objectively ugly and takes a minute to learn. The advantages of this approach I found is two-fold 1. You can be more confident that the changes you are making apply to only the elements you are interested in changing You are modifying an element directly. Contrast with modifying some class that could be on any number…

Agree, and to add…the “component” still needs to exist somewhere in the system for tailwind to make sense.

No one is writing a long paragraph of styles for _every_ button in their app.

Re: Vanilla JavaScript support for Tailwind Plus

#107

Post by AstroBen »

Jaygles wrote: post #100
AstroBen wrote: post #97

Earlier quoted context omitted.

I just can't fathom how someone can look at this and think "yeahhhh thats some good clean code". How did tailwind get so popular? Learn plain CSS. It's really good now

I've worked in many different FE codebases with a variety of CSS "strategies". This sort of thing is objectively ugly and takes a minute to learn. The advantages of this approach I found is two-fold 1. You can be more confident that the changes you are making apply to only the elements you are interested in changing You are modifying an element directly. Contrast with modifying some class that could be on any number…

This is one of the least elegant ways to scope CSS though.. you may as well just write inline CSS

I like BEM personally. "navbar__item" scopes the styling to the nav item

> Once you're well familiar with your toolset, you know what to reach for to quickly reach a desired end state

This also applies to plain CSS, doesn't it?

The big value add that Tailwind brought isn't their utility classes IMO - it's their philosophy around having a design system of consistent coloring and spacing. I actually borrowed that for my own projects. It taught me to be a lot more diligent about specifying the system upfront. Put it in CSS variables and re-use those

Re: Vanilla JavaScript support for Tailwind Plus

#108

Post by pjmlp »

AstroBen wrote: post #97
ricardobeat wrote: post #67

Lovely. Verbosity aside, now on top of knowing CSS you need to learn another hierarchical system within class names.

I just can't fathom how someone can look at this and think "yeahhhh thats some good clean code". How did tailwind get so popular? Learn plain CSS. It's really good now

No idea, thankfully I am doing mostly backend and devops stuff, so I don't need to care.

If I do something myself, I keep using bootstrap, as it is good compromise for those of us not honoured with CSS mastery.

Ironically I have no issues making great looking UIs with native toolkit.

In 5 years the tailwind craziness will be replaced by the next shiny CSS of the month.

Re: Vanilla JavaScript support for Tailwind Plus

#109

Post by pjmlp »

yoz-y wrote: post #102
gnarbarian wrote: post #94

Earlier quoted context omitted.

We need a total and complete stop to all front end development until we figure out what the hell is wrong with them.

Some people (I suspect a lot of young and motivated developers) think that UI development should be easy and elegant. But consider that a UI is 100% state management and side effects (so fundamentally imperative and asynchronous). On top of that it takes about three revisions for any tool to require bespoke display of something (everybody has an opinion). They also bring a layout engine which is best expressed in con…

Mostly is, with native toolkits, Web should have stayed for hypermedia documents, but here we are.

I have used and programmed enough kinds of UIs, since I got coding into that Timex 2068 in 1986.

Post reply on HN