Steady.js – No more scroll jank

http://lafikl.github.io/steady.js/

by khalidlafi • 12 years ago

69 26 12 years ago

lafikl.github.io

ihuman• 12 years ago

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.

michaelmior• 12 years ago

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

aroch• 12 years ago

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

werdnapk• 12 years ago

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.

sehr2• 12 years ago

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

kcbanner• 12 years ago

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

notduncansmith2• 12 years ago

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

Nemcue• 12 years ago

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

notduncansmith2• 12 years ago

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

null_ptr• 12 years ago

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.

gavinpc• 12 years ago

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

mmahemoff• 12 years ago

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

i_am_ralpht• 12 years ago

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

huhtenberg2• 12 years ago

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.

digitalmaster• 12 years ago

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

underwater2• 12 years ago

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.

shawnz• 12 years ago

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.

underwater2• 12 years ago

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.

huhtenberg2• 12 years ago

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

TimWolla• 12 years ago

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

rnnr• 12 years ago

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!

dmak• 12 years ago

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.

spullara• 12 years ago

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

Steady.js – No more scroll jank

Related Stories