Hacker News Reader

Comment by vsnf | Hacker News Reader

Speaking as someone who only very occasionally does browser related programming, what is the supposed sin committed here by implementing it this way?

View on HN

In programming in general, sleeps are generally considered....(I'm lacking the word)...distasteful?

If your code needs to wait for something, it's better done with some sort of event system or interrupt or similar; the reason being that a 5s wait is a 5s wait, but if, say the thing you're waiting for returned in 10ms, if you're using an alternative solution you can carry on immediately, not wait the remaining 4.99 seconds. Conversely, if it takes longer than 5s, who knows what happens?

Sure, but assuming we take it as face value that this is a straightforward attempt to force a UX-destroying delay, I don't see what makes this so terrible. It's meant to force a 5 second wait, and it does it. Problem solved.

The 5-second wait is the issue, not the means it was obtained -- a fixed wait time either wastes the user's time (by making it take longer than necessary) or is prone to bugs (if the awaited task takes >5 seconds, then the end of the timer will likely break). The better question is _why_ a 5-second wait was necessary, and there's almost certainly a better way to handle that need without the fixed wait time.

OPs point, I think, is that wasting the user's time is part of the point of the code. This specific code seems partially meant as a punishment of the user for using an adblocker.

*for using firefox instead of google's own browser.

That's somewhat in debate, the last I saw. The initial report was it affected a user using Firefox, and it didn't when they switched useragents. Since then, there have been reports of users not seeing it in Firefox, but seeing it in other (even chromium-based) browsers. So it seems likely they are A/B testing it, but less clear if they are intentionally targeting non-Chrome browsers.

Their goal, quite clearly, is to prevent (or at least heavily discourage) adblockers. This is one attempt to detect them, and maybe in Chrome they have a different detection mechanism so it doesn't show the same behavior.

It would be a particularly foolish move on their part to push Chrome by punishing everything else right now, while they are in the middle of multiple anti-trust lawsuits. It makes me think that is unlikely to be the intent of this change.

> In programming in general, sleeps are generally considered....(I'm lacking the word)...distasteful?

Hmmm.....

In programming in general, Javascript is generally considered....(I'm savouring the word)...distasteful?

Yea, nah. I put a sleep in a Javascript/Dart bridge the other day.... We can do better, I can do better,

they are a lazy man's solution to race conditions that does not actually solve the problem of race conditions, only makes them less likely to cause a problem at an often extreme cost to responsiveness as seen here.

I don't know if this is what was meant, but my assumption is that it is quite brazen and crude.

But then I think of some alternative method where they send an ajax request to "sleep.google.com/?t=5" and get a response like "" after five seconds.

Yep, curious to know the same thing myself.

For one, they didn't use React.

Reply on news.ycombinator.com