Hacker News Reader

I applaud your pragmatism. And I wish this pragmatic attitude was more common here, it’s refreshing in a sea of negativity whenever anything about web dev is posted.

Re: CSS layout. It’s actually just a very big, complex practice to become proficient in. If you’re ever inclined to go back and relearn it, it helps to accept that from the outset. Once you’ve accepted that it’s a fairly involved learning process, the successes should feel more significant and the failures hopefully more temporary. But!

Re tailwind: if it’s working for you, and you never feel compelled to drop into lower level styling concerns, that’s fine. Great even. You’re getting stuff done that you want to do, with tooling that addresses your needs! I don’t personally love tailwind, and I much prefer to write styles directly… but it’s obvious tailwind solves this well for you and others who don’t share my preference.

Re CSS vis tailwind: probably overly pedantic, but you are still using CSS. You’re just not authoring it directly. I’m only pointing this out because you may find a time when tailwind doesn’t do everything you want/need, and it’ll help to know it isn’t some styling black box. It’s just a very thoroughly robust abstraction around the styles you could write directly if you choose. And if that abstraction, however robust, doesn’t fit your needs, plain CSS is always there to supplement it.

Thanks for you words, comments like these make me appreciate sharing my thoughts here! Regarding your points, I don't see myself getting deeper into CSS in the near future, but I can't say it will never happen. For now though, I see both CSS and tailwind as means to an end and I am not yet interested in understanding how they work.

I've been through your journey, and CSS was by far the hardest to wrap my head around. Once JS clicks the journey is smooth, but CSS always feels like it'll be hard.

And then one day ... there it is. It all just makes sense. Not as much sense as JS! But enough sense for me to think, huh, I never thought I'd get this.

My one criticism of Tailwind, which I enjoy but do not currently use, is that it's likely to delay if not prevent this ultimate moment. If your long-term goal is to be a proficient front-end developer, I think you should try getting dirty with CSS sometimes.

Not always! Use Tailwind when you have a thing you need to get done. But sometimes.

Tailwind is vanilla CSS though right? If someone created a stylesheet that just mapped one class to one CSS rule, and did that over and over for all the kinds of rules (with sensible spacing variations), you've got 90% of what tailwind is as far as I understand.

It's just CSS classes.

> mapped one class to one CSS rule

So they essentially reinvented the style attribute in a less verbose form?

Yes, along with the variations. So you can do things like “text-green hover:text-red”

Some of the other 10% is stuff around theming and design systems. This isn't something that injects cleanly into inline styles. Also media queries and hover states etc can't be done inline.

If it's a reinvention it's objectively better at least.

I think you're confused. What they're saying is it's a reinvention of

  ```css
   .card {
     ...
   }
  ```
  ```html
   <div class="card" />
  ```

RATHER than a reinvention of

  ```html
   <div style="..." />
  ```

I meant this tailwind framework looks like a reinvention of style="..." inline styles.

  <div class="block">...</div>
  <div style="display: block;">...</div>

https://tailwindcss.com/docs/display

So we've gone from inline styling to separating markup and presentation with CSS but now we've gone back to inline styling.

The whole separating markup from presentation doesn't quite work for any non trivial web-app type of webpage.

Because the presentation affects markup. You'll have to add wrapping divs to accomplish any kind of complex layout for example.

Once you can't separate it in your mental space, it doesn't matter that its in two different files.

But the solution is to turn CSS into inline styles?

> You'll have to add wrapping divs to accomplish any kind of complex layout for example.

I don't know about that. I think selectors are pretty powerful. Have managed to avoid littering the HTML with structural nodes by using them creatively. CSS has gained a huge number of features since I first learned it, there's even better ways to do stuff now.

Less verbose? Ha, far from it. Look at the tailwind examples. One div tag now has 6 or more classes attached

Well I suppose it's less verbose than a lengthy style="..." attribute that accomplishes the same thing.

Now it's a lengthy css instead. It seems to me we are going backwards...

Out of interest, have you built anything non-trivial with tailwind?

I've used CSS, and Tailwind and not worrying about naming everything correctly and not skipping around different files is a dream for me. Perhaps that's my brain, Idk.

Further I have gone over old code, and haven't had any problem with maintainability

> Well I suppose it's less verbose than a lengthy style="..." attribute that accomplishes the same thing.

It's not actually the same thing. What you're talking about is inline styling which takes precedence over class-based styling. It's generally considered bad practice to rely on inline styles. The traditional approach is `style="card"` not `style="...a bunch of rules..."`

  <div class="block text-black">...</div>
  <div style="display: block; color: black;">...</div>

Looks like the same thing to me. Only shorter.

With traditional css you'd most likely have a class for all the relevant attributes.

Of course. That's how I learned CSS and how I wrote the CSS for my site. Apparently that's not how things are done these days. People have one class for every property and value combination now and essentially write the entire class inside the class="..." attribute. Can't understand why.

Like I said. It's not at all the same thing. Inline styles have different behavior from class-based styling

Which was always what anyone with any sense wanted. CSS selectors were a mistake, no-one actually writes web pages like the CSS Zen Garden nor should they. The only problem with inline styling was the verbosity (and even then, we've had transparent compression in HTTP for about 30 years now).

I think it's nice I can change "color: red" to "color: blue" and "padding: 1rem" to "padding: 1.5rem" in one place and have it take effect everywhere it's relevant.

You can do this with CSS variables now I suppose, but this very quickly becomes "CSS classes, but with extra steps".

> I think it's nice I can change "color: red" to "color: blue" and "padding: 1rem" to "padding: 1.5rem" in one place and have it take effect everywhere it's relevant.

I agree, but that place is normally the code/templating engine that generates your webpage. So it really shouldn't matter if it's repeated on the wire.

> You can do this with CSS variables now I suppose, but this very quickly becomes "CSS classes, but with extra steps".

Variables are much simpler and easier to understand than selectors.

> CSS selectors were a mistake, no-one actually writes web pages like the CSS Zen Garden nor should they.

I see, we finally reached the root of the issue.

Why are CSS selectors a mistake? Doesn't seem that way to me. Why shouldn't I use them?

Complete lack of encapsulation. You never know when changing one element is going to change another, seemingly unrelated element - e.g. you add a class to a high-level element expecting to get a border around your page, and it gives you a border around your page but also around some small elements on your page that are picked up by that same selector. You can't reliably reuse your styling or components between pages, because the exact same element placed in two different pages might end up with radically different styling.

> You never know when changing one element is going to change another, seemingly unrelated element

Isn't this a symptom of the selectors not being specific enough?

> You can't reliably reuse your styling or components between pages, because the exact same element placed in two different pages might end up with radically different styling

Can you give concrete examples of this happening?

I can provide an example I think is a good use case for highly specific selectors: turning HTML lists into file system trees.

https://www.matheusmoreira.com/css/tree.css

  ul.tree,
  ul.tree ul {
    list-style-type: none;
    padding: 0;
  }

  ul.tree li {
    margin-left: 1em;
    border-left: 2px solid var(--tree-color);
  }

  ul.tree li code {
    display: block;
    position: relative;
    padding-left: 1em;
    padding-bottom: 0;
    line-height: 1em;
  }

  ul.tree li:not(ul.tree > li:first-child) code::before {
    content: "";
    position: absolute;
    left: -2px;
    width: 0.75em;
    height: 0.5em;
    border: 2px solid var(--tree-color);
    border-top: 0 none transparent;
    border-right: 0 none transparent;
  }

  ul.tree li:last-child {
    border-left: 2px solid transparent;
  }

  ul.tree li:has(ul) > code::after {
    content: "/";
  }

  <ul class="tree">
    <li><code>~/.files</code>
        <ul>
          <li><code>~</code>
              <ul>
                <li><code>.bash_profile</code></li>
                <li><code>.bashrc</code></li>
                <li><code>.vimrc</code></li>
                <li><code>...</code></li>
              </ul>
          </li>
          <li><code>GNUmakefile</code></li>
        </ul>
    </li>
  </ul>

That sort of thing feels like a perfect fit for CSS selectors to me. I admit it's not a super complex design (or even a beautiful one, I suck at design) but it does demonstrate the value of selectors.

> Isn't this a symptom of the selectors not being specific enough?

Well, yeah, but that's a "you're holding it wrong" argument. If you make your selectors specific enough then they will apply to the right elements, and if they applied to the wrong elements, well, they weren't specific enough. In practice people resort to only ever using a classname as a selector because anything else is too likely to break; there's no way to find out which selectors apply to which elements or which elements are covered by which selectors (e.g. you can't do the equivalent of "find references" on a variable).

> Can you give concrete examples of this happening?

Only on the level of, like, "my company's whole webapp" (but I've seen it cause real bugs in prod if that's what you're getting at). Getting surprised by which selectors get applied isn't a problem you can show in small examples, because it doesn't happen with small examples; it's only when the selectors and DOMs are too complex to keep in your head that you have a problem.

> That sort of thing feels like a perfect fit for CSS selectors to me.

Why does it need selectors though? It doesn't change based things at higher level (which is the failed ideology that the likes of the CSS Zen Garden were pushing - the idea that you want your component's styling to magically change to fit in with the page it's on or what's happening around it). What are you doing here that you couldn't do with a self-contained component that knew how to style itself?

You can think of it like the style attribute, but with support for CSS media queries, pseudo classes, variables and everything else. If the style attribute let you do that from the beginning of the web, would we have ever felt the need for separate stylesheets? Web development might have turned out quite different.

It is just CSS, but I would not consider equating tailwind to CSS. Instead, I write tailwind utility classes that seem more friendly and approachable to me and their behaviour is also much more predictable to be at least so far. While it does get mapped to CSS in the end, I dont really have to read/understand that generated CSS and just enjoy tailwind handling it for me.

It's more than just CSS classes. If it was just CSS classes I think people should just make their own utility classes. It adds a build step for things like, for example, tree-shaking (it'd be a massive amount of wasted CSS to add classes for EVERYTHING). It's also yet another configuration to manage

My experience with Tailwind was with Fresh which did NOT allow you to use regular CSS. I found that Tailwind was far from enough to accomplish everything you need and often made it particularly hard to build an accessible web app of any complexity. In addition, anyone looking to mess around with psuedo classes or even just have a more unique style will likely find Tailwind to get in the way more than it helps. At least when it's the only tool you're allowed to use. I understand being forced to ONLY use Tailwind is not how most people have had to experience the tool but my personal experience has made me extremely weary of it

I also just don't really understand. It adds a complicated build step. I already previously heavily used "utility classes" in my own vanilla CSS projects and so can anyone else without adding a complex build step. This also inherently provides something like tree-shaking. You don't have any css code you're not using since you only define the classes you want. You also get to know all the CSS variable names.

For small projects, Tailwind feels like an overengineered solution to a non-problem (though I respect that it has helped a ton of people bad at CSS make decent looking websites). For large projects, it quickly becomes more of a crutch than a help. For frameworks like React, styled-components already solves issues TW supposedly helps alleviate in a much more elegant way.

It seems like the niches TW is helpful for is medium-sized projects and for people who are just... not that good at CSS and not interested in improving

Why does it help people who are not good at css though? That part I've never understood

For example if you type "center" into the search engine on their docs you'll get a modern reasonable way to center things (flexbox or grid). Whereas if you Google for css centering you'll run into all sorts of different ideas.

I really like the minimal approach. I started my site as just a GitHub Pages repository with hand-written HTML and CSS. Eventually that became too painful due to the layout repetition and verbosity of HTML. I wanted a lightweight HTML templating language. Pug was great back then but it is now unmaintained. So I forked it into a new project and customized it for my needs.

Same!

Really wanted to start from scratch and I'm just using vanilla html/css/js for

https://ameye.dev/

Haven't found the need yet for any frameworks.

i really like the design of your page, good job!

> Haven't found the need yet for any frameworks

This is a static page, CSS framework shine for dynamic page where style needs to change beaded on state.