Hacker News Reader

> Because this is coming from nim and nim design goals are to be efficient and elegant I can not help but notice the excessive bloat. The main forum page is 4MB of data (~700kb compressed) to basically communicate 3KB of information (plus avatar images which should not be more than few kb total anyway).

As a basis of comparison, HN's home is 43k, and old.reddit.com is currently 3.16MB including all assets, the sole markup is 363K (gzip'd to 104).

Most of the 4.2MB of data is cacheable; only ~128KB gets re-downloaded on subsequent visits (about 100KB of which has to do with Google recaptcha). With compression, what actually gets downloaded on subsequent vists is on the order of ~60KB.

That being said, I agree that the web is bloated and needs to go on a diet. We just need to be careful on where to spend our energy for optimization (caches are great and we should rely on them).

In principle I do not share that view. The browser does not start with this data cached. You actually need to load all of it. On a slow connection you may give up and never come again to reach a cached-load scenario. It is a lose-lose scenario. IMO cache should be used to make an already fast page lightning fast.

Web perfomance optimization tells me a lot about a product and its priorities. I do not mind bloated products that perform a certain function well for their users and never try to pretend to be optimial from an engineering standpoint.

But this is nim, language that markets itself as efficient and elegant, and execution like this can hurt their credibility and brand perception in the very community they are trying to market themselves in (developers).

I hope this doesn't come across badly but: NimForum is an open source project, as such I would encourage you or anyone to help improve its efficiency. I think there is a lot of low hanging fruit here and I'd happily help with any patches that fix them.

Back in 2018 when I implemented the basis for this modern reimplementation of the Nim forum I focused on the functionality and a solid CI so that we can easily accept others' contributions without fear of regressions. Unfortunately I had only 2 solid weeks to make this a reality and optimising the code size didn't make the cut.

Improving its efficiency would mean re-writing it entirely, since it's an SPA app with 4 MB of JavaScript.

It could, but it doesn't. As many have remarked already, it appears there is a bug that's causing the site to reload Google's recaptcha multiple times.

This is a big low hanging fruit fix, another is simply minifying the Forum's JS, there is also bound to be a lot that can be done on the Nim side to reduce the code size generated.

As far as I can see you already have a minification task [1] in your nimble file. May I ask you why you are not using it to save bandwidth both for your sever and your visitors?

[1] https://github.com/nim-lang/nimforum/blob/master/nimforum.ni...

> it appears there is a bug that's causing the site to reload Google's recaptcha multiple times

I forgot to mention that it is not a bug. See https://github.com/google/recaptcha/issues/335 for example (I believe there are others issues like this in the repo)

And about 3.7MB is JavaScript (mostly reCaptcha—eww! why load it when I’m just browsing the site?—being loaded multiple times—quintuple eww!; the forum’s own JS is only about a megabyte). Just parsing and compiling that code (not even executing it!) will take over a second on many common low-end mobile devices still in use (even some new), several seconds on slower devices.

> caches are great and we should rely on them

Caches hang or crash my browser. Please don't. (Amazon Kindle Paperwhite – yes, this has been my only web browser several times – no, I will not replace it with another Kindle when it breaks)

3MB of the 4MB data appears to be JS, and a lot of that repeated calls to recaptcha_en.js, which would be cached after the first call. Though I don't know if all those repeated calls are really needed.