[rvense]

I also grew up in the CSS Zen Garden era, and I've become a big Tailwind proponent.

To me what is cringe-worthy is hanging on to ideas about what this medium is that just no longer apply. For better or worse, the web stack has been appropriated into an application framework. I am not making documents that have styles applied to them. It's just not a metaphor that works anymore.

The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way. Maybe for some parts of your app, you can maintain this separation of you try, but it's not something that adds any value at all. Even if it could work, there would be absolutely no reason to try. The type of redesigns I do on this type of code affects HTML, Javascript and CSS equally, always.

Tailwind, to me, solves a bunch of very real ergonomic issues when working with large web applications, and results in far clearer code.

[Benjammer]

>The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way

This is orthogonal to the issue. It's still possible to separate the functional layers of a website or application, even if the entire stack is JS or whatever.

I don't see how single page apps invalidate the base concept of separating data, structure, and styling into separate layers, regardless of the format or code language of those layers.

[dasil003]

SPAs don't invalidate the concept of separating structure and styling, but as with all technical architecture decisions there are tradeoffs. Whenever you add another layer you are paying some base overhead cost with the goal that each individual layer ends up simpler. Whether or not this is a net win depends largely on the interface between the layers (see also: microservice trainwrecks). Content and style is tightly coupled and application-dependent, so abstract principles that sound good may make zero sense in a particular use case depending on a whole slew of technical and operational concerns about how the markup and CSS are generated and served.

In the old days, website were primarily documents, and as browser formatting grew more sophisticated the ratio of content to styling markup grew lower and lower, and when you're formatting simple documents the amount of redundant styling is very very high. Because HTML was designed with a small number of elements that provide pretty good coverage over basic documents, and because most documents were created by hand, the original CSS design and philosophy behind CSS Zen Garden was an absolute slam dunk for content creators of the era. The assumption is a small amount of CSS covers styling for a huge library of markup documents, minimizing overall code size.

As web apps evolved to be more dynamic, first with bits of AJAX and then graduating into full SPA with more and more functionality ported to client-side APIs, we found the semantics of HTML which were tied to more universal concepts of written documents (heading, paragraph, list, quote, etc) did not cover the semantic needs of describing UI widgets. At this point CSS is still useful but the optimal structure is not as obvious. Essentially there are two extreme approaches: 1) create very specific markup for each UI element, which optimizes markup size and clarity, but leads to a huge amount of duplication of CSS; or 2) create UI-oriented classes that are then tacked onto a dense tree of nested divs, which optimizes CSS size and clarity, but leads to markup bloat and "class-itis".

This fundamental problem was attacked from many different angles, lots of code generation, web components, OOCSS, BEM, Sass, etc. I consider Nicole Sullivan's work in this area to be seminal, leading to the optimal approaches large web products use at scale, and directly informing the design of React and modern SPA approaches. The reason Webpack processes markup, css and javascript all together is because things are so tightly coupled in practice, that you need tooling to optimize overall code structure and legibility. Purist approaches don't work very well for large projects because HTML & CSS were not designed to build GUIs.

[Benjammer]

>Essentially there are two extreme approaches: 1) create very specific markup for each UI element, which optimizes markup size and clarity, but leads to a huge amount of duplication of CSS; or 2) create UI-oriented classes that are then tacked onto a dense tree of nested divs, which optimizes CSS size and clarity, but leads to markup bloat and "class-itis".

Really, only two approaches are viable? There's no middle ground here? What would be the point of highlighting the extremes?

It's as if the entire tech industry has lost the ability to tell a designer to sit down and come up with a basic typography set and color palette even. Obviously you can't just create the entire style sheet set in one pass, but can't there be an iterative approach rather than throwing the entire thing out and building giant systems just to let picky designers pointlessly tweak small pieces of the application, in isolation?

What does a complex, "dynamic" widget have to do with not using standardized typography and colors in your application? Once you start there, can't you just evolve the styles to meet product needs? It just seems to me that 99% of the time, the point where it's decided that this whole thing should be thrown out, is almost always the point where someone wants to put "built a component system" on their resume...

Another grey area:

>create very specific markup for each UI element

vs.

>create UI-oriented classes

There's another middle ground here where you just have really big CSS selectors, and many things share styles, while still pointing to structure-oriented html classes. Can you achieve a middle ground better than individual styling, without resorting to UI-classes?

[dasil003]

That's exactly my point, the two extreme approaches are on a continuum, and the interface between the two is very tightly coupled, leading to the optimal approach for a typical SPA being very different from the approach being touted in the Zen Garden era.

[z3t4]

Can you give an example where CSS is duplicated?

div's should be avoided. Use semantic elements instead! If you absolutely need them you should consider making a custom element instead. (with it's own base CSS).

[rvense]

> I don't see how single page apps invalidate the base concept of separating data, structure, and styling into separate layers, regardless of the format or code language of those layers.

It does not. But using utility-first frameworks like Tailwind doesn't mean you're not separating things. It just means you're not separating things in CSS files. You have the Tailwind setup (which allows you to customize colours, spacings, etc.) and the functionality of whatever component framework you're using. The point is that in the context of SPAs, "styling" (visual presentation) is not limited to CSS.

[rglullis]

This seems backwards. Desktop/GUI application developers have separate layout/theming engines and you don't see them asking for theming frameworks to be intertwined with components properties.

[lallysingh]

> The HTML, Javascript and CSS in a single-page application are not separable in any meaningful way. Maybe for some parts of your app, you can maintain this separation of you try, but it's not something that adds any value at all. Even if it could work, there would be absolutely no reason to try. The type of redesigns I do on this type of code affects HTML, Javascript and CSS equally, always.

I've heard different forms of this argument for decades in dozens of systems. Same old "why pay for abstraction" argument. I'm not going to answer. Either you figure out the answer or you don't.

[rvense]

I'm not saying you shouldn't make abstractions. I'm saying that Tailwind (in the context of a SPA framework) makes for better abstractions than traditional CSS.

[Wowfunhappy]

> I am not making documents that have styles applied to them. It's just not a metaphor that works anymore.

And xml-based markup was just never a good format for that. The concept lives on in markdown, and in CMSs like WordPress, where an author creates content in a common format that is styled based on site- and page-specific rules

No one wants to write in html. If you’re working in html directly, it’s probably because you’re building something more complicated.

(If any of those assumptions are wrong, tell me! I’d love to hear a counterargument on why pure html is a great format for producing content!)

[moron4hire]

Maybe for 80% of people, it doesn't matter that your HTML isn't semantic, but for the 20% of other people who have need for accessibility features, that's basically the same size as the entire market of web browsers not named "Google Chrome".

[allover]

You are conflating unrelated things.

Using a framework like tailwind does _not_ affect whether your actual HTML elements are semantic, which is what would affect accessibility.