patrick.net

Yes, it always takes you to the latest page of comments.

I just assumed that people always want to see the latest comments first. Not a good assumption?

hmmm, may be not.
It took me a while to figure out that I am not seeing comments in order.

put pagination links at TOP and BOTTOM., so it is easy to jump to latest

But I do have the pagination links at the top and the bottom!

I think I made it so they don't appear if there are fewer than 40 comments though.

I don't like the pagination thing, it makes it harder to refer to older posts. I guess it does take a bit of load off the server.

Still, you could use AJAX to fetch the latest 20 links and then fetch others asynchronously so that the page loads fast, but you still get older postings. Then just insert them at higher positions in the DOM.

Depending on what your server load is, you might be able to spread out the load a bit using this method, too.

It does make it harder in the sense you have to actually go to a different page to see a comment that not on the current page of 40 comments.

It helped reduce server load and increase performance immensely. When a thread got more than ~100 comments, it would take several seconds to load, and it just went up from there, to the point where I couldn't take it.

The problem is that I have to pull each comment from the database and do a lot of string manipulation to put it on the page. I could try the Ajax thing, but Javascript introduces new problems too. It's not as standardized as HTML.

The problem is that I have to pull each comment from the database and do a lot of string manipulation to put it on the page.

Have you considered offloading the string manipulation to the client? If the string operations are the bottleneck, rather than reading from the database, you could serve up XML, compressed XML, JSON, or CSV to the client. The text sent to the client would represent all the data needed to render the page, perhaps a straight forward copy of whatever you are selecting from the DB.

Then on the client side use either an XSLT or JavaScript to generate the HTML needed for the page or directly manipulate the DOM tree.

Personally, I prefer the XML/XSLT approach since it so cleanly separates content from presentation. But there are lots of options. I've never had performance problems using any of the methods above even for relatively large datasets, 1000 records. Well, that's large for a web page that is.

The server shouldn't have to do any string operations using this approach since even things like whether or not to display the Like/Dislike and the number next to it, are just properties inside whatever you send to the client.

W3Schools has an excellent tutorial on XSLT including client-side XSLT, as well as all the other web frameworks.

Ah, forgot to mention, but whatever method you decide to play around with, I'd implement it so that the server only uses the new way if the URL has a parameter like "test=yes".

That way you and others can test it out without affecting anyone else.