AJAX is an acronym dreamed up by some dude. It expands to "Asynchronous Javascript and XML", which are 2 concepts which have been around roughly since Netscape was relevant and 1 other concept that has been around forever. Just shows that coming up with a memorable new name at the right time can cause a lot of people to start using it.

Anyway, I wrote a chat room. Like all chat rooms, it has asynchronous aspects to it. It happens to use Javascript. Not only that, in order to work around some ridiculous inconsistencies in the XMLHttpRequest object, I was forced to even use XML.

While writing the chat room, I've noticed a pattern. I don't mean pattern in the sense of "Design Pattern" -- the word that so many people seem to be misusing and otherwise abusing these days, but just the normal generic "pattern". Code that needs to be written (in my case in PHP) on the server also needs to be written in Javascript and made available to the browser. As a means of explanation, let me describe a few concrete examples from my chat application:

Example 1: I am using a slightly modified version of this lib_filter library to filter out potentially annoying, broken, or otherwise malicious HTML tags and elements before they appear on the screens of other chatroom inhabitants. Since anybody can send whatever HTTP requests they want directly to the server, this filter needs to be run in the server. However, the chat room also features a preview field. While it would be possible for the server to continuously filter the user's message as they were typing it, a better solution would be if the same filtering logic were available in javascript so that the browser could filter the text in exactly the same way, without using any bandwidth at all.

Example 2: I replace textual "emoticons" like "=)" or "=(" with an image. The replacement code needs to be implemented on the server so that when you first load the chatroom page (with or without javascript), the smileys are there as images. However, the replacement code also needs to be run on the client when new messages are downloaded from the server. The alternative is to replace the smileys in the new messages before they are sent to the browser, but my way saves bandwidth, which is going to be a big problem in any current-day Javascript chat room.

I remember reading somewhere that Netscape's web server (back when there was a Netscape) allowed you to write your page-generation code in Javascript. This suggests a reasonably good path-of-least-resistance-way to deal with this "problem" that I'm having:

1) Write a big, standard, library for Javascript that duplicates all of (say) PHP's useful functionality, including string manipulation, database connection, cookie and session handling and whatnot.
2) Create and standardize a small extension to the Javascript language that looks like PHP, or ASP, or JSP. <?JSSP /* javascript code goes here */ ?>. Include in these extensions a few meta-directives like "include". For the next few paragraphs, let's call this extension "JSSP"
3) Make an Apache module that parses and runs JSSP in-process, like the PHP module does.

Now I can write Javascript code that gets included into my JSSP pages, and also included into my HTML documents in the normal way. Modifying the code modifies both the server logic and the logic used by the browser at the same time.

There's probably things out there that already do this or similar things. Feel free to write a comment if that's the case. I just haven't bothered searching google yet.