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

21–30 of 45 posts

Re: Finally, voting without refresh

#21

Post by benhoyt »

palish wrote: post #10
npk wrote: post #9

Earlier quoted context omitted.

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…

Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)

Google Web Accelerator won't follow the link, because it's got query parameters (a ? in the URL). See their help: http://webaccelerator.google.com/webmasterhelp.html#prefetch3

It's just as well, too -- GETs are used so often for this kind of stuff that any web acceleration tool which ignored this would break lots of sites.

Re: Finally, voting without refresh

#22

Post by pg »

palish wrote: post #7

I'm curious why you're averse to learning and using javascript, Paul. It's really close to Lisp (no compile-time macros, but functions are first class objects, has lexical closures, so on). It's really a powerful language, much more so than C. (Not criticizing, just curious)

I'm not averse to using it. Just never got around to it till now.

Re: Finally, voting without refresh

#23

Post by codeLullaby »

paul wrote: post #19
npk wrote: post #11

Earlier quoted context omitted.

Is there any particular reason for such an implementation? I think the answer boils down to this: http://paulbuchheit.blogspot.com/2007/06/wasting-time-on-things-that-really-dont.html (This is not meant to be a nasty sounding response.)

Yeah, it seems to work ok for reddit (try "work offline" then click the arrows on reddit). For things that are really important (sending an email or something) I'd check the reply, but for arrow clicking it's probably not worth the effort and delay.

Paul can say this, but,

{update the server first} - {return a value} - {update the UI}

doesn't require much "effort".Its just a good practice. I am just suggesting Paul.

Re: Finally, voting without refresh

#24

Post by ralph »

benhoyt wrote: post #21
palish wrote: post #10

Earlier quoted context omitted.

Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)

Google Web Accelerator won't follow the link, because it's got query parameters (a ? in the URL). See their help: http://webaccelerator.google.com/webmasterhelp.html#prefetch3 It's just as well, too -- GETs are used so often for this kind of stuff that any web acceleration tool which ignored this would break lots of sites.

GWA did use to follow all GETs, including those with parameters, and did cause all kinds of grief because of poorly written web sites, so they added the query parameter check to work around it.

Re: Finally, voting without refresh

#25

Post by philh »

codeLullaby wrote: post #23
paul wrote: post #19

Earlier quoted context omitted.

Yeah, it seems to work ok for reddit (try "work offline" then click the arrows on reddit). For things that are really important (sending an email or something) I'd check the reply, but for arrow clicking it's probably not worth the effort and delay.

Paul can say this, but, {update the server first} - {return a value} - {update the UI} doesn't require much "effort".Its just a good practice. I am just suggesting Paul.

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.

Re: Finally, voting without refresh

#26

Post by paul »

philh wrote: post #25
codeLullaby wrote: post #23

Earlier quoted context omitted.

Paul can say this, but, {update the server first} - {return a value} - {update the UI} doesn't require much "effort".Its just a good practice. I am just suggesting Paul.

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.

Re: Finally, voting without refresh

#27

Post by Bogtha »

paul wrote: post #17
palish wrote: post #10

Earlier quoted context omitted.

Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)

It's just an adaptation of the old, non-js html, in which the arrows were just links, and it's written such that it will work in the old way if the js doesn't work for some reason (like I never bothered to test it with all the browsers). Anything that assumes that GET links can be arbitrarily followed will break stuff all over the web. GWA needs all kinds of heuristics to avoid that kind of thing. (maybe they avoid s…

> Anything that assumes that GET links can be arbitrarily followed will break stuff all over the web.

Arbitrarily performing GETs is something condoned by the HTTP 1.1 specification. Anything that assumes that GETs won't be arbitrarily followed is clueless.

You'd think people would have learned this the first time around. Don't write out-of-spec code and then complain when conforming code comes along and trashes your app. It's your bug, not theirs.

> GWA needs all kinds of heuristics to avoid that kind of thing.

How reliable. Wouldn't it be better to follow the spec so this kind of guesswork wasn't necessary?

Re: Finally, voting without refresh

#29

Post by pg »

gyro_robo wrote: post #28

Well, this explains why PG is so big on co-founders. The amount of AJAX needed is very little, and he still had two other people do it for him.

The sw on the server is somewhat more complex. It takes some amount of knitting closures together to e.g. allow the submission of a link via the bookmarklet to work even when it has to be interrupted by a login.

Re: Finally, voting without refresh

#30

Post by gyro_robo »

pg wrote: post #29
gyro_robo wrote: post #28

Well, this explains why PG is so big on co-founders. The amount of AJAX needed is very little, and he still had two other people do it for him.

The sw on the server is somewhat more complex. It takes some amount of knitting closures together to e.g. allow the submission of a link via the bookmarklet to work even when it has to be interrupted by a login.

Oh sure, blame Arc.
Post reply on HN