| Apologies for reading more into your article than it was trying to say. You're probably right that we're talking past each other a little bit. That being said: > I'm saying the interface of a website and the documents it contains are muddled. There is some truth to this, but it's overstated. I don't believe that the distinction between a website and a document is particularly clear on a conceptual level. Those things are muddled on the web because they are actually muddled in real life, there isn't a clear distinction between a document and an application -- and often it makes sense to treat them as the same thing. > I said that interface-html and interface-css are tightly coupled. This is already true. They already almost always evolve together. It is already exceedingly rare to see a web site/app fully redesign without changing html. I don't think this is particularly strong evidence either. Redesigns are large. I'd say an above-average number of site redesigns that I see involve changing the database layer too, that doesn't mean I'd encourage everyone to stop separating their database from their application logic. A bigger thing here though is that this feels opposite to me to how I think about HTML. HTML in your app should be more likely to change than your CSS, not the other way around. HTML is your user interface. When you do a site redesign, you change what data you present to the user and how you present it. That's HTML. To me, this is like saying that splitting font display from UTF-8 characters is wrong because most of the time you revise a book it involves changing the characters, not just the font. Incidentally if you redesign a website you will also often change the style, but... the style is secondary. I love the CSS garden stuff, I love how it got people thinking about separation of concerns, but it also encouraged people to think of HTML as if it's this extremely static interface that we apply a manifold of styles to, and that's usually incorrect. So sure, of course HTML and CSS often change in parallel, but... so? ---- > I am saying component-oriented approaches are ~recognizing and trying to rectify this mismatch (and people using Tailwind are reacting to a real deficiency in the core technologies). This is another thing where I feel like there must be something I'm missing because if you said this in isolation without mentioning Tailwind, I think I'd agree with it. I do agree that using semantic tags in CSS is bad for maintainability. I do agree that CSS has downsides, and I do think it should almost always be used in a component-oriented fashion. But I've used Tailwind for a little while now (maybe not heavily enough, I don't know?) -- I don't think Tailwind is very component-oriented. It's component-oriented in the strictest sense that you put styles on a component. But it doesn't encourage building logical units of style, it doesn't encourage reuse, it doesn't encourage structuring of style, it makes it harder to look at the output and understand where a style is coming from or what part of the code set it. You can have that stuff with Tailwind, but Tailwind doesn't seem to be helping with it, and most of the time that I see Tailwind it makes it harder to reason about the style of the app in a structured way. Most of the time I see Tailwind it's just attached directly to HTML like an inline style. And if I came to you and said I was going to stop using functions and just inline all of my code, you wouldn't characterize that as "component-based programming". Honestly, if we're talking about component-based interfaces, Tailwind-based interfaces feel a lot more like early JQuery interfaces than they feel like React or Vue. Forget separation of style and layout, I don't think Tailwind encourages the use of components at all. At least to me -- again, I know a bunch of people love it, I keep thinking there must be something I'm missing. But in practice, every Tailwind app I hack on makes it harder for me to couple CSS to a JS component. |
<3 (Nothing wrong with reading in, but thanks nonetheless.)
> You're probably right that we're talking past each other ... I don't believe that the distinction between a website and a document is particularly clear on a conceptual level. Those things are muddled on the web because they are actually muddled in real life, there isn't a clear distinction between a document and an application -- and often it makes sense to treat them as the same thing.
Part of the trouble here is that document is an overloaded term (there's a reason why the linked post has a full section on what is and isn't the document). You may be disagreeing with where I'm choosing to draw the lines here, and that's... okay. I suspect this is mostly coming down to perspective.
Categorizing isn't my natural mode. The world is a mess of gray, and a single language closing over both interfaces and documents is necessarily so.
(At the risk of projecting...) I get the sense you're seeing this from something like the context of what I called the "html-concrete document". From that perspective it's mostly unclear what bits are an interface and what bits are documents (and whether there's one document or N of them, etc.). They're all already muddled in the concrete document. (If you step up to considering several html-concrete documents on the same site, I guess you could use template induction to work towards understanding.)
The perspective I'm coming at this from is concerned with how we can author marked-up documents to maximize reusability. This perspective is concerned with, as the post said, "the one closest to the document in the eyes of the author" which I called "an abstract-document". I think this is conceptually clear (but it may not be clear to anyone but the author).
> So sure, of course HTML and CSS often change in parallel, but... so?
I didn't say it was a problem that they change in parallel--just that this change is a sign that the interface-html and interface-css are already tightly coupled. I'm not arguing for more or less coupling between them, but pointing out that a fraction of the global html/css/js namespaces are comprised of tightly-coupled code structure/style/behavior that comprise "the interface" (as the interface designer sees it) almost certainly co-mingled with structure/style/behavior for stuff that isn't the interface (where they can all unintentionally clash).
> This is another thing where I feel like there must be something I'm missing because if you said this in isolation without mentioning Tailwind, I think I'd agree with it.
These are separate ideas (hence the aside). I'm not arguing that Tailwind is component oriented. The component folks, and the Tailwind folks, and the BEM folks (and many more folks trying different things!) are all reacting to problems caused by the status quo separation of concerns. The component folks are more directly trying to rectify the mismatch, but they're all still patching around deficiencies in the stack.
> I've used Tailwind for a little while now (maybe not heavily enough, I don't know?) -- I don't think Tailwind is very component-oriented. It's component-oriented in the strictest sense that you put styles on a component. But it doesn't encourage building logical units of style, it doesn't encourage reuse, it doesn't encourage structuring of style, it makes it harder to look at the output and understand where a style is coming from or what part of the code set it.
I could probably clarify that I find the Tailwind style a bit revolting, and set about writing the linked piece in part to dunk on it (among others). In the process of pulling things apart to understand them, though, I felt like I could see the problems it's reacting against. It's a ~reasonable way to make lemonade, even if I don't like it.
> Most of the time I see Tailwind it's just attached directly to HTML like an inline style.
This is both a thing I personally find revolting about Tailwind, and a big part of the value/leverage I think Tailwind users are reaching for.
> And if I came to you and said I was going to stop using functions and just inline all of my code, you wouldn't characterize that as "component-based programming".
Maybe reframing this function/inline analogy a bit will help clarify?
If you showed me a 2000-line function, I'd ask the obvious question about why you didn't abstract it out into multiple units with meaningful names.
But if you responded by explaining that this code was destined for a global namespace where there was a real risk of code written by others also defining/overwriting/wrapping the identifiers you chose, we'd end up having a similar conversation about the ways around. You could hand-namespace all of the identifiers and make human reviewers keep up. You could introduce tooling to namespace identifiers to avoid clashes. You could try to engineer in stronger component boundaries. You could indeed choose to inline as much as possible.
I would say I'm not a huge fan of the inlining approach because it's a mess to read, but if you countered that you were extremely confident that the code was stuffed with implementation quirks so tightly coupled to something in the stack that it would almost certainly not be reusable elsewhere and would almost certainly be faster to rewrite from scratch than understand and refactor... I wouldn't call you crazy.