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

Working with Tailwind CSS every day for 2 years

themosaad.com

Post reply on HN
Print view View original

181–190 of 215 posts

Re: Working with Tailwind CSS every day for 2 years

#181

Post by themosaad »

deliriumchn wrote: post #9

I'll be honest here, after working with tailwind for 7 months I really hate this piece of tech and really regret picking this company. I thought it wouldn't be a big deal but after seeing unnecessary long walls of class names I'm really tired. Anything other than basic styling is an absolute pain with tailwind and I don't understand why /my company specifically/ can't just use typestyle/styled-components/css modules…

I do dislike long walls of classes as well. However, I'm yet to find an alternative that offers the same benefits Tailwind CSS offers without such compromises.

Wrote about Vanilla-Extract shortcomings here https://news.ycombinator.com/item?id=33793944

Re: Working with Tailwind CSS every day for 2 years

#182

Post by nirvdrum »

dimmke wrote: post #170
nirvdrum wrote: post #168

Earlier quoted context omitted.

Thanks. I did overlook that. Although, the docs are a bit foreboding. "Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse." Then it lists a bunch of reasons that seem to just be the author's preferences on things like naming and workflow productivity. I guess I don't…

I agree that some of it is preference, but the main point he is making is that the number of utility classes doesn't matter if you're using a framework and styling a component. Yeah, it's ugly markup but so what? With that said, I think it's reasonable to roll some things up into general classes. They remain very easy to change. >I haven't seen anyone argue not to use React or Web Components because naming a componen…

Got it. So this would be more of a hybrid approach and clears up that question on naming granularity. Give the "component" a logical name and use the utility classes for the component's entities. That makes a lot more sense to me. I didn't realize those child entities were the things people were giving names to. CSS has fairly rich ancestry rules, so I just assumed people use them.

Thanks for taking the time to clarify that for me. It does indeed change my perception on utility classes.

Re: Working with Tailwind CSS every day for 2 years

#183

Post by mind-blight »

karaterobot wrote: post #165
mind-blight wrote: post #102

Earlier quoted context omitted.

I actually think a lot of CSS-in-js frameworks became popular for the same reason that React became popular: css, html, and to some extent JavaScript can't really be decoupled. Things like CSS Zen garden made it seem like they were, but that was only a separation of control. If the HTML structure changes, then the CSS likely needs to change. That's a tight coupling. CSS-in-js embraces the coupling and makes it explic…

I wrote that because the benefit most people who liked styled-components told me they appreciated was that they didn't have to think about inheritance. Everything is encapsulated in the component. This, to me, is equivalent to saying "I think the cascading part of CSS is either a mistake, or too complicated to maintain in practice, so I am going to eliminate it."

> This, to me, is equivalent to saying "I think the cascading part of CSS is either a mistake, or too complicated to maintain in practice, so I am going to eliminate it."

I agree both with your interpretation, and with the sentiment. I think, in many contexts, using the Cascading part of CSS is a mistake. It's great for low-level design system kinds of work (e.g. setting matching text and BG color, then override font size or decoration later). But, it's pretty problematic when you start styling specific components in a web app. (This is less of an issue with static documents).

If we're using SASS instead of a css-in-js, we end up doing things like:

``` .my-custom-hero { h1 { // override necessary styles } } ```

That's essentially the same encapsulation. It's just hidden in a one-off class in the CSS rather than embedded with the HTML - which makes it even less legible. It also has a dependency on the root-level `h1` styles. If someone change those, they inadvertently change the hero's styles.

We could get around that by having a `.my-custom-hero .my-custom-hero-title`. But, that's essentially a worse version of css-in-js encapsulation: I have to come up with names for everything, and my component's internals are split across multiple files.

Re: Working with Tailwind CSS every day for 2 years

#184

Post by iudqnolq »

mhoad wrote: post #62

I haven’t seen it mentioned in this thread but for those who like Tailwind in theory but hate all it’s drawbacks you might be interested in Open Props ( https://open-props.style/ ) which is put together by a member of Chrome’s devrel team. The first 10 minutes or so of this video is also a decent introduction it seems which will help put this project into context for you so you can see specifically what kinds of prob…

That website has visual bugs and lag in Firefox. When I combine that with my general stereotypes about Chrome devrel I think this isn't for me.

Re: Working with Tailwind CSS every day for 2 years

#185

Post by themosaad »

zupa-hu wrote: post #121

I think Tailwind is great but I agree with many of the issues raised. I desperately needed a _language_ instead of a framework back when Tailwind was still a framework. As I could not get any response from them, I ended up rolling my own called Turbo CSS - this was like 2 years before their compiled version came out. Take a look if you want to consider alternatives. https://developer.boomla.com/turbo-css I'd compare…

Great work scratching your own itch! Not as easy addition to the workflow as it doesn't have a CLI but I think that's intentional or not a priority for you.

I backed out from maintaining a big Tailwind CSS plugin let alone create my own solution.

Similar to React, I don't think Tailwind CSS is easy to replace regardless of the slightly better alternatives that exist or might popup up due to its established community.

Re: Working with Tailwind CSS every day for 2 years

#186

Post by themosaad »

AlwaysRock wrote: post #12

I've been using it regularly for the last 6 months and like it a lot. The blog points out the biggest switching over issues. Converting from rem to px can be annoying if you cant do that math in your head and at first you are often looking up the "simple" tailwinds way to write a css property that you already know. I pretty much always have the tailwinds docs open and thankfully they are very good and searchable. It…

Forgot to mention that I no longer do these conversions for the most part, instead, I scroll down the suggested values from the Tailwind CSS IntelliSense VSCode extension since it displays the equivalent values in pixels.

Re: Working with Tailwind CSS every day for 2 years

#187

Post by themosaad »

joshmn wrote: post #4

I have been working with HTML since I was 11 — 20ish years. I thought I knew most things. text-decoration-thickness? Nope. I have been adding border-bottom to spans for far too long it looks like.

That's a good side effect from using Tailwind CSS docs. They curate new CSS properties and add the most important (in their opinion) once they're supported by all modern browsers.

Re: Working with Tailwind CSS every day for 2 years

#188

Post by mixmastamyk »

PainfullyNormal wrote: post #136
esparrohack wrote: post #123

This style comes and goes. Utility classes. Then a framework like bootstrap comes up. Then it’s back to utility classes. I feel like I’m taking crazy pills

> I feel like I’m taking crazy pills You're not. If you look hard enough, long enough, you'll see this same pattern in every corner of programming. Round and round, never forward.

With love we'll find a way, just give it time

Re: Working with Tailwind CSS every day for 2 years

#189

Post by [deleted] »

734129837261 wrote: post #22

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

[deleted]

Re: Working with Tailwind CSS every day for 2 years

#190

Post by montroser »

lghh wrote: post #141
icambron wrote: post #83

A lot of people I respect really like Tailwind, but I just don’t get it. Seems like you end up with walls of classes because you don’t name your compositions, and thus your design system doesn’t actually live anywhere. If you have a standard box in your design system with a certain padding, spacing, font size, and so on, are you really going to write out all its constituent properties every time you use it? How do yo…

You manage this complexity the same way you manage the complexity of repeated code nearly anywhere else: you encapsulate. If you have a standard box (div + styles) that you use everywhere, abstract it in whatever way you're writing your application allows. For example, a component in React.

Or...a CSS class? I think the point is that CSS already has the means for abstraction built right in. Using an application framework in order to abstract a list of styles adds unnecessary complexity that compounds upon itself.

Somebody writes a React component to abstract a button and its standard styles, and all seems simple enough. Then we need marketing styled buttons, and buttons that are anchor elements, and ones that are small and large, and inverted and with and without shadows because the design people insist, with icons, block width, pills, etc, etc. And you end up with a monstrosity component with all sorts of bespoke interface that everyone has to learn, when some cascading classes and plain HTML would have entirely sufficed.

Post reply on HN