Talk about a catch-22 situation. The modern web is useless without adblocking. Especially when you get forever scrolling pages with random ads stuffed in there.
I use ublock origin, and on literally more than one occasion (insert doofenshmirtz nickel quote) I've found a site that I quite like, think it's awesome to the point I actually write to the people who create it with suggestions, and then for whatever reason happen to load it without blockers and discover it's halfway useless with all the ads on it.
I fully support people being able to make some money off the useful things they build on the internet, whether it's some random person who built a thing, or the New York Times or even FB or Google, but there has to be a better local maximum than online advertising.
> Dr. Heinz Doofenshmirtz : Wow, if I had a nickel for every time I was doomed by a puppet, I'd have two nickels - which isn't a lot, but it's weird that it happened twice.
I thought about including the whole thing, but then I decided that doofenshmirtz being as google-able as it is, anyone who was curious could easily find it.
I just choose not to use it. if I follow a link and there is an ad per paragraph and video starts playing I close the tab. it's rare the page I was about to look at was actually important
As a web developing illiterate, I wonder how hard would be writing a browser extension that loads a page, does infinite scroll in memory and in background, then while it is still loading the infinite stuff, splits the content in pages and shows them instead, so that the user can go back and forth to page numbers. This wouldn't reduce the network and system load, however navigating the results would be much more friendly.
Problem is, "infinite scroll" often is infinite, meaning it will load an ass load of data in the background and take up a ton of memory, and the user may never even end up looking at that data.
I really hate the load on scroll (especially Google Drive's implementation which is absolute trash, and half the time I'll scroll too fast and it will just miss a bunch of files and I'll have to refresh the page and try again), but a better hack might be an extension that scrolls a page or two ahead for you and stores that in memory. If it was smart enough to infinitely scroll websites that are actually finite (like google drive) that would be amazing though.
In these situations what’s eating up your resources usually isn’t the data being represented but instead the representation.
This is why native apps use recycler views for not just infinite scroll, but anything that can display more rows/columns/items/etc than can fit on screen at once. Recycler views only create just enough cells to fill the screen even if you have tens of thousands of items to represent, and when you scroll they reuse these cells to display the currently relevant segment of data. When used correctly by developers, these are very lightweight and allow 60FPS scrolling of very large lists even on very weak devices.
These are possible to implement in JavaScript in browsers, but implementation quality varies a lot and many web devs just never bother. This is why I think HTML should gain a native recycler widget of its own, because the engineers working on Blink, Gecko, and WebKit are in much better positions to write high quality optimized implementations, plus even if web devs don’t use it directly, many frameworks will.
I find this idea interesting ‘These are possible in JavaScript in browsers, but implementation quality varies a lot and many web devs just never bother.’
Do you have any examples that you consider good implementations? I ask because tables seem to be the biggest offenders of slow components in say Angular / PrimeNG. I am going to a legacy app soon that is being updated (Angular but not PrimeNG). Would like to see if we can build a feature rich table that is more performant than the PrimeNG one that I know looks amazing but is the cause of many headaches.
NOTE: its not Angular or PrimeNG specifically that make the tables slow/hogs, but the amount of DOM elements inside and some of the implementation details that I disagree with (functions that are called withing the HTML being evaluated every tick). Would be great to see if this idea of a ‘recycler widget’ can help us. Cheers.
We do this at Fastmail and, if I say so myself, our implementation is pretty damn good. We’ve had this for over a decade, so it was originally built for much lower powered devices.
> its not Angular or PrimeNG specifically that make the tables slow/hogs, but the amount of DOM elements inside
Yep, this happens even with nothing but a 10-line vanilla JS file that adds N more items every time the user scrolls to the bottom of the page. Performance degradation increases with every load due to the growing number of DOM elements which eventually exceeds whatever margin is afforded by the machine the browser is running on, causing chug.
Web is not my specialty so I don’t have specific recommendations, but plenty of results turn up when searching for e.g. “angular recycler” or “react recycler”.
Which is another reason why an HTML-native recycler is desirable. The browser could be easily avoid this is issue if it were the one to implement the recycler, rather than it being a third-party bolt-on.
> Problem is, "infinite scroll" often is infinite, meaning it will load an ass load of data in the background and take up a ton of memory, and the user may never even end up looking at that data.
It's also an infinitely worse user experience and prevents you from holding your place in whatever is being scrolled. Are there advantages? Why is infinite scroll used in any context?
Personally I prefer infinite scroll, versus the alternative of finding the "next page" button at the bottom, waiting for the content to load (preloading could help here) and sometimes navigating to the beginning of actual beginning of the content I was viewing. I even used a browser extension that matched "next" buttons from pages and loaded the next page content automatically, but the extension (can't recall its name) is not available anymore.
Granted there are some downsides, such as having the browser keep extra-long pages in its memory, but overall I prefer working infinite scroll mechanisms over paged ones. As far as I see, the ability to remember the current location in the page could be easily implemented by modifying page anchor and parameters accordingly, though personally I've rarely needed it.
Perhaps if there was a standard way (so in the HTML spec) to implement infinite scrolling, it would work correctly in all cases and possibly even allow user to select a paged variant according to their preference.
Not all the paged views work correctly either. In particular systems that show threaded discussions can behave strangely when you select the next page. Worst offender is Slashdot.
Infinite scrolling, at least in most implementations, makes it almost impossible to find historic content. This could be useful e.g. to journalists and researchers, but even as a private individual I would sometimes love to be able to see what person XY posted in, say, 2019.
In other words, infinite scrolling works in "pure consumption" contexts. You'd never want to add infinite scrolling to some backoffice admin interface.
Talk about a catch-22 situation. The modern web is useless without adblocking. Especially when you get forever scrolling pages with random ads stuffed in there.