Hacker News Reader

Comment by codinghorror | Hacker News Reader

I can't repro this.

(The following are all screenshots taken at exactly the point described.)

I am scrolled down on the main page of http://meta.discourse.org viewing topics.

http://i.imgur.com/dr0V0dn.png

I click on the topic "Development on Windows". (My read position was already at the bottom of the topic, so that's where I go. There are no new replies to read.)

http://i.imgur.com/OMcKAW5.png

I then click the back button, and go...

http://i.imgur.com/5e4DpK4.png

back to exactly the position, the very same position by pixel, I was at.

Maybe I don't understand what you are talking about, because I can't reproduce it? Can you share some screenshots?

It is true that when you deep-link into a topic you've already read, with new replies, we take you to the top of the post you had a last read position at. But that seems unavoidable and correct to me. (You could argue we should start you at the post below the last one you read, I guess.)

View on HN

As I stated, they (edit: you? I was replying from my iPhone before, and skipped the username) solved half the problem (scroll pixel offset) for the topic thread list, and half the problem (inability to deep-link for any of a number of reasons) for thread post lists. Before even having to look at your screenshots, I could tell you are measuring the topic thread lists, showing that you can re-arrive at the same pixel position viewing a list of threads. However, if you try to do the same thing for posts (where this is even noticeable: as I described, a post might be long), it fails. (To describe this differently: you seem to have ignored the part about being scrolled halfway through a post, because the list you were looking at didn't even have posts... ;P.)

(added:)

> It is true that when you deep-link into a topic you've already read, with new replies, we take you to the top of the post you had a last read position at. But that seems unavoidable and correct to me. (You could argue we should start you at the post below the last one you read, I guess.)

This is related, but not the issue: if you are looking at the middle of some post, click a link in that post or click a link surrounding that post, and then hit back, you are brought back to a position at the top of that post, as it rebuilds your location based on the URL you were coming from (which, again, is sometimes even worse than that, as sometimes it seems that certain sinews of multiple posts forming a sub-conversation seem to be ignored for constructing the URL, so you are brought back to the top of the entire thing).

I can repro it. The lag is only of a few milliseconds, but enough to capture a screenshot, so it is jarring for sure.

This is on first page load - http://imgur.com/4kB93ZX

And this is on clicking through to a post - http://imgur.com/i7B3HOE

When I hit back, I get the first page's loading symbol again.

Here's another weird thing:

Sometimes, when I click from the list of posts page through to a post, scroll down, and then hit back, it takes me to the top of the post instead of back to the list of posts. This happens only sometimes, not always.

Also, it looks like you are tracking scroll position by chopping up the page into numbered sections which are tracked in the url. Going back and forth resets the scroll position to the top of the tracked section. This works mostly fine, but is off sometimes by a line or two.

Edited to add:

In an earlier post[1], Robin argues that using client-side frameworks like Ember increases speed because you can leverage CDNs. But, I think our examples suggest that there are still some speed issues in the client-side rendering, which I think is DHH's point.

Even if total times with Ember (request to server and final render) might be less than something like pure Rails, the perceived speed for the user might be lower.

Robin gives one anecdote of some people in Prague finding his Ember site faster than others. saurik and I have provided couple more anecdotes :-)

But, it might be good to collect some proper data using something like Torbit.

[1] http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-ef...

> I can repro it. The lag is only of a few milliseconds, but enough to capture a screenshot, so it is jarring for sure.

I would say this is at least a few hundred milliseconds; if nothing else, I dare you to succeed in taking a screenshot of something that only lasts for milliseconds ;P. (I say this only because someone else might get the wrong impression about how intrusive it ends up being.)

> Also, it looks like you are tracking scroll position by chopping up the page into numbered sections which are tracked in the url. Going back and forth resets the scroll position to the top of the tracked section. This works mostly fine, but is off sometimes by a line or two.

This is the actually specific issue I was complaining about with the scroll position (and which I think was what was trying to be reproduced); its awesome that you found another one, though ;P. The longer the posts (and even just a post with a YouTube video in it is half my screen height) the more off the scroll position becomes. I often see posts on the forums I use that are a couple screens long: clicking a link from them and then hitting back with Discourse resets you to the top of the post, as the "numbered sections" are the index of the post you are looking at (with that irritating caveat that I've found a bunch of contexts where there are multiple post-like thing that somehow "don't count" for the URL).

see: http://meta.discourse.org/t/lots-of-loading-time-when-browsi...

Try viewing a topic, not the topic list, scroll down a ways into the discussion, and click a link that's posted in the discussion. Then click back. I think that's what the original post is complaining about. I was able to reproduce it on chrome.

Reply on news.ycombinator.com