Jaxer is a "Javascript on the server" solution that allows for programmers to write the code on the server as if they were writing on the client. This allows for programmers to spend more of their time working on client code as the server is designed to automatically keep up with them and their changes as you work on your application.

How it Works

On the architexture side, Jaxer is distributed as an Apache module. Though the module is hook-in to Apache to use Apache as the file server. Jaxer's main process is called Jaxer Manager which manages the different Jaxer processed and managed sending requests to and from the web server. We've written a compatibiulity layer that allows you to use Nodejs as a front end web server and have Jaxer act as the application server.

How Jaxer works is the Jaxer Manager process will spawn multiple Jaxer processes. When the Jaxer Manager process recieves a request, it will pass it to one of the Jaxer processes to be handled. The Jaxer processes are escentially a SpiderMonkey interpretter that is allowed to execute functions on the system with xpcom. In fact most of the source code is based off Mozilla's Firefox and adopted in a way to act as a server process.

When Jaxer first receives an http request, it will check the html file for any script tags defined with a tag with the value of "runat='server'" or "runat='server-proxy'". Runat server scripts are intended to be executed only on the server and not be visible to the client. With respect to 'server-proxy' scripts, Jaxer will automatically include an ajax-library along with the request with predefined callbacks to the 'server-proxy' functions. Both of these are cached and stored as byte-code on the server.

On the client, all of the available 'server-proxy' functions on the server will have pre-defined callbacks in the included ajax libary. This allows for functions on the server to be called as if they were on the client. The Jaxer ajax library will take the arguments, parse them as JSON, send them to the server as a JSON string, where the server will find which page is being called, locate the correct bytecode for the request and pass in the client parameters as arguments into the server-defined function. When the server defined function returns a value, it will automatically be serialized and returned to the client.


Benjamin Collins from WSD gave a talk at OSSAJ to provide background into the work that WSD has been working on to maintain and improve on the codebase that was left over from Aptana. We are working to create a one-script install , removing unused features, and support for the Raspberry Pi.

More Information: http://jaxer.wsd.co.jp