

Steady.js – No more scroll jank - khalidlafi
http://lafikl.github.io/steady.js/

======
null_ptr
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
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](https://developer.mozilla.org/en-
US/docs/Web/CSS/position)

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

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

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

~~~
werdnapk
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.

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

~~~
codexon
Jank is a slang word.

[http://www.telegraph.co.uk/culture/10303816/Derp-YOLO-and-
Ja...](http://www.telegraph.co.uk/culture/10303816/Derp-YOLO-and-Jank-make-it-
in-to-new-dictionary.html)

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

~~~
sehr
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

------
notduncansmith
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
You're referring to "jank" when additional content is added to the page, which
to my understanding isn't what this library remedies.

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

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

~~~
underwater
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.

------
huhtenberg
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](http://lafikl.github.io/steady.js/examples/infinite.html)

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

------
rnnr
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
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
A proper implementation of infinite scroll loads until the window is filled.

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

