And the comments on that page (840kB) are smaller than the Javascript on a discourse site (4MB).
Also this 4MB number isn't correct; I count 700kb. Feel free to double check my work:
Jeff, I respect you, but I don't understand where you are going with that comeback.
Namely, even with bloody awful markdown, HN still delivers 1000 comments in 1/4 of the bytes.
Another interesting idea, as almost everyone doesn't actually comment, wouldn't it make more sense to load the editor javascript dynamically? As far as I know, the silent majority read comments but never reply. In fact, I vaguely remember Jeff even having a blog post that most people never participate, they just consume (could be wrong!).
Also, I haven't kept up with it, but mobile browsers used to have fairly aggressive cache invalidation to save space on the phone, so serving big chunks of JavaScript in the hope it might get reused one day wasn't actually a great idea.
Are you sure this is correct? I count 700kb of total content (including the actual HTML and CSS), not 4mb, so I think your comments are premised on a number that's off by almost 6X?
So how you feel about this depends on "how often you use the app". If you only plan to visit that one page, ever, then it's not a great tradeoff (though 700kb -- no idea where you are getting 4MB from -- of images is basically nothing on a webpage these days). If you visit many discussions and many pages, it's a win.
In other words a single discussion doesn't need 4000 comments, you just need to read 4000 comments across all discussions all time. I'm not sure your math is correct here, either: I just visited meta.discourse.org in incognito mode and I see about.. 700kb of javascript?
I'm sorry but I don't know where you are getting 4 megabytes out of 700kb. See above screenshot.
Answering Macha, below:
- Your chosen example is missing http/2 so requests aren't batched
- Discourse homepage by default shows user avatars for each participant, up to 5 in each topic, so there will be "more images"
I suggest testing with meta.discourse.org (hosted) or discourse.codinghorror.com (self-hosted) to make sure you're looking at apples to apples, and properly configured sites.
72 requests, 50s load time, 3.5mb data. It would have been smaller if you'd served the screenshot of the page.
HN for comparison:
6 requests, 50kb, 0.72s
Now how about your contemporary forum competition.
Here's a Xenforo forum:
http://i.imgur.com/tlzZ5WN.png
19 requests, 2mb, 5s
And that's with the massive background image you can see, which is 1mb in size by itself.
EDIT:
Since Jeff stated the comparisons weren't apples to apples, xenforo.com/community vs meta.discourse.org . Both boards running in basically stock configuration from their own sites:
* Xenforo.com: 43 requests, 1.4mb, 4s
* meta.discourse.org: 73 requests: 3.2mb, 4.5s
Definitely a better showing than the ACEO forums, but still loses the comparison.
Too lazy to take more screenshots, but reddit is 50 requests, 1.3mb, 3s for comparison.
I'm unclear where you are getting 3.2MB from, since sorting by filesize, here are the largest network requests at meta.discourse.org:
As you can see, starting at 11.5kb and below it's all images (avatars).
I suppose you could try with images disabled. If you want to make a case that 'not showing avatars by default uses less bandwidth', then I guess I can agree with that. But these images won't affect actual load time, as images rez in later, and all the dimensions are set on the page.
Regarding the 4mb thing, I pulled it out of 1wd's comment. It would be best if 1wd came back and explained. That said, I believe the discrepancy is probably between the size of compressed javascript in the network and it's uncompressed size. Firefox dev tools show 3.1mb for meta.discourse.org. I don't know how to view the total size in Chrome's dev tools, but if you click the "use large request rows" in the Network tab you will see that application.js by itself takes up 1.5mb.