Weird, I thought you needed 1024 Kubernetes nodes, a 70mb React bundle and 200 engineers to host 50M monthly sessions.
Anything HN has had to implement, Reddit has to implement at a generalized, user-facing level, like mod tools.
Frankly, we underestimate how hard forums are, even simple ones. I learned this the hard way rebuilding a popular vBulletin forum into a bespoke forum system.
Every feature people expect from a forum turns into a fractal of smaller moving parts, consideration, and infinite polish. Letting users create and manage forums is an explosion of even more things that used to be simple private /admin tools.
I agree, most software is deceivingly simple from the outside. Once you start building it, you become more humble about the effort required to build anything moderately complex.
Its not that the mod tools are constantly being used, its that there's now potentially far more code complexity for those tools to even exist.
Since I've been here they've added vouching for banned users (and actually warning people beforehand) thread folding, Show HN, making the second chance pool public, thread hiding, the past page, various navigation links and the API. They've also been trying to get a mobile stylesheet to work. They've also mentioned making various changes for spam detection and performance. And the url now automatically loads a canonical version if it finds one, and the title is now automatically edited for brevity. And I've probably missed a few things.
And HN isn't a simple application by any means. Go look at the Arc Forum code - it isn't optimized for readability, or scalability or reliability, but joy - for the vibe of experimental academic hacking on a Lisp. It's made of brain farts. Hacker News is probably significantly more complex than that for being attached to a SV startup company and running 'business code' and whatnot.
Engineers.
And they're tasked with building a product that can handle Google-levels of demand, though they currently only have two customers, neither of them paying.
It indeed is imperative, but not for technical reasons.
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.