AJAX-based Perlmonks.com?

[hackdaddy]

After experimenting with CGI::Ajax, I'm wondering if Perlmonks.com would consider AJAX for the web site?

What would be the pros and cons?

Thanks.

[talexb]

OK, I'll bite.

Pros	Cons
Cooler web site	More code to maintain Higher load on the server Can Perlmonks really benefit from the application of this fairly new technology? Does this limit the browsers capable of viewing Perlmonks?

It's 0450 local time -- so my reasoning may not be 100% -- but that's the list that I was able to come up with.

[ChemBoy]

I'm not sure I agree with any of your cons except the "More code to maintain", actually.

More code to maintain

Yes, certainly, though the most obvious applications would be pretty easy to keep decoupled from the main body of the Everything code (since they'd be Javascript—I doubt very much would need to be changed on the server side).

Higher load on the server

I simply don't see it. Certainly if you made every page reload the chatterbox at a fixed interval, it would probably increase the load—but why would you do that? There are plenty of ways to use XMLHTTPRequest without using setInterval, and most of them decrease the load, since actions that change one 15-character span (or, in the case of the chatterbox, one 10-line table cell) wouldn't force a reload of the entire page.

Can Perlmonks really benefit?

A valid question, certainly. I think it could, though whether the benefits outweigh the maintenance and security auditing costs is a question worth asking. Calling it a "con" in an initial evaluation seems to me to be prejudging the situation, though.

Does this limit the browsers capable of viewing Perlmonks?

I don't think it would have to, if implemented right. Let me make that more explicit, actually: under no circumstances would I consider it a good idea to add AJAX capability as a requirement for viewing any part of the site. Simply a terrible idea, and you're absolutely right to raise the point. But the kinds of functionality that other monks have mentioned as possibilities elsewhere in this thread already exist in standard-HTML form (no pun intended): unless very broken code or very broken browsers got involved, that functionality would be silently replaced with the JS-based implementation when (and only when) the browser being used had the necessary functions enabled.

All of that leaves aside the question of whether it should be done: if the benefits (which so far are largely minor convenience upgrades and a possible trivial server-load reduction) don't balance or outweigh the costs in code complexity and maintenance hassle, then the idea is a non-starter. That said, there seem to be a number of monks with some interest in the topic—if a few of those are both pmdevils and familiar with the problem domain, we could probably at least investigate the idea, and try to get a solid answer to that question.

[Your Mother]

It would probably cause more problems than it would fix but a couple things it would help with: chatterbox and voting. Like on Yahoo and Amazon, you could vote silently. Vote and the radio buttons disappear. The vote is counted on the server side but the page isn't necessarily reloaded. Better user experience. Chatterbox could be remotely refreshed every time there is a new "talk."

Problem is, the site is already sluggish most of the time, so the apparent savings would probably just be shunted off to higher loads from talking back and forth with clients; gains would vanish whenever you actually did request a full new page. Plus, it's just not very "Monk-ish" and there are quite a few JSphobes here.

[b10m]

You -unfortunately, like many others- seem to follow hypes to extremes. Rather than saying "We need to change some functionallity and AJAX seems to fit in nice", you say "AJAX looks cool, now we only need to find functionallity for it".

Rather asking what the pros and cons are, you could suggest why this would be good to begin with. I see very little use for AJAX on perlmonks. With a pimp-my-site project to replace all functionallity with AJAX stuff, I can't browse perlmonks from my Xbox (using LinksBoks), nor from my command line (using Links) anymore.

So, where exactly would you like to put AJAX support and why would it be better to what there already is? When you have that straight, we can agree or (most likely) disagree with your proposals.

[thor]

So, where exactly would you like to put AJAX support and why would it be better to what there already is? When you have that straight, we can agree or (most likely) disagree with your proposals.

I don't know about the OP, but three places where it would be apparent to me are the chatterbox, voting, and moderation. I've always thought it odd (and probably expensive) that all three actions required a full refresh of the page to do what amounts to a tiny change in the output.

[Corion]

The chatterbox will never be Ajax-based for two reasons. First, Pair.com does not allow "chat servers" in its terms of use. The CB already is on the very border of that in my opionion. Second, the server load would multiply if every page that a browser has open on Perlmonks would reload all the time. I usually have two or three pages open, but when starting the day, I open at least all new root nodes in separate tabs - the load inflicted on Perlmonks by a constantly refreshing CB would be huge and the gain miniscule.

[Happy-the-monk]

expensive that all three actions required a full refresh of the page

I once thought the same and wouldn't it be nice if you could click your votes, moderation and type your cb-message and hit any of the buttons to make all three actions happen? That could be made possible.

Judging it as a programmer - I don't need that bad enough to volunteer to code it. Actually, I only very scarcely need more than one of the options at any time.

Cheers, Sören

[bart]

It would require Javascript enabled for this site. That's a requirement the gods are pretty much opposed to it, at least, as long as a user can put any Javascript on his home node.

[Juerd]

The most apparent con is that it would make the site depend on Javascript, something the text browser I regularly use doesn't understand.

perlmonks.com AJAX based is fine with me, but please don't touch perlmonks.org in a similar fashion :)

Update: I am aware that .com and .org are the same site, but I always use .org because of the cookie, so I wouldn't mind if .com were to be used for a different, for example AJAX based, site :)

[castaway]

For the record (and in case others are confused), (www)?perlmonks.(com|org|net) are all the same site.

C.

[japhy]

But I'd think it'd be possible to make the code that operates the perlmonks.* web site do one set of behaviors if it's perlmonks.org, and another set if it's perlmonks.com, and another set if it's perlmonks.net. I'm not saying that's a GREAT idea, I'm just saying it's possible.

[Mutant]

I think most interactive sites can benefit from some use of AJAX, with the following caveats:
• There must be some way to degrade gracefully, or to turn on/off AJAX features.
• There must be a clear benefit to the enhancement. There are a million things AJAX can be used for, but only a few of those are actually useful, and don't over-complicate either the interface or the underlying code.
• Server load should be considered.
I'd love to have 'asynchronous' node voting. It's annoying to have to click each node you want to vote on, scroll to the bottom, then click 'Vote' (sometimes I forget to actually submit the form when reading a long thread).

This case might also actually reduce server load, since the node will only have to be generated once (not twice as is currently the case). Of course, there will potentially be a greater number of requests to vote, but I'm assuming this would be a lesser load than the double page generation.

To help those with less standard browsers (AJAX works pretty well on all the main browsers, including Konquerer and Opera), this feature could be a user settting.

[Juerd]

I'd love to have 'asynchronous' node voting. It's annoying to have to click each node you want to vote on, scroll to the bottom, then click 'Vote' (sometimes I forget to actually submit the form when reading a long thread).

That's a great idea, and easy to implement in a well degrading way. Add a button and a small iframe next to the voting buttons, and make that load the reputation display when the user has voted. Some Javascript could be used to hide the vote buttons (don't put THOSE in the frame!), but it would still work well without.

Things like this I started using years ago, before anyone had invented the name AJAX for it, and long before XML and Javascript were considered required for something to be cool.

[b10m]

I'd love to have 'asynchronous' node voting. It's annoying to have to click each node you want to vote on, scroll to the bottom, then click 'Vote' (sometimes I forget to actually submit the form when reading a long thread)

I read long threads entirely different. When I feel like voting on a node, I check the appropriate radio button. Then I go to the next node. When I'm done with the thread, I hit the vote button. Now my -maybe- 10 votes will be handled at once, thus less bandwidth than 10 asynchronous request on the server.

[gregor42]

10 votes will be handled at once, thus less bandwidth than 10 asynchronous request on the server.

Just to pick nits - you'd be reducing the number of transactions, but not necessarily the bandwidth requirements. You still are reloading all of the content for those 10 nodes every time you submit votes. Asynchronous requests would only send the vote information & (user id, node id, vote type) and receive confirmation information (current reputation tally for node).

Adding up all that data you still have less bandwith required in total.

AJAX excels in reducing bandwidth when you do things like this - decoupling functionality from content and only sending page updates rather than the entire page. Yes, you might increase the number of transactions, but you are making their function more granular and thus simpler to process with less overall generated network traffic.

[andyford]

I do this too, but I often lose track of how many times I've voted. The instant AJAX feedback on voting would help in that regard.

[tirwhan]

Given that I just had a hell of a time trying to work with §%&/$ing googlegroups with a slightly non-standard setup, I'd be against such a move. What do you want to do that you can't do already? As far as I can see the pmdevs already have their hands full with site maintenance and adding another technique which requires per-browser tweaking is a bad idea IMO.

[kulls]

We can implement in super search section alone for better performance and we will make it like this .
-kulls

[ForgotPasswordAgain]

Why do we need these "AJAX" hacks in the first place? Because HTTP is too primitive. Clearly perlmonks needs to be reimplemented as a video game! We could build like a Second Life community. Come on!