[ben_w]

The web being slow is an example of UI in general becoming slow.

My experience over the years has been that UI frameworks are very fun to write but we'd all be better off if our managers said "no" to them — vanilla HTML is very fast, as is UIKit.

Likewise for development, while Interface Builder gets flack for the file format making it hard to collaborate or even to code review, actually using it to implement a UI from the design team is fast and easy compared both to UIKit in code and to SwiftUI (and SwiftUI is better than some of the other programmatic UI frameworks I've seen, though it also loses points for a WYSIWYG editor that gives up if you look at the keyboard wrong).

[p_l]

The web is slow because it's used in ways that it's not exactly designed for.

This means that even when you try your best, you can end up with very complex code paths for doing things that would be handled through simpler ways in "proper" GUI framework.

It's not really a dig at browser engines - they are very optimized. But they are very optimized because otherwise it would be even more unbearably slow.

[ben_w]

I'm not complaining about the browsers themselves either.

IIRC, almost every UI widget in iOS and Mac OS (even way back to 68k) and VisualBasic and Java is a rectangular interaction region, even if the appearance is circular.

A <div> with a background image and an on-click, on-mouse-move etc. handlers, can replicate the look and behaviour with much lower complexity than even the React tutorials I've done (I assume that React is even more complex in production?)

Last tech conference I went to, there was a talk on how to boost website performance by loading your JS in a particular order — at that point, I think you're better off with a website being an img and <img> and <map> and everything more than that being done on the server. Not that this is a good idea, just less bad than having so much JS you need to re-order it to keep load times down.

jQuery seems nice, from what little of it I've seen in practice.