HN is not user friendly. Better comparison is Stack Exchange which is way more rich and runs on small (relative) infra.
The idea that a website needs to be “rich” to be usable is one of the dumbest things the industry has convinced itself of in the last 20 years (following only ‘yaml is a smart way to encode infrastructure’).
For example, if it was more user-friendly, it could have links to jump between root comments, because right now very popular top comments tend to accumulate most interactions, and scrolling down several pages to find the next root thread requires effort.
TY!
It takes substantial wisdom to arrive at an 80% solution and cease fannying about.
What do you prefer?
* doesn't encode Norway to false;
* most formatters for JSON are deterministic.
* doesn't deserialize into arbitrary objects;
YAML, in in constrast...
* YAML is insecure by default and will deserialize into arbitrary objects;
* YAML knows that there's no such thing as wall clock time, there's only number of seconds since midnight;
* YAML has 22 ways of writing true or false, and the parser will silently replace your "strings" with false.
* There are 63 ways of writing multi-line strings;
* A truncated YAML file is still a "valid" YAML file.
JSON is one strict subset, but one that makes smart trade-offs for strictness and machines like error detection and syntax-typed types.
We decided on a different subset of YAML for our users that were modifying config by hand (even more strict than StrictYAML). Some of the biggest features of YAML are that there is no syntax typing, and collection syntax is simple (e.g. also true for JSON, false for TOML).
For example, a string and a number look the same. This seems bad to us developers at first, but the user doesn't have to waste 20 min chasing down an unmatched quote when modifying config in a <textarea>. Beyond that, it's the same amount of work as making sure the JSON is `"age": 20` instead of `"age": "20"`, one just has noisier syntax.
I think the StrictYAML docs have a great breakdown of the advantages: https://hitchdev.com/strictyaml/why-not/
We decided against TOML because nesting is too confusing. https://github.com/toml-lang/toml/issues/846
Yes, I've heard that SO runs on relatively simple and modest infra. And agree that would be a good example.
>HN is not user friendly
How so? I find the HN UX a refreshingly simple and effective experience. It might not have all the bells and whistles of newer discussions fora, but it doesn't obviously need them. I'd say it's a good example of form/function well suited to need. Not perfect perhaps, but very effective.
YMMV of course.
So, I think there is a lot more in common than you think between HN and SO.
Other than that, I think it's delightfully ugly and lightweight.
Having to separately configure individual sites or web apps for dark mode is a nonstarter anyway; if you could do that, would you really want to?
Ideally, you should be able to set your device to dark mode, and everything would follow: every app, every site in the browser.
Some combination of setting your OS to dark mode and using a dark mode extension in the browser sort of approximates that, imperfectly.
We still need the workaround via extensions or Userstyles for the ones that don't implement that, sadly.
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Also, HN apps tend to make it harder to send interesting things to Roam or the laptop or Safari's reading list, the website makes that really convenient.