Hacker News Reader

Here's a thought: HTML does not separate structure, or content, from presentation. I'm not sure where the myth of the web's separation of concerns first arose - possibly from some architecture astronaut who'd never written an element in their life, perhaps from someone who really knew better but needed to slip something past the mediocrity police - but irrespective of what any non-normative reference may say, HTML does in practice blend structure, semantics, content, and presentation. CSS and JS substantially augment the presentation and semantics, but fighting against the grain of what HTML fundamentally embodies, instead of leaning on the framework, is a prime recipe for technical debt, not to mention opening the door for an awful lot of NIH.

Tailwind responds to that with an organising principle of styles refactored at the abstraction level of page components. It is not supplying an off-the-shelf design system for front-end novices a la bootstrap/material design. That is an excellent fit for a template-driven world, which is to say, most applications of scale. It is also an excellent fit for anyone (or any HTML generation language) that thinks of data as functional and anonymous. Naming things is hard, so the fewer things we're forced to name the better. My CSS has even improved from using Tailwind, not just thanks to the excellent docs but because it's been easy to experiment with alternative compositions.

To your specific inquiry - I've been maintaining several Tailwind frontends for a few years now, and it's been more reusable, more composable, and more maintainable that any of the hand-crafted CSS I might've written in the past, no matter how polished and proud I was of it.

I'm not sure where the myth of the web's separation of concerns first arose - possibly from some architecture astronaut who'd never written an element in their life, perhaps from someone who really knew better but needed to slip something past the mediocrity police

I'm pretty sure it came from CSS Zen Garden (http://www.csszengarden.com). The same HTML with dozens of different presentations all done exclusively with CSS changes. Don't get me wrong, I agree with you that for the most part the separation is a myth, but I personally remember before seeing CSS Zen Garden, the idea wasn't as common.

It's hard to argue against the power of separating content from presentation when we can see the results with our own eyes in a couple clicks on Zen Garden. I have a hard time seeing how the disparaging title of "architecture astronaut" is warranted by it.

That power is only for the contrived example of doing a complete redesign that doesn’t change any of the html content. It’s like one of those demos people make of a CSS-only thingamajig that would be much easier to do any other technology. It makes for an interesting tech demo but isn’t practical for day-to-day development.

Templates, themeable products like WordPress, dark modes and alt accessibility presentations...

>That power is only for the contrived example of doing a complete redesign that doesn’t change any of the html content.

Didn't Github just re-style their whole UI? Presuming that's an extreme possibility seems like premature optimization unless you run Product.

That’s more like YAGNI.

The other comment made a good point about WP templates, I can only speak to my own experience. I have mostly worked on projects where I could edit the HTML, and in those cases using a Tailwind-like methodology was dramatically easier. Even when doing a full-site redesign.

So if you are designing for a project where you are unable to edit HTML, sure, use the right tools for the right. Or if the bulk of your coding time is spent doing full site redesigns instead of updates to an existing design, then it wouldn’t be the right approach. I wouldn’t use it on a project intended to be white-labelled, otherwise that’s the methodology I’d use.

HTML and CSS has overlapping control over many properties on how a given document is rendered, so Zen Garden is more like “check out this Turing complete program written in CSS” — cute and interesting, but it is not practical as we can see from.. literally no real website doing anything remotely like that. This myth came from a time when we had markdown-level HTML markups, and it made sense back then: sure, why not let me color headers red? But it doesn’t scale as it simply doesn’t compose. That cascading part doesn’t make sense for many properties: should padding be inherited? It basically never makes sense. Components are the sane building blocks (as has been realized by desktop GUIs decades ago), and we are much better off with strong encapsulation here (shadow dom is a welcome change).

I think the idea comes directly from timbl himself. Maybe he even got it from one of it the webs predecessors, like project Xanadu maybe. Certainly older than CSS Zen Garden (which is a brilliant project) and even older than CSS (which was the one of at least two style sheet languages that won).

The original idea was that the server provides the content and the consumer (browser) is responsible for presentation. In this thinking the separation of content and presentation makes total sense and the delineation is just a matter of practicality.

If the same party provides content and the presentation I find the distinction much harder to justify. Especially since there is no hard boundary (server pure content, consumer pure style) people will draw the line where it is convenient for them. What you inevitably will end up with is crossovers like in Tailwind.

That would make sense only in an alternative universe where HTML itself didn’t end up with styling-related functionality, but remained closer to its XML ancestry.

HTML was spawned from SGML and HTML predates XML. The only XML ancestry was later on when a couple of versions of HTML were rewritten to be based on XML (XHTML which was eventually abandoned), but even then it needed a lot of backwards compatible escape hatches, and was only valid XML with strict modes etc.

‘architect astronaut’ is a great phrase.

If HTML were specifically about structure instead of presentation, stuff like line-height or text-transform (which carry an obvious semantic value) would've been tags rather than CSS properties.

HTML+CSS(+SVG+JS+Web Workers+etc...) is not a formally correct framework, and personally I can appreciate what Tailwind can achieve even if strays a bit further from an ideal approach.

My take on this is that meaningful class names are massively helpful for maintainability and any kind of development lifecycle.

What is the name of the sub-widget you are currently building? Say you're building a card - if there is a row that has various icons for the features of the thing depicted in the card, alongside a subtitle, what is that row? It's not just an icon row, because of that subtitle. Should it be its own component? Or will you just give it a reasonable name, keep it defined inline in the larger card's component, but make it clear that you see it as a definable sub-layer? A class name is easier and less disruptive to type than creating an entire new React file for a subcomponent.

What about code review and QA? Must the reviewer read a dense string of Tailwind class names just to try to intuit what is going on? And then, when someone doing QA says "we need to add some padding on the..." - can they go into dev tools and see a reasonable name for that subcomponent? Or would they need to refer to it as the thing around the X and Y and Z, because that's the only way they have to describe the thing?

Not to mention userscripts and extensibility. For the same reasons that one might open-source parts of their stack, and for the same reason that app stores drive stickiness, allowing your users to hack on the visualization of your product can be highly synergistic. Using opaque class names takes this power away.

We've all seen Figma files with unnamed Group 142 nested in Group 134 nested in... if they are grouped at all, that is! A tradeoff was made for design speed vs. maintainability/future component extraction. Often that's the right choice at the design stage. But if you work in a realm of text editors and textual code reviews, that may not be the right choice for you.

Tailwind makes a lot more sense when used in conjunction with a component library.

Unfortunately like “jQuery developers” a decade ago, we now have “react developers” that don’t understand CSS and add more divs until they get the result they want.

A modal log in screen is five elements: a shade, a dialog, two labels, two inputs and a button. These are all very easy to name.

Not 300 unnamed divs. The react developer adds divs and then considers it difficult to name them all.

> A modal log in screen is five elements: a shade, a dialog, two labels, two inputs and a button. These are all very easy to name.

Agreed. But why name them at all if the structure is so simple? Keep your simple, understandable structure, colocate your styles with tailwind classes, and avoid the unnecessary cognitive overhead of naming obvious things (is it .username or .user-name?) and linking them with remote styles in a different file.

Not saying it’s the “one true way”, but I don’t think your way is necessarily simpler.

Unnamed would be great if it was just inline styles. Just not 34 class names per element in a custom DSL plus other rules to get around DSL limitations, plus additional wrapper divs because the developer does not know CSS, which is my experience of tailwind projects (including one from YC).

With all due respect, I think many of us has been massively burnt by that “meaningful classname”, that happened to be also a meaningful classname in a different part of the code, or was not specific enough, or an update to a CSS dependency broke the whole thing.

I have used it for three years at this point. I would feel very disabled if not allowed to use it on the next project.

You say that you want to write "meaningful class names", which is something that clicked for me: naming things is hard[1]!

I remember having the feeling that every time I used inline styles, I was cheating in both senses of the word: doing something not allowed and getting away with something too easily. I get that second feeling when using Tailwind.

[1] https://medium.com/p/9eab459633d2

How is naming things hard?

I am looking at a comment, it contains two voting buttons, and some text.

The elements should be : .comment, button.upvote, button.downvote, .text

If you have more elements than that you’re either doing something extraordinary or you need to learn CSS better.

Now do a card-widget. HTML is too barebones to operate without random helper divs, and those can’t be meaningfully named.

I do card widgets all the time without wrapper hacks. So do most competent from end developers. Challenge me on any design you want.

> naming things is hard

This is an argument that would have held more weight for me before I started using BEM. Naming your CSS should be exactly as hard as naming your component, and no harder.

Is your React/Vue/Svette component named "GenericButton"? Congrats, that's your class name. Got some markup under it that you need to style and you're worried about name intersections? Don't be; "GenericButton__whatever". You never need to worry about collisions again, they just don't happen. And you never need to worry about naming, you just use the same names that you're using in your Javascript/Typescript.

----

To me, I look at Tailwind, and it feels like taking a bunch of React components and saying "no, don't separate those out into hooks and helpers, inline all of it." People say that Tailwind is about locality of style, but I just don't see it. Locality of style, component-based CSS -- you do that by using components and by scoping your CSS to those components. You can do that with normal CSS. Heck, there are even libraries that will get rid of the cascade if it becomes a problem.

I'm told that the reason Tailwind often ends up looking like spaghetti code is because you're supposed to be using more helpers with it and that you can make it reusable. Sure, I buy that. I buy that it can be made reusable and composable. But say that you make it reusable and composable -- part of that process is going to be naming things. It's going to be deciding what to name your helpers and your shared styles you want to use everywhere.

So I don't know, maybe there's something I'm missing. I agreed with a lot of the criticisms of "semantic" CSS and I might have been really receptive to Tailwind at some point (I do think using element names in CSS is usually bad practice), but then BEM happened and I realized, "hey, you can just name CSS after the component you have it attached to, and then suddenly all of these problems go away and it becomes way easier to debug because you always know exactly what to search for in the codebase and where to look to adjust every class."

And yeah it's more verbose and the double underscores look a little ugly, but come on, we're comparing it to Tailwind. Having your markup look a little bit ugly obviously isn't a dealbreaker.

I'm trying not to be dismissive of Tailwind in part because a lot of people use it and like it, and I felt dismissive about BEM as well before I started using it. So I keep on using Tailwind when I run into it, I keep on waiting for it to click. It hasn't yet. Maybe I'm just not seeing it or not using it right but I'm never tempted to use it when I don't have to.

----

Edit: I will add to this, you want to talk about coupling CSS to Javascript then one of the cool things about BEM styling is that your generated output documents your Javascript/Typescript.

When I look at an app that's using BEM, and I see part the HTML that I want to change, even if I've never looked at the codebase before in my life I know exactly what to grep to get to the HTML and exactly what file I need to change. If somebody wants something added to a footer, I know what filename to search for to get that footer, I know the full list of every component that's inside that footer just by looking at the HTML. I know how the Javascript code is organized just from the HTML. And that makes it so much easier to just think about individual components without having to worry about understanding an entire application.

In comparison, every time I look at an app with Tailwind, I'm struck by how utterly useless the generated HTML is for doing any kind of debugging -- both debugging style and debugging the HTML/Javascript.

Because it turns out that having every component name in code mirrored to your class list and tied to your styles makes it really easy to cross-reference everything.

There is XSL-FO, less famous cousin of CSS, that formats documents for printing. It has no formatting classes; each element has to have the appropriate attributes. To make it manageable there are, of course, default values and inheritance, so you can set the main font once on the root element and then only use 'font' when you need another. And since these are XML documents and are mostly created via XSL, they can also use an alternative generic mechanism of setting attributes: XSL attribute sets.

I’ve worked with XSL-FO (not as much as I would like to), and I would say that this is a pretty viable approach. First I tried to turn attribute sets into formatting classes (it is totally possible, plus these classes can also form a hierarchy with clear priority rules). This mapped very well to what I knew about CSS and to my experience in desktop publishing. But over time I became perfectly content with just setting attributes on an element directly and only resort to attribute sets when they came naturally as a time-saving technique.

In old times people who wrote about UI emphasised “direct control”: users must feel they are in control of things that are happening on the computer, that they not just convince the computer to do something but can, for example, directly move a file from one place to another. This is an illusion, of course, but the one that gives the interface a very empowering quality. (Which becames more and more scarce nowadays.) As far as I understand Tailwind it gives the same feeling of direct control.

Thank you, this was a good read and positively exhaustive.

Especially the comparison with XSL-FO regarding the cascade: I never felt that tailwind abandoned the C in CSS entirely, it just encourages to limit its usage to a sane and transparent approach (as opposed to specificity wars)

Same here. Have tried a few before moving my portfolio to Sveltekit last year, including Tailwind. And to be honest it does feel Bootstrappy as you said. The simplicity and flexibility you have in some of the functionality of CSS to really do whatever in terms of layouts is fantastic.

The only thing I know for sure, as it's a current problem with the front-end development at work, is that majority of devs are not that experts in CSS and they have hardly spent any time working on raw CSS in their whole career. Which is where I can see the appeal of using Tailwind. Maybe.

I think the appeal of Tailwind is in having the defaults preset (especially if you customise them to your own design needs).

Padding numbers, font sizes, colours available, etc. You're not just randomly picking a px number in a style declaration, or trying to come up with a random variation of red. A new developer can come in and use the standard tailwind classes and they'll be productive right off the bat, regardless of your product's decisions around sizes/colours/etc.

And it scales in a way that Bootstrap doesn't, because Bootstrap imposes a design. Unless you customise the living daylights out of it, it's going to look like Bootstrap. With Tailwind, you're building from scratch, and you can make it look like whatever you want, you don't lose any of the flexibility of CSS.

I, too, had to try it before it clicked; I thought it looked ugly as all hell, tons of random classes sprinkled in. Went against all that we've all been taught in the past (remember when we all worried about semantic class names?).

But it really is useful.

>having the defaults preset

This was very much the appeal to me - it eliminated a ton of different little decisions I would have otherwise had to think hard about, and let me just get into the actual fun part of style.

I also like that most Tailwind classes are named very similarly to the CSS directives that they apply, which meant (for me at least) that learning Tailwind has had a direct impact on my ability to write decent vanilla CSS.

I used it to style my personal site / blog (epiccoleman.com) and was really happy with the results. Previous attempts at rolling my own design did not come out looking nearly as good, so there's definitely something to it.

Man I am right there with you. It just feels like it’s giving up too much. It’s more enjoyable to write the CSS yourself.