Top Checklists on HN

That's because HN search is hosted by Algolia who encourage searching directly from JS (client side) since it's faster (one less hop to an intermediate HN server).

Re: Top Checklists on HN

#8

Post by gawin » Mon, Apr 30, 2018, 10:53 AM UTC

Svip wrote: post #6

Why does hn.algolia.com require JavaScript to work? Seems somewhat counter to the philosophy of HN's web design.

Algolia and HackterNews (Y Combinator) are two different parties. Algolia implemented the HackerNews API (which is based on Firebase). Agolia uses their JavaScript library to enhance the user experience (for near instant search results).

Re: Top Checklists on HN

#9

Post by chrismorgan » Mon, Apr 30, 2018, 11:15 AM UTC

gawin wrote: post #8

Svip wrote: post #6

Why does hn.algolia.com require JavaScript to work? Seems somewhat counter to the philosophy of HN's web design.

Algolia and HackterNews (Y Combinator) are two different parties. Algolia implemented the HackerNews API (which is based on Firebase). Agolia uses their JavaScript library to enhance the user experience (for near instant search results).

General commentary based on your use of the words “enhance” and “near instant”:

Especially in places of higher latency (e.g. Australia), using JavaScript for things like this does not enhance the user experience, but rather increases the delay, because additional round trips are required, especially when it’s over TLS on a different host as in this case.

On a good connection at these latencies (~300ms), these near instant search results you describe take around four seconds to load, rather than under a second and a half as it would be if it just served the final DOM directly—or 100ms if it could serve the whole thing from an edge location. (Having to execute half a megabyte of JavaScript for a search page before it will actually do the search seems fairly absurd too.)

Subsequent searches without a page reload will also often take 2–3 seconds due to the connection having been closed and the DNS TTL being only one minute, so it’s got to resolve that again, open a new TLS connection, et cetera.

I really wish people would actively avoid the fancy JavaScript SPA approach. (And I work on such an SPA.) There’s a place for them, but this is not a good demo of that place.

Re: Top Checklists on HN

#10

Post by crispyporkbites » Mon, Apr 30, 2018, 11:58 AM UTC

chrismorgan wrote: post #9

gawin wrote: post #8

Earlier quoted context omitted.

Algolia and HackterNews (Y Combinator) are two different parties. Algolia implemented the HackerNews API (which is based on Firebase). Agolia uses their JavaScript library to enhance the user experience (for near instant search results).

General commentary based on your use of the words “enhance” and “near instant”: Especially in places of higher latency (e.g. Australia), using JavaScript for things like this does not enhance the user experience, but rather increases the delay, because additional round trips are required, especially when it’s over TLS on a different host as in this case. On a good connection at these latencies (~300ms), these near in…

I think a JS SPA is a good fit for this. A common search use case is trying to find something obscure, which usually takes a few different searches. Once you've loaded up the SPA once (ie. your 4 second delay), you are able to do multiple searches quite rapidly as the subsequent post requests are tiny (3kb out 16kb in), new DNS resolution / TLS connections won't be required for at least a few minutes.

So if I'm doing more than one search, which I would guess is the way most people use it, then the current implementation will be much, much faster than doing a full page reload on every search.