John Resig posted yesterday about his experiments with creating a full Javascript/DOM pseudo-browser environment that runs from the command line:
This weekend I took a big step in upping the ante for JavaScript as a Language. At some point last Friday evening I started coding and didn’t stop until sometime mid-Monday. The result is a good-enough browser/DOM environment, written in JavaScript, that runs on top of Rhino; capable of running jQuery, Prototype, and MochiKit (at the very least).
The really nice touch is that you can issue PUT and DELETE requests on the XMLHttpRequest object to manipulate files on the local file system! Here’s an example script that scrapes post titles from alistapart.com and stores them in a file (remember, this runs on the server like a shell script):
load("env.js");
window.location = "http://alistapart.com/";
window.onload = function(){
load("dist/jquery.js");
var str = "Newest A List Apart Posts:n";
$("h4.title").each(function(){
str += " - " + this.textContent + "n";
});
var out = new XMLHttpRequest();
out.open("PUT", "file:/tmp/alist.txt");
out.send( str );
};
Search friendly AJAX
When you load a content-empty HTML shell and fill it on the browser side with content from an XML source, you end up with a page that is essentially invisible to search engines. One workaround for this, short of having all page requests load full HTML, is to pre-render content to the page on the server side. Any content refreshing or manipulation can still be done on the client side via AJAX.
The problem with this method is that you have one code base that renders your pages on the server side, and then another Javascript code base that essentially performs the same function on the client side. It’s twice the work. Twice the bug fixing too.
Imagine extending this server-side Javascript proof of concept into a general architecture for dynamic, AJAX-style sites. There’s no reason why you couldn’t use a Javascript library to pre-render pages as they are served and then use that exact same code to update page content on the client side.
Take this dual mode Javascript concept further and you could give all your dynamic anchor tags an href=”url.html” as well as an onclick=”loadFoo(‘url.xml’)”. Javascript compatable browsers can benefit from the AJAX UI features, while search engines can still navigate your documents appropriately.
Automated Testing
The other nice feature that John’s hack provides is a mechanism for easily testing and debugging your Javascript code. You can code your unit tests in Javascript while writing your web apps and easily execute them against your software, just as a traditional development process would have a “make test” (or equivalent) procedure.
Other Ideas
Some other applications immediately come to mind, the most obvious being search. A robust Javascript/DOM environment added to the crawl process could make a lot of previously inaccessible content suddenly more easy for a search bot to digest.
Have any ideas or immediate uses for server-side AJAX? Give us a shout in the comments!
Bringing the Browser to the Server – Link
ADVERTISEMENT
