3 ms·

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 o

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). This is still better than original Discourse which for this same thing needs 6MB of data (1.2MB compressed). However Discourse does not claim to be efficient or elegant. This kind of web performance engineering attention to detail will go a long way. The benefits for users on slower connections are particularly important. And as an engineer, showing few KBs of information with few MBs of data should bother you. Your information to data ratio is less than 1%. Excessive reliance on JS does not help. The best way to think about JS is as a feature enhancer not a feature requirement. See also: https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm Having said that I think it is absolutely great that you are doing this and I hope we can get efficient and elegant forum software. This will certainly help nim adoption if executed in the way that is true to your values. Edit: A competitor has been mentioned in comments: https://fluxbb.org/forums/index.php https://fluxbb.org/forums/index.php They are showing similar amount of information in "only" 100KB of total data. And 80% of it is CSS (which does seem excessive for what it does, I am sure 5KB of CSS would do the same job taking that page to amazing 25KB of total data).

masklinn 5y ago
> 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).
tyingq 5y ago
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.
khaledh 5y ago
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).
- freediver 5y ago
  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).
  - dom96 5y ago
    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.
    - sim_card_map 5y ago
      Improving its efficiency would mean re-writing it entirely, since it's an SPA app with 4 MB of JavaScript.

masklinn 5y ago

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

tyingq 5y ago

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.

khaledh 5y ago

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

freediver 5y ago
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).
- dom96 5y ago
  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.
  - sim_card_map 5y ago
    Improving its efficiency would mean re-writing it entirely, since it's an SPA app with 4 MB of JavaScript.