Hacker News Reader

Comment by rendall | Hacker News Reader

> Let’s take an example.

> This is how you write a card component with Bootstrap:

  <div class="card"...>
  <img src="..." class="card-img-top" alt="...">
  <div class="card-body">
  <h5 class="card-title">Card title</h5>
  <p class="card-text">
   ...

> This is how you write a card component with Tailwind:

  <figure class="md:flex bg-slate-100 rounded-xl p-8 md:p-0 dark:bg-slate-800">
  <img class="w-24 h-24 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="..." ...>
  <div class="pt-6 md:p-8 text-center md:text-left space-y-4">
    ...

Let's be honest. All other considerations aside this does not make the case for Tailwind

View on HN

When I saw the Tailwind example, the first thing that came to mind was... "Wasn't CSS supposed to decouple presentation from content"? Because this sure looks like going back to <font> tags and style="" attributes everywhere.

"Separation of concerns" often results is code rot and harder to main codebases. Placing the styles, js and HTML for a "component" in close proximity helps to reduce this and can in my experience make development significantly quicker.

Separate css style sheets make sense for "document" web pages, but for "applications" I have found keeping the style close to, or inline with, the HTML much better.

Personally I prefer the concept of the "single file component" popularised by Vue. Having one file that contain the js, HTML and css in close proximity but not on top of each other works really well.

A common phrase used to describe this is "locality of behaviour".

yeah i've never been a fan of separating html, css, and javascript. it's a dogma that doesn't work well for frontend development.

That made sense for documents, and maybe even web apps before the rise of component-based web libraries that make it easier to collocate HTML, JS, and styles in reusable components.

It didn't make sense even for documents. A document usually cannot be cleanly factored into content independent from presentation - the border between the two is fuzzy, and there's always some bleed-through.

You could say, perfect is the enemy of good, with almost every document you could easily get 95% there. That's true - but that 5% made the whole idea into a leaky abstraction. The more strict you were about the separation of content and presentation, the harder it got to deal with the 5% that were both - and back then, people were dogmatic about this.

Many of us here probably remember the CSS Zen Garden[0] - the site that demonstrated just how far you can go with CSS if you keep the content and styling separate. I used to be in love with this, but now I think the site did incredible damage to web developers of that era: by getting people excited about flexibility of CSS, it made people forget that any particular site they're building is not going to have 20 alternate stylesheets to choose from - rather, it's going to have one, and the content on that site will be created with a specific presentation form in mind. Devs and designers ended up chasing half-formed visions of what could be, without realizing those visions made no sense in practice.

(This of course doesn't mean that doing HTML and CSS in JS is a better idea. It's also a bad fad, just for different reasons.)

[0] - https://en.wikipedia.org/wiki/CSS_Zen_Garden

But CSS has almost never been decoupled from content. Yeah, there is zen-garden, but no real world CSS would be applicable to a different website just as is. They depend on the exact html structure, what is inside what, etc.

If you add this to the fact that you would actually write a <Component> and only specifically style that “inline” once, then you are actually better off with tailwind.

Agreed.

Every generation repeats the mistakes of the past, and every time "this time it's different". This time it's different because components.

I'm still well-disposed towards Tailwind and it provides ways to handle this. I was just amused that the example was so bad.

I've been doing web dev since the 90's and my first reaction to Tailwind was the same. Basically, "are we doing <font> tags again? really?"

What the article (and many that are trying to introduce Tailwind) doesn't make clear is that Tailwind is purposely lower level than something like Bootstrap and it really exists to let developers make their own higher level framework.

In particular, the idea is that you use Tailwind's `@apply` to bundle your own components. So you would do:

  .card {
      @apply md:flex bg-slate-100 rounded-xl p-8 md:p-0 dark:bg-slate-800;
   }
  .card-img-top {
      @apply w-24 h-24 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto;
  }
  .card-text {
      @apply pt-6 md:p-8 text-center md:text-left space-y-4;
  }

Then your markup becomes

  <figure class="card">
  <img class="card-img-top" src="..." ...>
  <div class="card-text">
    ...

You basically can quickly build up your own replacement for Bootstrap out of components that fit well together, handle a lot of the messy implementation/compatibility details for you, and results in a bespoke framework with only exactly what you need and easy to change when you need to.

I think most of the articles and documentation that don't make it clear that Tailwind isn't a direct replacement for Bootstrap, but something that you use to build a better Bootstrap do it a real disservice.

Anyway, I think `@apply` should be one of the first things mentioned when introducing Tailwind. That made it click for me.

I wish it didn't require building/compiling with JS, but I guess we lost that battle way back with SASS/LESS.

Just using @apply isn't really the idea with Tailwind, and iirc one of the devs said they regret it. Tailwind exists in a world with component-based frameworks and advanced editor tooling. Some light repetition is thus toleratred, and it is expected that when more abstraction is needed it can be created using components. Thus you can abstract away non-CSS code too.

When it comes up '@apply' I don't really it as an improvement even over vanilla CSS.

Seems like tt that point you're basically learning an entirely new syntax just to save time on typing a few characters.

This bit annoyed me greatly. I'm not an expert on CSS and I've not done anything serious for years, but I have used used bootstrap, so I was curious to see why people thought tailwind is better.

But the two examples are completely different, and I dont understand why they would do that. Surely the the benefit of an example is to point out how hard it is to do the same thing in the old system compared to the other. not have two wildly different examples and say "look, the other one is shite"

> Surely the the benefit of an example is to point out how hard it is to do the same thing in the old system compared to the other

I think the idea here is "how is you accomplish the end goal in each, using their normal way of doing things". For example, if you were going to build a sorter in C vs Smalltalk, you would use procedural code for C and object oriented code for Smalltalk. Both would show how a sorter would be built in the style of the language in question (vs building an object oriented approach in C).

The article did a poor job of explaining this, but I think the assumption with utility-first CSS is you’re using some component framework. So instead of having to separate the HTML and CSS, and invent names for every child element of a component, you just use the utility classes in the component, and reuse the component rather than the (component level, not utility) classes.

> The article did a poor job of explaining this...

Yes, I agree, and that was more my point than any dig at Tailwind itself. Just because the article argues badly does not mean the argument itself is bad.

I'm also not a fan, but for bootstrap you have to understand how those semantic class names turn into CSS and presentation, whereas the bottom is directly telling you what it does. It also gives you a lot more flexibility out of the box.

Tailwind accepts greatly reduced DRY for straightforwardness. It's kind of like inline styles with training wheels.

I'd much rather do this type of thing in the CSS layer, but doing it inline has advantages. Mainly, I think the reason it's caught on is new junior devs get productive in it very quickly.

Bootstrap templates contain examples and simple utility classes though.

They prepackage bundled JS for interactivity, skipping over any build process.

There are also way more websites running bootstrap that need maintenance or enhancements.

These seem like a better fit for junior programmers.

I think tailwind has caught jr programmers because course sellers have had an easier time getting market share because there isn’t remotely as much (free) content, examples and docs about tailwind.

I think the influence of people with a vested interest in selling courses (like the hosts of Syntax web dev podcast) is what gets people to choose newer frameworks, not practicality or employability.

That was my exact same feeling after reading the example…

I was sceptical about tailwind for a long time for precisely this reason, it does looks verbose, and that was until I used it. The tagline "design without leaving html" is true and where all the productivity comes from.

I just watched a talk On why simplicity matters by Rich Hickey from Rails conf 2012, and I think this discussion is a good example of easy vs simple. Tailwind feels easy because it’s proximate, flexible, quick etc. but it makes the markup disgusting looking and, although I haven’t used it, I feel like it could easily lead to an inconsistent global design as each component can have their own styles that are isolated from the cascading/inheritance effects.

It doesn’t feel simple to me… there is just something about all these inline styles (that’s exactly what these utility classes become) that really turns me off.

Cool I've watched the same talk, did you use tailwind? No, well you can define your own css classes that combine multiple tailwind classes but using the same postcss syntax. Bootstrap philosophy is, writing css is too hard so we did it for you. With tailwind css is no longer hard and it lets you focus on designing, instead of changing the main color or your bootstrap theme.

You ain’t writing HTML like “here is a 10000 line file, let’s style it”. You almost always have some repeating components (which is a shame that it wasn’t really a well-defined thing for so long in web circles, this is like the most basic abstraction of frameworks from the 80s), and you make that HTML file from multiple of those. These inline styles are just the implementation of your <Button> — changing that will change every button of yours.

Hickey’s talk is a very very great talk, but I fail to see its relevance here. All tailwind does is give names to often used css attributes and allows one to apply them very specifically. It has no strange abstractions going on, it is basically “developer WYSIWYG” for CSS styling

In Vue SFC, my scoped CSS is a few lines below the HTML. And my HTML doesn’t look terrible like this.

Fair enough, I never tried it. It’s just for someone who might be inclined to give it try (like myself), the example in TFA makes a really bad case.

Now change the padding on card-body.

All of a sudden tailwind makes more sense.

Now maintain an app with 3 front end devs.

With Tailwind there’s no consistency across developers. It’s all highly configurable, but no convention.

Have maintained one with 10 FE devs - Tailwind is a godsend.

You should have a design with a catalogue of components to build off of so you don’t have 30 card components.

It’s a your-team issue, not a Tailwind issue.

That's when you make components

Dev 1 might make a card component with grey text as #999 and Dev 2 might make a footer component with grey text as #888.

Components are locally consistent but not globally consistent.

Or, let’s say you want to change all your grey text to #777, then you have to go back through all your individual components and hope you didn’t miss anything.

No buddy, text-gray-600 is globally consistent.

So are your own custom defined colors like text-armatav-500.

Use the thing before you dismiss it.

You ain’t hardcoding colors inline, you refer to them via “variables” basically, so this situation doesn’t exist: https://tailwindcss.com/docs/customizing-colors

That’s a single variable or rule if you want to change it site-wide.

If you want an unsemantic one-off, you can do it just like Tailwind by setting a utility class like “p2”.

Isn’t that a single SCSS variable in Bootstrap?

SCSS cannot be of use to the 98% of all bootstrap sites that just use the CDN to deliver a compiled stylesheet. The point here is can just change it in the HTML.

Tailwind cannot be of use to those same sites either, because the compiler needs to process your HTML to cut the generated CSS down to size. You have merely traded one tool for another. If you actually want to change things without preprocessing, your option remains good old HTML and CSS.

Amazing, the lengths that devs go to not to learn CSS fundamentals.

It’s almost like CSS just fails at its job (though to cut it some slack, it was never designed for “apps”)

Tailwind looks like it goes back to the days when people use in-line styles.

I mean, it would be a lot more useful if people used the Tailwind classes as primitives to compose site-specific components, which can be further changed locally.

> Tailwind classes

Not classes, but components as primitives. You just go to the component’s definition and can see its style at a single place, right next to its structure without which CSS makes no sense.

That's what people do? Or at least that's what I'm doing in my pet project to learn React and typescript.

Reply on news.ycombinator.com