[spankalee]

> HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces.

I disagree a lot on HTML here - it's a pretty fantastic way of describing a render and layout tree, so much so that people are embedding HTML-like syntax in programming languages because the syntax is better than what the language already has to offer.

To paraphrase something I've heard: JSX proves that HTML actually won.

And you can see this because even in a language with concise object literals like JS, a markup based syntax is nicer. There are template systems where you write objects, and I find them cumbersome and they're not very popular.

But markup is king, whether it's in JS like JSX or Lit-like tagged template literals, or in an HTML-like file like Angular, Vue, or Svelte. They all share a markup-based syntax.

> If HTML is so magical why do they need a fancy template language?

Note that Rich doesn't say that HTML is magical. He says it's good, which it undeniably is. It describes elements with attributes and children, which happens to be exactly the structure you need for the vast majority of UI widget concepts.

The reason you need a fancier template syntax is that while HTML is good it isn't perfect. HTML doesn't have a dynamic binding syntax (though standards is working on that with Template Instantiation) or conditionals, and attributes are underpowered.

So template systems generally add those things. Whether it's JSX, Svelte, lit-html, Angular, etc... they share those common enhancements.

The only real big disagreement is whether you embed the logic in HTML or the HTML in JS. It's not even that fundamental of a difference.

I prefer HTML-in-JS myself (note: I'm on the Lit team) because JS already has binding syntax, expressions, control flow; because the data is already available in JS; and because JS has a module system and you can do all the things without forking a language or a build step.

But having been on the Polymer side too, which is logic-in-HTML, I know that a lot of people prefer HTML syntax and that to some it's more clear how it maps to the DOM created on the page, simply due to syntax similarity. That's fine. But it's really all variants of HTML in the end.

[spankalee]

Also, these differences in syntax and opinion are why I vehemently support and work on web components. You shouldn't have to have two incompatible silos of UI building just because of some frankly minor differences in preferences.

Component authors and component users should be able to seamlessly interoperate which disagreeing about such trivial things.

[mixmastamyk]

Have a blogpost handy? Sounds interesting but I don’t know much about it.

[codeflo]

> JSX proves that HTML actually won.

While I think that might be true, similarly, JSX proves that for the dynamic parts of the template, you want a real programming language.

[scotty79]

I'd say that it's better to use real programming language, but you shouldn't use it in JSX beyond the simplest statements like ifs and loops.

Mixing any logic beyond that with HTML makes a mess of both.

I'm personally a fan of minimalist templating engines that provide only simple loops and conditionals so that template has to receive prepared data tree which is created by the actual programming language first and passed into the template.

[mixmastamyk]

Sounds like Django, which I’ve found maintainable.

[wruza]

To paraphrase something I've heard: JSX proves that HTML actually won.

And you can see this because even in a language with concise object literals like JS, a markup based syntax is nicer. There are template systems where you write objects, and I find them cumbersome and they're not very popular.

That’s completely an opinion, and I have another one. Html sucks at reading and writing, it is cumbersome (and also non-typed, and non-structured), and js structs/calls are much better for creating these trees.

Jsx proves nothing but that react team had to make a decision about format and they decided to not experiment with formats due to drop-in compatibility. That’s it.

[lenkite]

I personally agree - mileage definitely varies with people. Prefer markup languages over code for describing user-interfaces any day. Find myself quite comfortable with XAML and struggle with SwiftUI.

[mixmastamyk]

It depends on the markup format, language, and libraries of course. However in general I prefer code. Why? While it takes a bit longer to get started, you can factor patterns into reusable methods and before you know it are working at a higher level:

    make_fancy_dialog(msg);

Html only recently got templates but I don’t believe they are that powerful.

[Hugsun]

I suspect that the dominance of HTML is largely due to it being the only browser native markup language. Crucially, the browsers' dev tools always show HTML and having an obvious mapping from there to your code is hard to beat.

I personally dislike HTML due to the verbosity. I prefer hyperscript.

[PaulDavisThe1st]

> I disagree a lot on HTML here - it's a pretty fantastic way of describing a render and layout tree,

In the context of the discussion, that would imply that "a render and layout tree" is a good way to describe a UI. That too is subject to serious questions.

[spankalee]

Yes, I would claim that. What major, non-game, UI stacks out there aren't structured that way?

[PaulDavisThe1st]

Well, the constraint layout system that Apple introduced (sorry, I am drawing a blank on the name) is sufficiently different that I'd say that although technically you could call it a layout tree, that is really missing the point.

Also, the render tree concept doesn't exist in the internals of GTK (at least; I could speculate about Qt but will not). Rendering is done by invalidating rectangles and then finding intersections with widgets; since there is no z-axis stacking, there's only ever 1 widget to be drawn at a given pixel coordinate.