I misspoke a little. I wouldn't generate the whole thing as a blob of text and then split that. I would traverse the tree depth-first making HTML blobs for ne

I misspoke a little. I wouldn't generate the whole thing as a blob of text and then split that. I would traverse the tree depth-first making HTML blobs for new comments that that hasn't been done for already, generate a linear list of comment items that each know the size of their own subtree (set that when you traverse back up to the node), and make a list of the indices of the top-level comments as I go. Then you can go through the top-level comments, adding them (and their subtrees - everything up to the next top-level index in the list) one by one into your webpage and adding up the total size so far until you reach some threshold of "too big", at which point you finish off that page and start the next one. I think caching would be important to make it fast, and you could cache the HTML of each comment or subtree. Actually, if I was making my own forum and not copying HN I would probably have the comment tree structure represented in the DOM tree, as that seems better for navigation and accessibility. All of this is totally theoretical of course! I haven't actually done it, so may be wrong.