Comment by crowcroft | Hacker News Reader

Comment by crowcroft | Hacker News Reader

Parent Full thread

Is that more or less verbose than

  button {
    position: relative;
    cursor: pointer;
    overflow: hidden;
    border-radius: 0.375rem;
    border: 1px solid #0a0a0a;
    background-color: #171717;
    padding: 6px 12px;
    color: #f5f5f5;
    box-shadow:
      inset 0 1px #525252,
      0 4px 6px -1px rgb(0 0 0 / 0.1),
      0 2px 4px -2px rgb(0 0 0 / 0.1);
    transition: all 150ms cubic-bezier(0.4, 0, 0.2, 1);
  }
  button::before {
    content: "";
    position: absolute;
    inset: 0;
    background: linear-gradient(to bottom, rgba(255, 255, 255, 0.2), transparent);
  }
  button:hover {
    background-color: #262626;
  }
  button:active {
    background-color: #0a0a0a;
    box-shadow:
      inset 0 1px #262626,
      0 0 #0000;
  }

Sure, separating the code into a CSS file means it's not in your HTML but that doesn't mean it doesn't exist. Similarly you can move the button out to a component and reference that if you want to hide the code.

I find it easier to locate things in the HTML broken into components because the style is co located with the object being styled. I find it much more difficult to navigate through CSS and find out what classes are doing what exactly. Especially when a project grows over a long period of time and different people write CSS differently (and throw a few !important's in to make sure they can meet a deadline).

Each to their own though.

It's not quite apples-to-apples because the Tailwind code is using design tokens and the CSS is not. You should (for example) replace the long `box-shadow` value with `var(--shadow-md)`.

Anyway, to me this question is kind of like asking "Is it easier to break your writing into paragraphs, or write everything in one long block?"

Like, what would you think if I formatted my comment like this?

> It's not quite apples-to-apples because the Tailwind code is using design tokens and the CSS is not. You should (for example) replace the long `box-shadow` value with `var(--shadow-md)`. Anyway, to me this question is kind of like asking "Is it easier to break your writing into paragraphs, or write everything in one long block?" Like, what would you think if I formatted my comment like this?

This isn't something a web developer should be doing in 2025. The styling should be generated by the software used to design the UI.

Why aren't the companies building design tools solving this?

I think you should find a new job.

XML developer

Adobe has been trying to build this product for 30 years and still haven't figured it out. Figma is trying and the best you can get is partially usable copy and paste CSS.

This is a "why don't they just make self-driving cars" question. The answer is that there are too many edge cases.

I don’t think building autonomous cars is on the same level as writing CSS.

We're entering a phase where natural language becomes the main interface for html and css development. Companies like Vercel, Wix, and Framer are integrating AI to turn design prompts into working UI components.

This is only the beginning. Within 2 to 3 years, domain-specific language models, trained specifically on frontend code, are expected to become common.

Regarding Adobe, they never really understood developers.

I'll believe it when I see it, and so far what I'm seeing is "a llm lied to me and deleted my codebase"

Most people use Tailwind with components, and so when you talk about breaking things out into paragraphs, that would be the equivalent.

Sure that html looks a bit messy, but once you write it once you're never looking at it again. In your view files you're just writing.

  <Button>Click Me!</Button>

Or perhaps injecting variables etc.

  <Button color="red" style="outline">Click Me!</Button>

I'm not really trying to argue that Tailwind is better or worse, I'm just saying it's a valid way to do things and there's nothing inherently wrong or flawed with it.

There is also additional risk by overusing CSS's built-in selectors and inheritance, whereas there's zero risk with Tailwind.

To each their own, the Tailwind version is more readable for me.

1. highlighting

2. syntax checking

3. language servers.

100% this. People have all of these highfalutin arguments about tailwind being the wrong abstraction/non idiomatic etc. But, as someone who writes a lot of CSS—not having to jump back and forth between a CSS file and a HTML file is a game changer. CSS files are just another thing to maintain, and a painful one at that, since CSS is mostly organized relatively arbitrarily. This is why Tailwind won; reducing the surface that developers have to maintain is a big deal.

There are simply so many decisions when choosing how to implement CSS in a project—where should we put the files, should they be component based or global, what preprocessor if any, etc etc. With Tailwind, you don't have to worry about any of that.

Reply on news.ycombinator.com