* Works well on mobile
* Does fancy tricks with scrolling without breaking normal scrolling behavior or turning into a performance nightmare
* Good design and very readable (when many other websites seem to equate good design with low contrast, thin text)
So I would rather consider it a poorly implemented website. Since when do we need Javascript to display a grid of images? This site can be easily implemented in plain HTML; why did they chose to use JS here?
I can see a case for a static version of the site being available, and I think with a bit more work they could have generated one from the react source.
That said, and this is more of a generalization, I think hacker news has a bias towards JS-free sites. Accessibility is an issue, but you can have a fully accessible JS-based site. JS can make it difficult for a scraper to interact with a site, but a separate xml (or whatever) document would be better to allow scraping anyway.
Basically, when developing a site at some point you decide how much effort you're going to put into supporting users who don't have javascript (usually out of choice), and for most people the answer is zero.
I guess that people might prefer SPA because they are not very good at server programming or maybe they think it can make their resume look better (though I don't think choosing a complicated solution instead of simple one makes a good impression of an engineer).
Of course there are cases when you can't do without SPA: apps that work offline, interactive apps, online editors etc. But it doesn't make much sense to use SPA for a blog.
> at some point you decide how much effort you're going to put into supporting users who don't have javascript (usually out of choice), and for most people the answer is zero.
...until SEO people say that the site is poorly indexed so you need to generate a HTML version of the site. And you understand that it would be easier just to make a plain HTML site from the start.
I am not implying any contempt towards HTML fundamentalists. A website I made (https://elv.sh) works without JavaScript, precisely because the ratio of HTML fundamentalists among shell users is likely non-negligible :) It evens works with w3m, for that matter. The "terminal screenshots" are actually just text and they show up in their full glory in w3m.
I don't understand your complaint about the "preloader". It is a placeholder while the website is fetching images in the background, and, assuming that it is implemented correctly, it does not add any latency. Without the "preloaders" the images are not going to show up immediately, you will just see a blank page or partially blank page. The preloader gives you some idea that the website itself can be reached and I think it is a nice interactive feature.
> I don't understand your complaint about the "preloader".
It makes page load seem slower. Browsers can display HTML progressively even if it is not completely loaded, but preloader makes the user wait until all the resources are fetched. This is effectively discarding all the improvements browsers implemented for faster page rendering.
Also it is annoying to see a blank page when you navigate back and forward.
Only because in this case, the website is actually quite slow under load. Triggering a full browser page load would seem even more slow.