Hacker News Reader

Comment by chrisbroadfoot | Hacker News Reader

Is it just me or does this feel really slow?

Not too bad. On the sticky elements example, if I furiously flick my scroll wheel downward, there is a noticeable but tiny delay for the section menu to "catch up" at the top of the screen. The infinite scroll example seems fine, as does the analytics example. Is there really any way to get faster performance in the first example other than just giving the section menu div position:fixed (which doesn't exactly do the same thing)?

I think he means the main page, that one scrolls fairly jerky for me, too (OSX/Chrome).

However I think this is more due to the generous use of drop shadows than the javascript.

Plugin author here, I can help clarify that. The scrolling is throttled so that all the checks aren't run with every single scroll event, as that would choke everything. So the small delay you see there is some 0-100 millisecond value while it hasn't triggered the event yet.

You can change the throttle by setting $.waypoints.settings.scrollThrottle = 50, or whatever number you like, to try to reduce flickers in cases like these. Just be aware its a balance you'll be striking with executing more scroll checks. But all the selectors and offset values are cached so the performance should still hold up should you choose to lower this value.

Reminds me of this, I guess you read it already:

http://ejohn.org/blog/learning-from-twitter/

Based the throttling on that exact post.

I love what you did with this and i will definitely play around with it. This functionality should really be built into the browser in my opinion. I was thinking, for performance reasons, did you try ditching the $(window).scroll and go with this? http://jsbin.com/eciwu4/edit

"Not too bad."

If I notice it, then by definition it is too bad.

it's the box-shadow effect :-)

Just tried with the webkit inspector, if you remove all the box-shadow, the page is smooth.

Fits right in with jquery. Then in the next version they can announce it's 2000% faster.

First you make it work, then you make it perform well.

What, you were expecting the first code they wrote to be perfect?

Attaching code to scroll events will never be a good idea. Infinite scroll will never be a good idea.

"Infinite scroll will never be a good idea."

I very much disagree. It's an awesome way to capture the reader. I love it myself, not needed reloads, hunting for 'next' buttons, ... Yes you lose the relative position on the page indicator from the scroll bar, but it's irrelevant by the time you get to the bottom of the page anyway.

You also lose all indication of the total content length, which is IMHO a bad thing in many contexts.

If the content is not truly infinite (#comments known?), just very large, you could solve the scrollbar issue by giving the page the right vertical size (or an estimation), but only populating the HTML if the user scrolls somewhere.

so the page looks broken or like its still loading? Yah great usability

You'd use AJAX to load the elements, so it doesn't show as loading. And you make sure the user never sees the empty space, given normal scrolling speed, by loading the area around the visible screen. Certainly not worse than extending the page when the user reaches the bottom, as some sites do.

Reply on news.ycombinator.com