Steady.js – No more scroll jank | Hacker News Reader

Steady.js – No more scroll jank

lafikl.github.io

69 pointskhalidlafi26 comments

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.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/position

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).

sticky isn't expected to change much, and ships prefixed (and with accelerated compositing) in iOS 7.

But it remains unavailable in Google Chrome and they don't plan on implementing it until it hits the standards board.

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.

What is scroll jank? Neither the author of this post nor the links posts explain it. Searching for more information just brings up those same pages.

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).

1: http://jankfree.org/

2: See videos on jankfree

Jank is basically jerky scrolling. This is normally caused by too much happening handling scroll events.

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.

It's not a new word, it's been around for decades

Jank is a slang word.

http://www.telegraph.co.uk/culture/10303816/Derp-YOLO-and-Ja...

They seemed to not know about proper terminology such as jitter.

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

jank is the accepted industry term for scrolling which is jerky, or happens out of sync with the initiating user input

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).

You're referring to "jank" when additional content is added to the page, which to my understanding isn't what this library remedies.

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.

So we will still get janky performance.

The infinite scroll example shows a blinking "Loading..." text and that's it. Recent FF on Windows.

[1] http://lafikl.github.io/steady.js/examples/infinite.html

I can confirm problems in Firefox. It does work in Chrome, however.

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.

A proper implementation of infinite scroll loads until the window is filled.

just a wrapper for requestAnimationFrame.. useful.. but not game changing

Reply on news.ycombinator.com