3 ms·

These services seem to often get .com/.org/.net/etc results back immediately (maybe cached or API is just faster) while the longer-tail stuff is slower. Maybe n

These services seem to often get .com/.org/.net/etc results back immediately (maybe cached or API is just faster) while the longer-tail stuff is slower. Maybe not cached or has to hit one of those weirder tld servers to check. This is a case where the streaming solution makes sense because you don't want to have to wait til `example.weirdtld` is resolved when you just want to check for `example.com`. Now, you kinda admitted this in this post which is quite a change from your original post, at which point it seems that you're saying "this isn't always good" which is kinda self-evident.

Figs 9y ago
There were a couple hours between the two posts, and I was actually pissed off when I wrote the first one -- I'd had more time to think about it and cool down a bit by the time I got through with that second one. As someone who is in the class of people actually affected by developers' choices on how to "reduce latency on mobile", I reacted really badly when presented with a page that had a massive increase in load time because of JS -- when JS was being presented as the solution to a problem on mobile connections. (Frankly, I hate the way JS is being used on the modern web as it tends to make my experience browsing the web absolute hell for a couple weeks each month after I hit my bandwidth cap. I browse with it off by default, and my experience is usually better on the majority of otherwise well-designed websites.) After reflecting on it more, I acknowledged that the article does make a good point -- don't make lots of small connections to the server if you can avoid it since connection start up time can be large -- and people in the replies reminded me that the average performance I'm seeing isn't necessarily the worst case performance, and problems with the way this site was put together didn't necessarily mean the technique is bad. Now that more time has passed, I have to wonder why didn't the author just use chunked transfer encoding of HTML instead of JSON for the results? You'd get basically the same effect without needing any JavaScript at all -- and as the author brought it up in the post, he/she is clearly aware of it. That's really the first question I should have asked...

Figs 9y ago

There were a couple hours between the two posts, and I was actually pissed off when I wrote the first one -- I'd had more time to think about it and cool down a bit by the time I got through with that second one. As someone who is in the class of people actually affected by developers' choices on how to "reduce latency on mobile", I reacted really badly when presented with a page that had a massive increase in load time because of JS -- when JS was being presented as the solution to a problem on mobile connections. (Frankly, I hate the way JS is being used on the modern web as it tends to make my experience browsing the web absolute hell for a couple weeks each month after I hit my bandwidth cap. I browse with it off by default, and my experience is usually better on the majority of otherwise well-designed websites.) After reflecting on it more, I acknowledged that the article does make a good point -- don't make lots of small connections to the server if you can avoid it since connection start up time can be large -- and people in the replies reminded me that the average performance I'm seeing isn't necessarily the worst case performance, and problems with the way this site was put together didn't necessarily mean the technique is bad. Now that more time has passed, I have to wonder why didn't the author just use chunked transfer encoding of HTML instead of JSON for the results? You'd get basically the same effect without needing any JavaScript at all -- and as the author brought it up in the post, he/she is clearly aware of it. That's really the first question I should have asked...