Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finally, voting without refresh

ycombinator.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Finally, voting without refresh

#31

Post by benhoyt »

paul wrote: post #26
philh wrote: post #25

Earlier quoted context omitted.

You could always update the UI on the assumption that it will succeed, and then check the return value. If you get failure, notify the user somehow. Making the UI seem a slight bit more responsive might not be really worth it, of course.

UI latency is actually very important, and generally under-appreciated. Sometimes, it's better to be fast than perfect.

Definitely true, especially for something like up-voting. I mean, it might fail on 0.1% of clicks, but 0.1% accuracy on a vote is pretty good.

I guess if one was really concerned, you could update the UI immediately like News.YC does, and then change it back or show an error if it does happen to come back failed.

Re: Finally, voting without refresh

#33

Post by Elfan »

phony_identity wrote: post #32
danielha wrote: post #5

Prediction: this submission reaches the Top 10 after every visitor verifies the asynchronous voting. Great stuff, Pauls (and Trevor).

It's Robert. Trevor doesn't work on news.yc, I don't think.

"Thanks to Paul Buchheit for writing the Javascript, and Trevor Blackwell for help integrating it."

Re: Finally, voting without refresh

#34

Post by nirs »

There a stupid bug - after you vote, the arrow is hidden, but it will accept clicks :-) So you can continue to upvote many times, and the score text updates. When you refresh, the actual vote is restored.

Tested with Safari 419.3.

Re: Finally, voting without refresh

#36

Post by pg »

nirs wrote: post #34

There a stupid bug - after you vote, the arrow is hidden, but it will accept clicks :-) So you can continue to upvote many times, and the score text updates. When you refresh, the actual vote is restored. Tested with Safari 419.3.

I don't think I count this as a bug. If you do something stupid, you see something stupid, but it doesn't affect anyone else.

Re: Finally, voting without refresh

#38

Post by ralph »

pg wrote: post #2

Don't worry, I'm not going to post a link about each releaselet. I just wanted to thank PB for helping us.

I looked into how it worked and found other things out.

Every page refers to /news.css. Since few HTTP headers are returned with /news.css, no caching is performed AFAICS anywhere between my browser and news.yc. So every page access makes the browser request /news.css again, doubling the number of hits.

Any unknown URL returns a HTTP 200 OK instead of, e.g. a 404, e.g. http://news.ycombinator.com/standards_what_standards . This is seen by my browser when it requests a /favicon.ico. It tries twice, presumably because it isn't keen on the HTML response. That's twice per page access to news.yc. It can't learn there's no favicon because it gets a 200 back rather than a 404.

Sorting this out would just seem nice. Pretty trivial too, I'd have thought. At the moment every dynamic page access to view a thread is generating an extra three needless HTTP requests.

Re: Finally, voting without refresh

#39

Post by ralph »

ralph wrote: post #38
pg wrote: post #2

Don't worry, I'm not going to post a link about each releaselet. I just wanted to thank PB for helping us.

I looked into how it worked and found other things out. Every page refers to /news.css. Since few HTTP headers are returned with /news.css, no caching is performed AFAICS anywhere between my browser and news.yc. So every page access makes the browser request /news.css again, doubling the number of hits. Any unknown URL returns a HTTP 200 OK instead of, e.g. a 404, e.g. http://news.ycombinator.com/standards_what_stand…

On a related note, http://news.ycombinator.com/news.css returns a MIME type of text/html instead of text/css like it should. This causes warnings to appear in this browser's console.

Re: Finally, voting without refresh

#40

Post by ralph »

npk wrote: post #9
mynameishere wrote: post #8

Does it make the request, then update the number? Or does it update the number and make the request at its leisure?

Well, look at the code :) I did, it was educational. Node.href contains the values that are linked on the up/down arrows. // ping server var ping = new Image(); ping.src = node.href; return false; // cancel browser nav } The clever part is in using the image object as an ajax-like connection, response isn't check, and I'm not sure if it's async. Question: is this a common javascript idiom? Is it browser portable? Myn…

Yes, educational as you say. node.href just returns an empty text/html document when fetched. Does this happen synchronously or not? What do browsers do when they're given text/html as the content of an image and what do the specs define they do? When is ping freed? Is it automatic when it goes out of scope and does that suggest that the image fetch is synchronous?
Post reply on HN