I’m happy to report that after a week of production use, it’s clear that this technique is a significant improvement over what we were doing before for several reasons.
It doesn’t matter how fast or slow the task is;
unjank benchmarks it on-the-fly and runs it as quickly as the device will allow. This means that your application is jank-free on all devices without you having to come up with magic numbers that determine how quickly a task should run.
An unexpected discovery was that kinetic scrolling in Webkit works very well even if the page is getting longer during the scroll. This means that if your user is scrolling down a long list as it is being rendered with
unjank, they will not perceive it as slow at all. Webkit preserves the momentum of the scroll and keeps going as the page gets longer.
The ability to abort an ongoing task is critical because most tasks are initiated by a user action. For example, if you have two tabs that have a long list each, quickly switching between the tabs will eventually crash the application unless the rendering of the lists is aborted when the tab becomes inactive.
I’m going to be using unjank a lot more going forward, especially where lists are involved. I pulled up the Getable app to experience it pre-
unjank, and it has that signature lagginess associated with web apps, despite our use of
unjank, our longest lists no longer cause the browser to stutter — a small step out of the uncanny valley of hybrid apps.