In the good old days Netflix had "Dynamic HTML" code that would take a DOM element which scrolled out of view port and move it to the position where it was about to be scrolled in from the other end. Hence he number of DOM elements stayed constant no matter how far you scroll and the only thing that grows is the Y coordinate.

They did it because a lot of devices running Netflix (TVs, DVD players, etc) were underpowered and Netflix was not keen on writing separate applications. They did, however, invest into a browser engine that would have HW acceleration not just for video playback but also for moving DOM elements. Basically, sprites.

The lost art of writing efficient code...

> Hence he number of DOM elements stayed constant no matter how far you scroll and the only thing that grows is the Y coordinate.

This is generally called virtual scrolling, and it is not only an option in many common table libraries, but there are plenty of standalone implementations and other libraries (lists and things) that offer it. The technique certainly didn't originate with Netflix.

And yet ChatGPT does not use it.

GP was mentioning that a solution to the problem exists, not that Netflix specifically invented it. Your quip that the technique is not specific to Netflix bolsters the argument that OpenAI should code that in.

I'm ignorant of the tech here. But I have noticed that ctrl-F search doesn't work for me on these longer chats. Which is what made me think they were doing something like virtual scrolling. I can't understand how the UI can get so slow if a bunch of the page is being swapped out.

Ctrl-A for select all doesn't work either. I actually wondered how they broke that.

They didn't actually name the solution: the solution is virtualization.

They described Netflix's implementation, but if someone actually wanted to follow up on this (even for their own personal interest), Dynamic HTML would not get you there, while virtualization would across all the places it's used: mobile, desktop, web, etc.

Its been about three years but infinite scroll is naunced depending on the content that needs to be displayed. Its a tough nut to crack and can require a lot of maintenance to keep stable.

None of which chatgpt can handle presumably.

Yes, tables and lists, since they have a fixed height per item/row. Chat messages don't have a fixed height so its more difficult. And by more difficult I mean that every single virtual paging library that I've looked at in the past would not work.

But they do have constant height in the sense that, unless you resize the window horizontally, the height doesn’t change.

For what it’s worth, modern browsers can render absurdly large plain HTML+CSS documents fairly well except perhaps for a slow initial load as long as the contents are boring enough. Chat messages are pretty boring.

I have a diagnostic webpage that is a few million lines long. I could get fancy and optimize it, but it more or less just works, even on mobile.

Exactly, browsers can render it fast. It's likely a re-rendering issue in React. So the real solution is just preventing the messages from getting rendered too often instead of some sort of virtual paging.

Dynamic height of virtual scrolling elements is a thing. You just need to recalculate the scrollable height on the fly. tanstack's does it, as do some of the nicer grid libraries.

To be fair I haven't looked at any solutions in about a decade lol

This is how every scrolling list has been implemented since the 80s. We actually lost knowledge about how to build UI in the move to web

The biggest issue is that there is no native component support for that. So everyone implements their own and it is both brittle and introduces some issues like:

- "ctrl + f" search stops working as expected - the scrollbar has wrong dimensions - sometimes the content might jump (common web issue overall)

The reason why we lost it is because web supports wildly different types of layouts, so it is really hard to optimize the same way it is possible in native apps (they are much less flexible overall).

Right. This is one of my favorite examples of how badly bloated the web is, and how full of stupid decisions. Virtual scrolling means you're maintaining a window into content, not actually showing full content. Web browsers are perfectly fine showing tens of thousands of lines of text, or rows in a table, so if you need virtual scrolling for less, something already went badly wrong, and the product is likely to be a toy, not a tool (working definition: can it handle realistic amount of data people would use for productive work - i.e. 10k rows, not 10 rows).

Agreed - I've had this argument with people who've implemented virtual scroll on technical tools and now users can't Ctrl-F around, or get a real sense of where they are in the data. Want to count a particular string? Or eyeball as you scroll to get a feel for the shape of it?

More generally, it's one of the interesting things working in a non-big-tech company with non-public-facing software. So much of the received wisdom and culture in our field comes from places with incredible engineering talent but working at totally different scales with different constraints and requirements. Some of time the practices, tools, approaches advocated by big tech apply generally, and sometimes they do things a particular way because it's the least bad option given their constraints (which are not the same as our constraints).

There are good reasons why Amazon doesn't return a 10,000 row table when you search for a mobile phone case, but for [data ]scientists|analysts etc many of those reasons no longer apply, and the best UX might just be the massive table/grid of data.

Not sure what the answer is, other than keep talking to your users and watching them using your tools :)

Desktop GUI toolkits aren't less flexible on layout, they're often more flexible.

We lost it because the web was never designed for applications and the support it gives you for building GUIs is extremely basic beyond styling, verging on more primitive than Windows 3.1 - there are virtually no widgets, and the widgets that do exist have almost no features. So everyone rolls their own and it's really hard to do that well. In fact that's one of the big reasons everyone wrote apps for Windows back in the day despite the lockin, the value of the built-in widget toolkit was just that high. It's why web apps so often feel flaky and half baked compared to how desktop apps tend(ed) to feel - the widgets just don't get the investment that a shared GUI platform allows.

Same. It’s wild how bad it can get with just like a normal longer running conversation

Yeah just had this earlier today, I had to write my response in vscode and paste it in, there were literal seconds of lag for typing each character. Typical bloated React.

Just because a web application uses React and is slow, it does not follow that it is slow because of React.

It's perfectly possible to write fast or slow web applications in React, same as any other framework.

Linear is one of the snappiest web applications I've ever used, and it is written in React.

Does not, in the seeming absence of other snappy examples and the overwhelming evidence of many, many slow React apps, the exception prove the rule?

There are plenty of snappy examples. Off the top of my head: Discord, Netflix, Signal Desktop, WhatsApp Web.

Discord, maybe. But Netflix and WhatsApp Web? Those are bloated cows, just less broken than average.

Those are all really poorly-performing.

Sure it's possible but those are a handful of exceptions against the norm, when the general approach so easily guides you towards bloat upon bloat that you have to be an expert to actively avoid going down that route.

Almost certainly running some sort of O(n^2) algorithm on the chat text every key press. Or maybe just insane hierarchies of HTML.

Either way, pretty wild that you can have billions of dollars at your disposal, your interface is almost purely text, and still manage to be a fuckup at displaying it without performance problems.

OpenAI sites are the only ones that do this to me. I have to keep a separate browser profile just for my OpenAI login with absolutely nothing installed on it or it'll end up being dogshit slow and unusable.

That's how eating your own dogshit works, or whatever was that saying