| ▲ | DenisM 3 hours ago |
| 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... |
|
| ▲ | zdragnar 3 hours ago | parent | next [-] |
| > 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. |
| |
| ▲ | tmpz22 2 hours ago | parent | next [-] | | 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. | |
| ▲ | dotancohen 2 hours ago | parent | prev [-] | | 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. | | |
| ▲ | jasonfarnon 2 hours ago | parent | next [-] | | 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. | | | |
| ▲ | BoorishBears 2 hours ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | groundzeros2015 2 hours ago | parent | prev [-] |
| 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 |
| |
| ▲ | bloomca an hour ago | parent [-] | | 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). | | |
| ▲ | TeMPOraL 21 minutes ago | parent [-] | | 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). |
|
|
