This article completely fails to address the biggest problem with scroll jacking: it breaks. I don’t mean it breaks expectations or traditions, but mean the feature literally breaks and fails to work.
The magic scroller will miscalculate the document size and refuse to let me see the bottom. The scroller will get wedged behind some network request and the page freezes. Or one little javascript error anywhere else on the page will crash the scroller entirely. Or any of a dozen other failure modes.
There’s also often a performance problem. Just as an example, they link to Pleasure to Burn, which was slow to load and then jittery to scroll. Not a pleasant experience at all.
Yup. It is possible to write efficient scroll effects, by limiting the amount of logic in the scroll handler, and throttling handler calls, but most sites don’t do these.
Building off @brinker - if you have a sub-par graphics stack (using the free AMD drivers on Linux for example…) then every single scrolljacking website works so poorly I just leave the page. Web designers don’t seem to care about the lowest common denominator of who will view their web page and this can be detrimental especially if they are marketing a product.
I have the same response. If I can’t scroll your page without delay or jitter, I will leave immediately. Not everyone has a beefy machine, and you really shouldn’t need one to scroll a website.
That’s more a criticism of the implementation than the concept itself, correct? If the developer building the website is following the progressive enhancement paradigm, then this should be detected and slower machines shouldn’t be running the scrolljacking feature at all.
This article addresses whether scrolljacking should be used from a UI perspective, this comment thread is addressing the performance perspective. Both are important, IMO.
This article completely fails to address the biggest problem with scroll jacking: it breaks.
This sort of dismisses the UI problem of scrolljacking without bothering to look at it. It is true that many implementations of scrolljacking are brittle, but not all are. The article is asking, in implementations where it doesn’t break, should it be used at all?
Or one little javascript error anywhere else on the page will crash the scroller entirely.
This happens with any js, but I get where you’re coming from. Also, in the near future a lot of these effects will be available via CSS (which doesn’t break when js crashes), which would make these issues more relevant.
It is hard to imagine articles like these reducing their interactive visuals to static figures and diagrams while conveying the same information as effectively.
No, if that NYTimes page had static figures and graphs I could peruse them at my leisure, rather than watching my late-model Macbook Pro trying to emulate motion graphics from a science-fiction movie at 12 FPS.
All of these web movement techniques (for lack of a better term) are fun when I’m using a Mac Book, but on my phone they always break the site beyond use. Either the “feature” doesn’t agree with touch screens, or dragging to scroll, or inertial scrolling, or it’s simply too slow and bloated that it cripples both Firefox and Chrome on my device (Android 5.1).
Awful. Please give us saner websites. Think of the heap!
Eventually someone will start a service with headless Chromium that serves web pages already “JavaScript rendered”.
Honestly why don’t we all just use desktop clients and communicate with servers. That is honestly the direction we are headed again. All sites will use Web Sockets and all clients will be rich. We’ve had this for years but now we’re just infesting browsers because there’s “less resistance”. The resistance before was getting people to download the client automatically and automatic updates. This was a security threat before…and it still is today. Nothing has changed.
Someone should start a new directory of JavaScript-less sites.
This article completely fails to address the biggest problem with scroll jacking: it breaks. I don’t mean it breaks expectations or traditions, but mean the feature literally breaks and fails to work.
The magic scroller will miscalculate the document size and refuse to let me see the bottom. The scroller will get wedged behind some network request and the page freezes. Or one little javascript error anywhere else on the page will crash the scroller entirely. Or any of a dozen other failure modes.
First rule of innovation: make it fucking work.
There’s also often a performance problem. Just as an example, they link to Pleasure to Burn, which was slow to load and then jittery to scroll. Not a pleasant experience at all.
Indeed. Hopefully this can be fixed when this get css support, since the effects can be delegated to the CPU that way.
Yup. It is possible to write efficient scroll effects, by limiting the amount of logic in the scroll handler, and throttling handler calls, but most sites don’t do these.
Building off @brinker - if you have a sub-par graphics stack (using the free AMD drivers on Linux for example…) then every single scrolljacking website works so poorly I just leave the page. Web designers don’t seem to care about the lowest common denominator of who will view their web page and this can be detrimental especially if they are marketing a product.
I have the same response. If I can’t scroll your page without delay or jitter, I will leave immediately. Not everyone has a beefy machine, and you really shouldn’t need one to scroll a website.
That’s more a criticism of the implementation than the concept itself, correct? If the developer building the website is following the progressive enhancement paradigm, then this should be detected and slower machines shouldn’t be running the scrolljacking feature at all.
This article addresses whether scrolljacking should be used from a UI perspective, this comment thread is addressing the performance perspective. Both are important, IMO.
This sort of dismisses the UI problem of scrolljacking without bothering to look at it. It is true that many implementations of scrolljacking are brittle, but not all are. The article is asking, in implementations where it doesn’t break, should it be used at all?
“This concept is never implemented well” seems more like an indictment than a defense.
This happens with any js, but I get where you’re coming from. Also, in the near future a lot of these effects will be available via CSS (which doesn’t break when js crashes), which would make these issues more relevant.
Also what @brinker said.
No, if that NYTimes page had static figures and graphs I could peruse them at my leisure, rather than watching my late-model Macbook Pro trying to emulate motion graphics from a science-fiction movie at 12 FPS.
All of these web movement techniques (for lack of a better term) are fun when I’m using a Mac Book, but on my phone they always break the site beyond use. Either the “feature” doesn’t agree with touch screens, or dragging to scroll, or inertial scrolling, or it’s simply too slow and bloated that it cripples both Firefox and Chrome on my device (Android 5.1).
Awful. Please give us saner websites. Think of the heap!
Eventually someone will start a service with headless Chromium that serves web pages already “JavaScript rendered”.
Honestly why don’t we all just use desktop clients and communicate with servers. That is honestly the direction we are headed again. All sites will use Web Sockets and all clients will be rich. We’ve had this for years but now we’re just infesting browsers because there’s “less resistance”. The resistance before was getting people to download the client automatically and automatic updates. This was a security threat before…and it still is today. Nothing has changed.
Someone should start a new directory of JavaScript-less sites.