How about no more scroll jank by just delivering plain useful content without the anti-usability bells and whistles? Even the cheapest hardware out there today is able to provide a nice user experience, and in answer to that we invent new ways to make everything bloated and choppy.
While I completely agree with your principle, I find myself interested in shimming the not-yet-standard "sticky" positioning, which is in draft specifications and available in bleeding-edge [0]. Depending on how many items use it, you would have to write your scroll handlers carefully.
In cases where this would really improve usability, I consider it an exception to my general antipathy towards "bells and whistles", since it will be native before too long.
Your comment fits the general pattern of "I want to keep it simple but if I could just do X" which is entirely valid from a UX perspective and the reason why any generalised janky buster is a good step forward (assuming it does the job, and with minimial overhead).
How about understanding that presentation matters. In fact, in the marketing domain presentation frequently is the content.
One man's anti-usability bells and whistles is another person's essential user engagement element that shapes the perception of the product. You try and sell MBP in Courier New/13px at 100% width and we'll laugh it off as the most idiotic idea ever. And that's not even getting into derivatives like website design galleries that generate a lot of viral awareness, but won't even look at sites without a UX gimmick.
It's explain at the link in the first para [1]. It's the catchy way of talking about screwing with site layout and scroll performance when manipulating the DOM with onscroll events. It became a thing to look for after Google's 2013 IO and dev conferences focused and removing jank from the web and Android - both in user facing (speed up DOM manipulation) and in code (prevent jank to begin with).
Not sure why the need to invent a new word for this. Scroll "twitch" would have been a perfectly acceptable choice I would think. ie. Twitchy scrolling.
I've never heard jitter used in client side web development, so it may just be custom in this domain. That being said, claiming either one as proper seems a bit misguided
The infinite-scroll demo was pretty janky for me: Chrome 35.0.1916.114 on a Macbook Air.
Scrolled down to the bottom, and then got thrown around the page a bit before settling. Not a fun experience (and I've seen infinite scroll done right).
True, though it's jank nonetheless. I just expected a little more from a demonstration of a "jank-free" experience. Had it been a font-rendering library, I'd gladly be more forgiving. Maybe their demo should have been some kind of parallax scrolling (from whence so much of this scroll-related jank seems to originate)?
This is a great idea and I love that it is self contained.
However, I don't see a lot of benefit in the way you're using requestAnimationFrame. JavaScript is single threaded, so if your callback is a long-running function then the onscroll handler won't fire until the callback is done.
Instead of using requestAnimationFrame to delay both the checking and handler callbacks (which means callbacks don't know about the scrolling until 33ms after it happens) you'd probably be better off using it to just throttle the global onscroll handler.
You might also want to take a looks at mobile scroll events. Chrome is relatively sane but iOS Safari and the native Android browser do weird things like only firing a scroll event after the page has stopped moving.
> However, I don't see a lot of benefit in the way you're using requestAnimationFrame. JavaScript is single threaded, so if your callback is a long-running function then the onscroll handler won't fire until the callback is done.
When a normal onscroll handler runs, doesn't it block the browser from processing the scroll event until the handler is finished? I assume this is to keep that from happening.
Yeah, but let's say scroll events happen every 10ms and the callback takes 50ms to complete. The first scroll event will be relatively fast, because it's just doing scheduling.
But when the callback kicks in, the scroll events that happen in the 50ms it takes will be buffered. The browser can't pause the callback to run the event handler.
another scroll junk.
I have my monitor positioned vertical, so 1920 vertical pixels and no scroll bars, ...next pages content not accessible, stack forever at page one!
Rephrasing what rnnr said: The infinite scrolling example breaks if you are not able to scroll. For example, if you just delete enough nodes in that list where the scroll disappears, then you wont be able to load in more content.
