yes, but the minute you click a _second_ page, the Javascript app is already loaded, and we request only JSON for the new data.

Also this 4MB number isn't correct; I count 700kb. Feel free to double check my work:

http://imgur.com/a/gPiEb

Are you really arguing that Discourse's superior linear complexity outweighs the huge constant cost in any meaningfull scenario? At 4mb/840kb * 970 comments, disregarding any additional JSON data that Discourse loads, a Discourse thread would need to have 4974 comments before its strategy is more efficient than Hackernews.

Jeff, I respect you, but I don't understand where you are going with that comeback.

Think of Discourse as a JavaScript app you load on your phone. Yes there is that unavoidable first time install on first page load, but once the app is installed, all it needs to render the page is the JSON data that makes up the comments -- which is very efficient, far more efficient than a full HTML page load of a traditional website.

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?

http://imgur.com/a/gPiEb

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.

Not the parent poster, but going to the first Discourse forum in my history:

http://imgur.com/BoPPL0i

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:

http://imgur.com/a/8qaIN

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

http://imgur.com/a/SihGh

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.

This isn't remotely apples to apples; for example, HN has zero avatars, Xenforo has zero avatars, whereas Discourse shows up to five avatars per topic, of which there are many on the homepage.

I'm unclear where you are getting 3.2MB from, since sorting by filesize, here are the largest network requests at meta.discourse.org:

http://imgur.com/8v4Fp4L

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.

Thanks for the reply. You have me convinced with amortizing the cost of js over multiple visits rather than a single thread.

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.

I'm sure they could get that 4mb down if they removed all text formatting, media, quotes, replies, editing tools, user icons, and pagination.

There's a lot of other things Discourse threads have (media, collapsing, proper markdown, editing toolbars etc.).

HN has collapsable threads and uses tables for layout, which aren't exactly efficient markdown, so makes the opposite point you're trying to make.

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.

> Namely, even with bloody awful markdown, HN still delivers 1000 comments in 1/4 of the bytes.

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?

http://imgur.com/a/gPiEb

Sorry! Was just repeating a number further up the thread, should have checked myself. Worse still, you'd already corrected him and I didn't notice :(

It is encouraging to see someone as high profile as you taking the time to have a evidence-based debate on the internet.