See the Known Limitations section for currently known Jaxer limitations.

Here are some thoughts:

• Write your entire app or site in one consistent paradigm: Ajax.
• Or keep your server-side business logic in Java, PHP, Ruby, etc. and write your presentation layer entirely in Ajax — without exposing your back-end APIs to the web.
• Use the same code or Ajax library to prepare your page on the server and later refresh its contents on the browser.
• Use the same validation logic on the server (for security) and the browser (for interactivity) so they can never get out of sync.
• Access databases, the filesystem, and sockets and protocols (e.g. smtp and xhr) across domains.
• Call server-side JavaScript directly from the browser as if it were client-side — Jaxer makes data wrapping and remote invocation transparent.
• Compensate for limited browsers by running the page on the server and serving the static HTML.
• Overlay Jaxer on top of any other web platform: post-process existing web pages to add functionality without altering their source.

But really, you, the Jaxer community, will come up with the best examples of where Jaxer can be taken!

Jaxer works with a web server to process and serve web content and respond to callback requests. At a very high level:

1. Jaxer reads and executes the HTML and the JavaScript designated to run on the server;
2. It sends the processed page as HTML to the browser, which reads and executes the processed HTML and JavaScript;
3. The browser JavaScript can then call back the JavaScript functions left on the server.

Of course there's a lot more to it than this... for an in-depth look, see the Jaxer architecture page.

Getting and running Jaxer is a snap:

1. Either grab a copy of the latest Aptana Studio, and click the Jaxer button to turn it on, or...
2. Download the self-contained Jaxer package for your operating system and fire it up — it comes with its own web server and database, and no installation is necessary. You can also view walkthroughs with screenshots for Windows and Mac OS X.

Jaxer is free and open-source. Enterprise and professional editions are coming soon, but Jaxer (community edition) will remain free and open source.

Read more about Jaxer on this site, or use Aptana Studio with its built-in Jaxer content assist, API, and help documentation.

Jaxer and GWT both address the question of how to unify the development paradigms across client and server. But they take very different approaches, at least to the UI part of web applications. GWT appeals to developers who would rather not write HTML or JavaScript at all, and instead have it generated automatically from their Java code. With GWT the developer writes server Java code for to describe the UI, and GWT autogenerates it. Jaxer appeals to those who want to write the HTML and JavaScript themselves, use any combination of Ajax libraries, and be in complete control of what appears on the user's browser. With Jaxer the developer writes the UI as they desire, in the familiar Ajax way, and designate certain parts to run on the server.

With GWT you end up writing pure Java for your entire application, except if you want to take more control of your UI than what GWT offers for you out of the box, in which case you end up mixing Java, HTML, and JavaScript, and you're back to the issues Jaxer and GWT were trying to solve.

With Jaxer you end up writing pure Ajax (HTML and JavaScript and CSS) for your entire application, except if you want the back-end of the application to be in Java (or some other language). But Jaxer will natively support connectivity to Java and other languages, beyond the network-layer (web services) integration already in Jaxer beta. So you will be able to keep your entire presentation layer in a single paradigm — Ajax — and have your business logic layer in Java. And since the interface between them will be on the server, you will not be forced to expose your Java APIs as web services on the public internet.

No.

We realized from the beginning that to really solve the problems we were tackling — making Ajax development seamless on client and server — we would need full Ajax capabilities on the server, as well as transparent calling of server-side functions from the browser. That requires a full web engine on the server side: a world-class HTML, JavaScript, and CSS parser, DOM engine, JavaScript interpreter and runtime, all fully integrated with each other, extensible, and with a large, established, and active developer community to guarantee a long life. We chose the Mozilla engine that powers the Firefox browser, and enhanced it with what any industrial-strength server needs. But we kept three principles at the forefront: it needed to be super easy to understand and use; it needed to feel like an Ajax platform, with familiar HTML/DOM and JavaScript conventions; and it needed to be extremely extensible using only Ajax (no C/C++ or even XPCOM needed in many cases).

So if all you want to do is run JavaScript on the server, of course you can do that easily with Jaxer, and you can do that with various Rhino-based and other platforms too. But if you need to manipulate the HTML DOM on the server, if you want to use an Ajax library there, if you want to call server-side JavaScript from the browser as easily as you call browser-side JavaScript, etc. — then you need a true Ajax server.

For many Ajax developers, who are already doing great things with JavaScript, HTML, and CSS on the browser, the prospects of doing everything that way, even on the server side, is very appealing.

But Java, PHP, Ruby, and other server-side platforms have tremendous established bases, strong developer communities, and powerful tools to make them compelling environments for back-end development. And indeed the vast majority of modern web applications use one of these platforms for their back-end layer.

The front-end of all these applications is almost invariably HTML, JavaScript, and CSS, because that's the common denominator of the browsers users use to access these applications. So Ajax technologies are almost inevitable — the only question is where is the boundary between Ajax technologies and the back-end platform. Usually, the answer is the internet: Ajax runs on the browser, the back-end runs on the server, and something serves as the presentation layer to bridge them. What is that something? We think it makes a lot of sense for that something to be Ajax itself: that way, the entire presentation layer can be in one paradigm, and it can interface cleanly to the back-end layer through established APIs architected for logical information flow across layers and not for public internet security or user-interface concerns.

Jaxer extends Ajax to the server to allow a single paradigm for the entire presentation layer, and furthermore makes client-to-server calling trivial, so the presentation layer can focus on the user interaction and not on low-level communications between browser and server. Jaxer already supports interfacing with back-end platforms via web service calls, and will soon offer native connectivity too.

The original and still prevalent interaction between browsers and web servers is a (more or less) stateless request from the browser followed by a response from the server, and that's it. With the addition of XMLHttpRequest (or similar mechanisms) to allow request-response communications without refreshing the page, Remote Procedure Calls (RPC) are very natural to implement, and now Jaxer makes them downright trivial: a client-side function can simply call a server-side function that's been designated with the "proxy" flag, as easily as calling another client-side function. Since in many cases the user interface is driven by user interaction events on the client, it's often sufficient to have client-server communications initiated from the client.

But there is also value in some cases for server-initiated communications, e.g. when the server has updated data, say in a collaborative application where the server coordinates interactions between users. Such "server push" functionality can be achieved by polling the server for new information, or by relying on long-lived HTTP connections between the browser and the web server ("Comet") . Jaxer easily supports polling models (e.g. see the Jaxer sample "Chat" which uses a very simple polling loop), while support for Comet is being investigated.

On the server side, Jaxer runs with full privileges, so it's not restricted from interacting with other domains. And on the browser side, accessing the server side is really, really easy. Put them together and you have a solution to the common cross-domain Ajax problem, that is, the restriction that browser code only make web requests within its own domain.

In Jaxer, the simplest solution is a single-line function, get(url), that makes the request and returns the results. Of course it can be dressed up to do a lot more. In any case, the rest of the sample is window dressing: <html> <head> <title>Cross-Domain Ajax Made Easy</title> </head> <body> <h3>Cross-Domain Ajax Made Easy</h3> <script runat="server-proxy"> function get(url) { return Jaxer.Web.get(url, {as: "text"}); } </script> <script> function $(id) { return document.getElementById(id); } function display(contents) { $('display').value = contents; } </script> URL: http://<input type="text" id="url" value="www.google.com"> <button onclick="getAsync(display, 'http://' + $('url').value)">Get it!</button> <br> <textarea id="display" rows="30" cols="100"></textarea> </body> </html>
Click to see what it looks like in a browser:

Please see the Jaxer Security page. We will soon provide many more discussions about this critical topic, as well as best practices and expert opinions.

Jaxer currently runs on all recent Windows operating systems (including Vista) and on Mac OS X (10.4.9 and up, on both Intel and PowerPC architectures).

Linux support is almost here — we know that will be the deployment target of choice for many developers and IT shops.

Jaxer works alongside a web server to process content. Today, it can work with Apache 2.x using the mod_jaxer Apache module bundled with Jaxer. It can also already work with Java-based web server Jetty, using the jaxer filter servlet now packaged with Studio and soon to be available standalone. It also works with Tomcat (details coming soon) and will be compatible with other Java web and application servers. We'll be working to expand the range of servers with which Jaxer works closely: to Apache 1.3, to IIS, and to others. If you'd like to get involved in accelerating the pace of Jaxer connectivity, please let us know — that's the beauty of open source.

If you're using the Jaxer in Studio, the regular Studio update process will let you know there's a newer version of Studio, and you can update it directly.

If you're using the standalone Jaxer Package...

1. First stop Jaxer if it's running.
2. Then simply delete the jaxer folder in your Jaxer Package (or JaxerPackage) folder.
3. Finally, download Jaxer_update.zip and unzip it into your Jaxer Package (or JaxerPackage) folder, creating a new jaxer folder.

All your data and settings will be preserved, because they're not in that jaxer folder. (You did put all your local settings in the local_jaxer folder, right?)