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.
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 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.
> (insert doofenshmirtz nickel quote)
I had to Google for it: IMDB.com has the quote: > 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.
<hat tip>The extension just needs to handle GDPR notice and Email subscription overlays.
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.
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.
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.
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”.
Apparently it was abandoned (for now?) in favor of content-visibility / CSS containment primitives: https://web.dev/articles/content-visibility
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?
Each next page click is a moment for you to reflect and notice the waste of time. Simple as that.
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.
In other words, infinite scrolling works in "pure consumption" contexts. You'd never want to add infinite scrolling to some backoffice admin interface.