6 ms·

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

by Svip 9y ago

karterk 9y ago
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).
gawin 9y ago
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).
- chrismorgan 9y ago
  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.
  - crispyporkbites 9y ago
    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.
    - jasode 9y ago
      >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 I don't think parent poster is talking about initial page load. Instead, the search page's javascript intercepts every keydown event so you would suffer 4 second round-trip delay for every keystroke. (You can go see this in browser's developer tools by setting a breakpoint on the keydown event.) Instead of this: [4 seconds] page load done, type "Ruby" It's this: R [4 seconds] u [4 seconds] b [4 seconds] y [4 seconds] More examples of this keydown latency frustration are retail websites like homedepot.com and lowes.com. When you're at home on a fast fiber optic connection, the keydown events work fine. (Customers generally like the "autocomplete" feature that the keydown javascript code enables.) However, when I'm at the store with a mobile phone on a slow 3G connection, each keydown takes 5 seconds and it makes it impossible to use the website.
      - crispyporkbites 9y ago
        I don't think that's right, at least for algolia (maybe others are implemented badly): - The latency for this query will never be 4 seconds (it's a tiny request/response, TLS connection is open already etc.) - There's throttling applied so if you're typing it won't send the request until you've finished typing - You don't have to wait for the previous response to come back to type another letter Finally, the real time searching means you'll probably find what you're after faster as you don't have to complete the full word for it to appear.
deleted 9y ago
[deleted]

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

by Svip 9y ago

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

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).

gawin 9y ago

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).

chrismorgan 9y ago
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.
- crispyporkbites 9y ago
  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.
  - jasode 9y ago
    >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 I don't think parent poster is talking about initial page load. Instead, the search page's javascript intercepts every keydown event so you would suffer 4 second round-trip delay for every keystroke. (You can go see this in browser's developer tools by setting a breakpoint on the keydown event.) Instead of this: [4 seconds] page load done, type "Ruby" It's this: R [4 seconds] u [4 seconds] b [4 seconds] y [4 seconds] More examples of this keydown latency frustration are retail websites like homedepot.com and lowes.com. When you're at home on a fast fiber optic connection, the keydown events work fine. (Customers generally like the "autocomplete" feature that the keydown javascript code enables.) However, when I'm at the store with a mobile phone on a slow 3G connection, each keydown takes 5 seconds and it makes it impossible to use the website.
    - crispyporkbites 9y ago
      I don't think that's right, at least for algolia (maybe others are implemented badly): - The latency for this query will never be 4 seconds (it's a tiny request/response, TLS connection is open already etc.) - There's throttling applied so if you're typing it won't send the request until you've finished typing - You don't have to wait for the previous response to come back to type another letter Finally, the real time searching means you'll probably find what you're after faster as you don't have to complete the full word for it to appear.

deleted 9y ago

[deleted]