How does Jaxer work? At a very high level:

1. Jaxer works closely with a web server to process and serve web content and respond to callback requests.
2. Jaxer reads HTML pages from the web server (Apache, Jetty, etc.) before they're sent to the browser, processes them, and returns the processed HTML to the web server, which forwards them to the browser — there are no proprietary XML formats or browser plug-ins needed, it's Ajax all the way.
3. Jaxer integrates the Mozilla engine — the industrial-strength engine that powers Firefox 3 — to provide rich, standards-based, well-tested parsing and APIs for HTML, CSS and JavaScript
4. To allow seamless calling of server-side JavaScript functions from the browser, Jaxer automatically injects a bit of JavaScript wrapper code into served pages. The actual server-side code remains securely on the server.
5. When you call a server-side JavaScript function from the browser, Jaxer wraps the function's name and arguments in a JSON string, sends them via an XMLHttpRequest back to Jaxer (via the web server), which unwraps the information, calls your server-side function, wraps the results back in JSON, and returns them to the browser, which unwraps them and passes them back as if the server-side function was running right in your browser.

Compared to a traditional web stack, Jaxer allows a much closer relationship between the client and server sides, because it offers a single, unified, and familiar development paradigm. You don't need to constantly switch contexts, wear multiple hats, and wrap and unwrap data and function calls. To paraphrase, "it's Ajax all the way down." You can apply Jaxer to your entire application (as shown below) or to your presentation layer, relying on Jaxer to unify the presentation logic on client and server and integrate on the back-end — where APIs are securely kept behind firewalls — with your existing systems.

More Details

Jaxer is pre-configured for use as a plug-in to the Apache 2.x web server, and it also supports the Jetty Java-based web server. Future versions will support other web servers, such as IIS. To provide world-class, standards-compliant JavaScript and DOM capabilities server-side, Jaxer is built on the Mozilla engine, which is the same engine used in the popular Firefox browser. Jaxer is layered into Apache as an input and output filter so that you can also use Jaxer to modify dynamic pages created by other languages, such as PHP or Ruby.

Jaxer Core vs. Framework

Jaxer itself is a combination of C/C++ "Core" code and a server-side JavaScript "Framework." The Core provides the JavaScript parser and runtime, HTML parser and DOM engine, and an event architecture that calls the Framework as the document is being processed on the server. The Framework provides the Jaxer logic itself, for example deciding which code to run on the server and which on the client, creating proxies on the client for callable server-side functions, serializing and deserializing data, and so on.

Because the Framework is written in JavaScript, it is easily extensible by Ajax developers. Jaxer is an open-source, free, and extensible platform for end-to-end Ajax development and for building rich presentation layers on top of existing back-end platforms.

Jaxer page lifecycle

Let's examine the lifecycle of a typical web page built with Jaxer:

1. The HTML document starts life on the server, either as a static HTML file read from disk, or as a dynamic page generated by PHP, Ruby, Java, etc.
2. Jaxer receives the document as an output (post-process) filter from the web server, and starts to parse and execute it, just as a browser would. Jaxer creates and populates the DOM, executes the JavaScript code designated to run on the server, and so on until the entire document is consumed.
3. The result is a DOM modified by the Framework and by the developer: in particular, proxies automatically replace server-side client-callable functions. Some important side effects include storing designated JavaScript functions as callbacks and persisting session-type data.
4. The new DOM is serialized as an HTML document and streamed out to the client as usual.
5. The client receives the HTML document and the processing continues, recreating the DOM from HTML and this time executing the client-side JavaScript left in the page.
6. When one of the client-side proxy functions is called, its parameters are automatically serialized into a JSON (JavaScript Object Notation) format, and an XMLHttpRequest is sent to the server to invoke the original function with these parameters.
7. When the server receives this special request, the parameters are deserialized, the function to be invoked is restored and called with these parameters, and the results (or any exception) are serialized back into JSON.
8. The data is returned to the client, where it is deserialized and returned as the result of the proxy (or a corresponding client-side exception is thrown).

On the server side, the developer's JavaScript environment is enhanced by the Jaxer Framework, which provides access to the database (SQLite or MySQL, with others coming), file system, network (from low-level sockets to high-level web service protocols), the HTTP Request and Response data, and in the future also direct integration with external server-side platforms such as Java, PHP, and Ruby.

Jaxer Page Flow (Non-Callback)

Jaxer Callback Flow