I am sure I can make a list with just text and not css I can insert 1000 text nodes in it, the issue is if you have something mroe complex like a grid with thumbnails and titles, and a small description under, and some css effect for hover, and a few buttons when you hover over those items etc. In a sane GUI this 1000 widgets are not created at all, only the visible ones are created and when you scroll the data under the Widget is swapped, this is great because you don't have to focus on performance or use pagination and then pretend pagination is better UX.
Just to clarify I agree that there should not be many DOM nodes in a page, the browser or framework widget should be smart and transparently recycle the existing DOM elements, I imagine there would be some new List and Grid widgets that are more advanced but that could be used by everyone with his favorite framework.
As a side note, this gets a little bit at an issue I feel pretty passionate about, which is that HTML is not a language for laying out interfaces, it is a user-facing interface itself. HTML isn't for programmers, it's for users.
The sane GUI you're talking about is essentially virtual rows, they're just baked into many native toolkits. A native interface doesn't insert everything because it doesn't have to, its interface is purely visual. If there are accessibility controls, they happen through a separate interface. If there are keyboard controls, they're based on the widget, not based purely on the content.
This is not a universal opinion, you will find people who disagree with me on this. But I think the web is fundamentally different than that. The web at least attempts to force your text interface and visual interface to be the same.
I'm not sure if it was to you or someone else that I mentioned that many apps (even native ones) are really just interactive documents when you think about their data separate from their styling. In my mind, the innovation of the web is that it acknowledges that, and it forces your interface to be a pure XML-like tree. And then you can put some styling on top of that with CSS if you want to. There are a few exceptions to that, but for the most part, HTML doesn't really let you hide a ton of information.
So imagine if you were building an app in GTK, and GTK said, "okay, first give me a pure-text representation of your interface that I can pipe to a terminal. And then I will allow you to position boxes on the screen, but only from the text that you told me I can pipe to the terminal."
That's a very different paradigm than how most other application frameworks work, and I think that the DOM's insistence of not having a lot of opaque data-bindings where possible makes a lot more sense when viewed through that lens. That lens also helps explain why some devs (myself included) got very annoyed about Google messing with that paradigm because they had their own 'cute' idea for web components.
The downside of this paradigm is that the tools you're talking about like data-bound lists aren't natively built into the DOM. You end up needing to use 3rd-party Javascript libraries for them. But for the most part, due to Javascript's popularity, those libraries are easy to find. Although due to Javascript's popularity, sometimes they are of dubious quality. :)
This thing where each developer re=invents same thing over and over and each implementation is broken in some way it bothers me, like the search input in Youtube has a dropdown with some suggestion, that dropdown popup can get stuck open until you reload the page, so even Google engineers are not capable of implementing a 100% working simple Widget.
I mean, yes, some of this is dependent on CSS. If you're doing complex rendering, or doing something strange with your fonts. I'm not going to make absolute claims about performance in every case, and different people have different interactions and requirements they're dealing with. There's caveats.
However, if someone comes to me and says, "I put 1000 DOM nodes into the browser and my page froze", I might not immediately make strong claims about the application, but I am going to immediately start looking around the codebase suspiciously to see if they're doing something strange or abnormal.
The current HN page you're on right now has ~2500 DOM nodes. Does it freeze for you when you load the page?
People complain a lot about DOM insertion, but while DOM insertion does sometimes cause problems, I've found it's more often that the problems happened before the insertion. At the point where DOM insertion actually becomes a problem, I suspect we're usually no longer talking about lists of 1000 simple table elements, or just putting 100 search results on a single page.