No, HTML and CSS are document markup languages. They are actually quite bad at UIs.

For example, implement a table with more than a few hundred rows. UI toolkits don't even blink while HTML just falls over.

>No, HTML and CSS are document markup languages. They are actually quite bad at UIs.

This was true 10 years ago. Now frameworks like React are at or beyond the sophistication of anything native. Practically every other UI technology implements their interfaces in an XML-esque syntax that is far less expressive and flexible than HTML, which end up locking you in to a small constrained ecosystem. CSS has evolved as well, and with GPU acceleration out of the box and things like grid and flexbox all of the older issues are gone.

Nah, HTML and CSS have lots to learn from iOS and Android layouts, QML and XAML.

Where is Blend for HTML/CSS?

React might be sofisticated, but having the performance of native GUIs, or the eco-system of companies selling UI components, is surely something that it will never have.

I think you’re right, but tables in scroll views are tricky in every context—if my understanding of the problem is correct, optimal rendering of this requires both an understanding of the backing data store and estimation of rows before loading. What about rendering via dynamic DOM interaction makes this fundamentally more difficult—is it something inherent to the DOM, or is it simply to do lack of effort to expose the necessary apis to do the same kind of work you can do natively to scroll through a table smoothly?

On the contrary, HTML/CSS still haven't catch up with the power of 90's RAD tooling.

Is HTML/CSS really easier to use than something like Qt/QML?

I truly believe that writing html is way easier than qt/qml. I can't remember how hard was styling in qt/qml.

This is a great sickness of the web: every website does custom styling on controls, and neglects all but the most primitive UIs. The result is a lowest common denominator: the web only really supports the click and the tap.

Consider the humble popup button: a native one can support mouse input, or arrow keys, or keyboard shortcuts, or type selection, or accessible interfaces. Take it a step further and support scripting.

But if your popup button is a div with an onClick, it won't support any of these. Even if you go the extra mile and reimplement all of them, the user won't even think to try it, because it's a "styled" snowflake. So the web sinks.

HTML is way easier because it does a hell of a lot less.

I've written and shipped UIs with AppKit/UIKit, Qt, a Tkinter (I know...) implementation, and HTML/CSS.

HTML/CSS win for a reason. ;P

Cheaper devs.

Yeah, no, it's not "cheaper devs". This is elitist gatekeeping.

HTML/CSS/JS win because at this point there's both a mountain of features that you'd need to match in a native framework, it's cross-platform with rendering engine(s) that are mostly platform agnostic, and it's _actually documented_ unlike things like AppKit.

Someone learning HTML/CSS/JS can google their issue and find a solution or guide or what-have-you with relative ease. It's nowhere the near the same for any other framework.

I would be quite happy if HTML/CSS/JS would be able to match the tiny set of 90's RAD development, and native graphics performance, that apparently never make it to that mountain.

AppKit doesn't look anything like HTML/CSS to me, nor does it appear to be heading in that direction.