It's too primitive an abstraction.

It was great when you were just fiddling a few little ajax widgets on a static page, but it doesn't scale.

That's what I meant by low level. Frankly, I disagree about scalability - that's up to the program's architect.

So, how would you go about altering all large numbers of page sections in realtime, without suffering the performance hit of serial page repaints, using jquery?

Haven't run into that need, I doubt most sites have, so I don't have a ready answer for you. We typically only change the parts of the page that have data that has actually changed, so DOM rendering performance hasn't been a difficult problem for us.

I thought you meant scalability in terms of code size, or number of people working on it, or number of users.

It's too reliant on state changes all over the place, making even medium-complexity web apps really hard to maintain. I find with Mithril (similar to React but smaller) it's a lot easier to understand how my app gets into a particular state.

Only if you keep too much of the complexity in the front end.

Well.. as a client interface HTML/CSS/Javascript have all been fairly anaemic compared to what is possible with native interfaces.

Once you've worked with a native interface, you're loathe to give up the potential for creation that comes with it, just to keep complexity out of the front-end.

Arguably, one could say people need to be retrained, and need to stop trying to make the web into something its not.... but considering the trends, I think that ship has sailed.