Looking back over previous nodes (Perlmonks AJAX Voting
, AJAX replacement for voting buttons
, AJAX-based Perlmonks.com?
), I've seen that in the past there's been resistance to the idea of using AJAX on the site. Objections usually amount to the following (and approximately in this order):
- We don't need it - the desire to use AJAX derives from a misguided wish to use the newest fad.
- It will increase server load - Because we'll be hitting the server more often(?)
Before discussing this last point, I have to address the first two. So, first of all, this write-up is not about using AJAX because it's cool, or because it'd make the site seem more modern, or even to improve usability (although IMHO that might be a good reason). I'd like to discuss it here only because it might be possible to use it to reduce server load.
So, that having been said, the main reason previous AJAX additions could increase server load is simply because the server doesn't have support for them. That is, most of these AJAX requests are going to force a complete page re-load in the background, where it's not even visible to the user. But if the server were set up to expect and handle AJAX requests differently, it could be streamlined to simply do the minimal amount of work necessary for this request, and only send a small amount of data back as acknowledgement, rather than rendering the user's entire site view. I am not a pmdev by any means, but isn't this at least possible?
Here are some areas which I think could benefit from the use of AJAX, if the server could handle them in a streamlined fashion (which is to say, by doing less processing and returning less data than a full page reload):
- Voting - Obviously, this has come up before. I think that in particular, if the server were to only send back raw data on the reputation of the nodes on which you've voted, and updated XP information, it could be doing a lot less work than it is now to process votes. After all, when you vote that's the only new information you receive (besides updates to your other nodelets), and yet the server still renders the entire site view. The simplest solution wouldn't even involve an interface change, simply overriding the listener on the "vote!" button to do the work, and if JS isn't there, it works as before.
- Drilling deeper into threads - Currently I have my display depth set to 10, because I hate to have to click on deeper nodes to view threads in depth. It should be possible to drill down into threads by retrieving only the node which you want to see, and inserting it into your current view, rather than rendering the entire page again. If this were available, I could decrease my depth to 2 and only drill into threads I want to read.
- Editing Previews - Again, simply render the preview and return it, rather than a full page load.
- Chatterbox - As far as I can tell, support for this is already there, since the chatterbox sidebar does pretty much the same thing as the free nodelet hack posted earlier. The good thing here is that the sidebar already renders a limited view, rather than a full page load, which means that (hopefully) the AJAX-enabled CB is not bogging down the server as much as clicking "talk" to refresh would do. Of course, it happens more often, but the sidebar does that too. However, since I don't know the server-side details, maybe there is room for improvement here.
- New Answer Notification - Okay, I don't know if this would help or not as it depends on how people behave. I know that personally I like to re-load the original thread after I write a response to see if somebody has beaten me to the same answer, to avoid giving redundant (or perhaps wrong!) information. Rather than re-loading the entire original thread in a full site view, again it should be possible for me to check whether new responses exist (a trivial amount of data), and then if they do only return the content of those notes (a smaller amount of data than a full load).
In the end all of these suggestions potential to reduce site load depends on the answer to this question: Which requires the most work for the server, receiving and authorizing incoming requests, or retrieving and rendering all the nodes from the database necessary for a pull-page view?
. If it's the former, then these suggestions are a bad idea, since they all require authorization. If it's the latter, then these suggestions could
help, by reducing the amount of node rendering the server has to do for these common activities.
Let me conclude by reiterating: This is just a proposal to get feedback, I am not a pmdev
, and I don't think we should use AJAX just because it's cool. I'd just like to discuss whether it could actually help with the existing concern of server load or not.