4 ms·

I wouldn't go so far as to be bitter about it like you appear to be (based on past negative experience?) but yeah: the real question is why should one stick to

I wouldn't go so far as to be bitter about it like you appear to be (based on past negative experience?) but yeah: the real question is why should one stick to markup when you're developing an app anyway? Markup is for documents, and the "declarative" aspect of it is that it guarantees certain safety conditions (termination, injection safety, maintainability) without sending the author into a full Turing-complete programming environment and everything that goes with it, requiring experience, testing, choice over implementation alternatives, maintenance, debugging, and more laborious/expensive hosting with monitoring, etc. Markup is for ambitious tech-savvy end users/non-developers, and the high end of a non-Turing markup language operating purely at the level of syntactic manipulation, unlike htmx and TwinSpark, IMHO would be SGML, containing a finite state mechanism for context dependent styling or other processing and natural injection-free templating/macro expansion. Now the web has pushed the limits of what can conceivably be called "documents" eg blogs with threaded comments, table of contents and other navigational idioms, etc. For these kind of "content apps" (supported by SGML still), there has always been a struggle between full Turing complete environments and increasingly idiosyncratic markup techniques. That struggle is even more noticeable when looking at CSS. IMO, CSS has aggregated such an enormous complexity while most advanced use cases fall straight into "app" territory. That is, there is no justification for most recent CSS features when those features can only realistically be applied in the presence of JavaScript anyway, and thus should actually be implemented using JavaScript rather than bloating CSS. Case in point: the has() selector which doesn't materially enhance what you can do with HTML/CSS but clearly is introduced in support of components and modularity; ie requiring JS anyway, and with JS allowing much better modularity already anyway, is hence just redundant. Clearly, also calc() and custom properties are doubling what's already available.

ziftface 3y ago
I think my experiences are just very different from yours, but I found that declarative markup was the only sane way to represent visual UI elements. The classic example is using an imperative JS API like element.innerHTML = '...' vs React/Vue/etc, but the same could be said for newer UI APIs, like SwiftUI. I wouldn't call a mobile app's UI layout a document, but I still think the declarative nature of that API is a better fit than its imperative predecessor, UIKit. Both of those examples have an "escape hatch", where you can drop into an imperative API if you need to, so I can see the argument for them not being a perfect abstraction of the underlying primitives, but that doesn't mean they're not useful and a good fit for the problems they're solving.
xigoi 3y ago
The has() selector definitely enhances what you can do with CSS. You can style elements differently based on what they contain.
- nsonha 3y ago
  which is the wrong way to do it. The source of truth for a state, that determines the style, should be... well a state, most likely in memory. It should not be a visual representation of that state (what element is rendered in side). When you change the latter, your conditional css will become broken unknowingly.

ziftface 3y ago

I think my experiences are just very different from yours, but I found that declarative markup was the only sane way to represent visual UI elements. The classic example is using an imperative JS API like element.innerHTML = '...' vs React/Vue/etc, but the same could be said for newer UI APIs, like SwiftUI. I wouldn't call a mobile app's UI layout a document, but I still think the declarative nature of that API is a better fit than its imperative predecessor, UIKit. Both of those examples have an "escape hatch", where you can drop into an imperative API if you need to, so I can see the argument for them not being a perfect abstraction of the underlying primitives, but that doesn't mean they're not useful and a good fit for the problems they're solving.

xigoi 3y ago

The has() selector definitely enhances what you can do with CSS. You can style elements differently based on what they contain.

nsonha 3y ago
which is the wrong way to do it. The source of truth for a state, that determines the style, should be... well a state, most likely in memory. It should not be a visual representation of that state (what element is rendered in side). When you change the latter, your conditional css will become broken unknowingly.