Top Checklists on HN | Hacker News Reader

Top Checklists on HN

hn.algolia.com

259 pointsgawin27 comments

Open articleView on HN

This is a great way to find many great posts and learn from HN:

"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!

works for comments too, although it’s pretty much hunting for long-tail keywords

“pm me”

“opportunity”

“pent up demand”

“I’d pay”

“I miss”

etc

At the time of this writing, this post (89 points) is already in the second page of its "own" list.

It's now on the first page for me, very meta. Does anyone here use checklists in their day to day? My work tends to shift daily/weekly/monthly, I'm not usually doing similar things most days.

Are these checklists updated?

The "Web Developer Checklist" was 5 years ago.

And the "quick website launch checklist" was 7 years.

No, this is just a search for old posts with the word 'checklist' in it. The actual quality and timeliness of any given list is something you'll need to judge for yourself.

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

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.

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.

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

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.

Nah, the four seconds is just when it has no open connection. Provided there is an open connection (that is, you performed a search on that instance of the page in the last minute or so), searching is just one round trip away—sure, latency to Canada is a few hundred milliseconds, but you’re not going to get any faster than that without edge searching.

Your argument is entirely unsound.

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.

I think you can get around these problems:

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.

But by the looks of it, the search backend isn’t being run all over the world, else latency would be decent.

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.

Their search backend is, in my experience, significantly faster than you'd expect of latencies through a typical app backend - request-to-render in 10s of millis or less. They run their search indices directly inside an nginx module, it's an interesting architecture to read up on.

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

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?

Honest answer to your question: Because they have to-do lists a million miles long, and "make an HTML-only version" is often at the very bottom of that list, because it may require high investment while providing few benefits relative to other things on the to-do list. Also, because "giving users control" can mean a million different things… colors, fonts, sizes, dimensions, HTML vs JS, etc.

And if it’s not the same code base, it’ll probably be buggy, because it’s not the UI people normally use.

Server-side rendering of the same UI avoids that hazard, at a much lower cost.

I agree with your point (here, have an upvote), but really, this should be, and already is, a browser option. Easier to do that than to get thousands of web sites to change. I know Safari has "Disable Styles" and "Disable Javascript" tucked away under the "Developer" menu of all things. Firefox has a "No Style" option somewhere in View. Would be better if it were easier to get to or even the default.

Disabling JavaScript is pointless when it also disables the functionality of the website.

It's occurred to me that it may be a market seqmentation tactic. Possibly unintentional.

https://plus.google.com/104092656004159577193/posts/ikRoMcRw...

These are so so so useful for self teaching.

This is great! So many great posts!!

Yeah, I was quite surprised myself. Thought it was worth bookmarking and sharing ;)

Reply on news.ycombinator.com