3 ms·
It's not a bug, though. Like many web sites these days, they don't load the entire page upon navigation as a deliberate design choice to save bandwidth and res
by Sohcahtoa82 2y ago
It's not a bug, though. Like many web sites these days, they don't load the entire page upon navigation as a deliberate design choice to save bandwidth and resources of the client browser.
I've been bitten by this one before as well. Looking at the files tab of a pull request, I hit ctrl-f and started typing the name of a file I knew was part of the PR, and...nothing. No hits. Couldn't find it.
It wasn't until I scrolled down a little bit that the JS on the page loaded more of the diff and THEN the file I was looking for appeared in the list and could then be clicked to scroll to that file.
This kind of lazy loading saves system resources for both client and server, but reduces usability.
- itsdrewmiller 2y agoThis pattern is so frustrating - especially when they capture the hotkey for find in page but not until js has fully loaded. Makes me wonder if exposing the browser find events to the page could help - handle the find event by ensuring the whole dom is loaded and searchable.
- yencabulator 2y ago> as a deliberate design choice to save bandwidth and resources of the client browser. The complete source file is likely a tiny fraction of the size of the React gunk to show it. It's more they're trying to limit DOM size than download size, with a virtual view. And, unfortunately, HTML virtual views break things like find-in-page.
- smitty1e 2y agoEnhancements are fine, but if one is so sophisticated that the basics are forgotten, then what good are the enhancements? It's not always the most scalable approach, but I like the DTTCPW "dit-ka-pow": the Dumbest Thing That Could Possibly Work.