Top Checklists on HN(hn.algolia.com) |
Top Checklists on HN(hn.algolia.com) |
"things i learned" https://hn.algolia.com/?query=things%20i%20learned&sort=byPo...
"wish someone told" https://hn.algolia.com/?query=wish%20someone%20told&sort=byP...
"how did you" https://hn.algolia.com/?query=how%20did%20you&sort=byPopular...
I'm sure there are many others like this too!
“pm me”
“opportunity”
“pent up demand”
“I’d pay”
“I miss”
etc
The "Web Developer Checklist" was 5 years ago.
And the "quick website launch checklist" was 7 years.
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.
Or just have a button somewhere for a "basic HTML" version.
Why are modern developers and UX designers so averse to giving users control over their experience?
Server-side rendering of the same UI avoids that hazard, at a much lower cost.
https://plus.google.com/104092656004159577193/posts/ikRoMcRw...
Algola has something they call a DSN that runs your search backed all over the word. So you have good latency's. [https://www.algolia.com/infra]
Additionally you could bundle only what you use in there library to make the page lighter.
The vast majority of the JavaScript is superfluous third-party libraries like AngularJS. The actual app is under 2,000 lines of code. I do not expect it would be difficult to cut the frameworks out of it at all, for a lighter and faster experience that only weighed a few kilobytes.
The JS they kick you off with is a pretty decent way to make a thorough, not-trivial search experience, you can get much more than a list of results (faceting and such builtin)
(https://community.algolia.com/instantsearch.js/)
The all-over-the-world bit is an optional part of paid plans, it's quite possible HN isn't using the global DSN
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.
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"
R [4 seconds] u [4 seconds] b [4 seconds] y [4 seconds]
- 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.
The cost difference between producing JSON and producing full HTML should be negligible, half a millisecond at most, and only a few extra kilobytes to the response (still tiny). (I’m deliberately ignoring the question of whether Algolia can emit HTML, talking rather about a theoretical system, or a system that proxied Algolia to sort that part out.) And the extra CSS and JavaScript required should be trivial.
Therefore, the difference between a full page load and slurping JSON and crafting a new DOM should be a matter of a few milliseconds at most. (And you can add a tiny JS handler that does the new page load as XHR and just replaces the body without needing to reparse any JS and CSS to shave most of those few milliseconds off if you are so disposed.)
As I assess it, the benefits of the JS SPA are a few milliseconds on each search—a frame or two at the most.
But the costs are that the first search is very slow, twice as slow in the best-case scenario (due to using a different domain—if the same domain was used, the absolute best case would only be ~33% slower, more like 40% in practice) and much worse on slow devices or higher latency environments.
The first search is the most important one and the most common one. To be sure, some will perform multiple searches, but most sessions will involve only one search.
In summary: the SPA approach has marginal benefits but severe downsides. It is not necessary or desirable for a web app like this.