Whenever you attach an event handler on scroll, it can impact page performance because the javascript needs to be evaluated before the scroll event can continue AFAIK...going from some old Paul Irish talk on performance.
The #1 killer he found responsible for "jankiness" (that horrible scroll feeling where the page scroll is unresponsive and not 60 fps smooth) is by people attaching event handlers on the scroll event that take more than a few ms to complete, thus reducing the frame rate of the page.
It seems like this library is throttling the evaluation of the event handler but you still need to be careful as to not solve one performance problem and create another. I know I personally hate slow scrolling web pages.
This seems like something that should be implemented in some as yet unreleased CSS selector. But that still won't stop people from abusing it.
Whenever I rely on scroll information, I store the event info I need on the scroll event in some variable, and the logic that would normally be placed in the callback goes in a separate requestAnimationFrame loop. This way, even if it takes a few ms, it doesn't impact the scroll speed of the page. I wish more developers did this.
"Whenever you attach an event handler on scroll, it can impact page performance because the javascript needs to be evaluated before the scroll event can continue AFAIK...going from some old Paul Irish talk on performance."
This isn't true no.
Scrolling is an asynchronous event, in this case meaning it will happen regardless (without waiting on any JS event handlers), the JS event triggers after its happened.
This is the reason you can't prevent scrolling from javascript.
Unlike clicking links, or submitting a form, the browser doesn't wait for any JS event handlers to return before doing this action. This was conscious decision to stop scrolling becoming too heavy or slow, or worse...crashing the page.
It's not true in some cases, sometimes. It's still quite easy to cause performance problems listening to scroll events, because even if scroll is partially asynchronous, the webpage itself is not - the browser will wait to render new content if the page is blocked.
The #1 killer he found responsible for "jankiness" (that horrible scroll feeling where the page scroll is unresponsive and not 60 fps smooth) is by people attaching event handlers on the scroll event that take more than a few ms to complete, thus reducing the frame rate of the page.
It seems like this library is throttling the evaluation of the event handler but you still need to be careful as to not solve one performance problem and create another. I know I personally hate slow scrolling web pages.
This seems like something that should be implemented in some as yet unreleased CSS selector. But that still won't stop people from abusing it.