Aptana releases Jaxer, Ajax server built on Mozilla
Date : 2008 01 22 Category : Tech & Development
Ajaxian
Aptana has been known for its Eclipse based Ajax IDE Aptana Studio. Paul Colton, CEO, has impressed us at The Ajax Experience as he has shown of Studio, and how Aptana is fast to adapt and come out with support for iPhone development, Adobe AIR, and more.
But today Aptana is breaking out of the IDE world, and joining the server market with the release of Jaxer, which they are calling an "Ajax Server". Jaxer brings JavaScript, the DOM, HTML, CSS, to the server as it tries to unify the development model for developers.
You can think of the server as a Mozilla version of Tomcat. It plugs nicely into Apache (and more in the future), and handles the web application requests for you.
An example: validation
One solid way to understand Jaxer is to look at an example such as validation (screencast). Wouldn't it be nice to be able to reuse your validation logic on the client and the server? This example shows you how you do just that:
Part 1: Server Proxy
This code shows you how to use runat="server-proxy" to wrap that code in a way that the client can call it, but it gets seamlessly ran on the server:
PLAIN TEXT HTML:<script runat="server-proxy"> // Set the value of the input field 'name' // to the initial value document.getElementById("name").value = Jaxer.File.read("name.txt") || "A Long Entry"; // Function to save the value to a file // once validated function saveToFile(value) { validate(value); Jaxer.File.write("name.txt", value); return new Date(); } </script>
Part 2: Share code with 'both'
Then you write a simple validator that can be run on both client and server:
PLAIN TEXT HTML:<script runat="both"> // Use the same function to validate on the browser // for user feedback and on the server for security function validate(name) { if (name.length> 5) throw new Error("'" + name + "' exceeds 5 characters!"); } </script>
Part 3: Client side script
Finally you have the client side code that calls in:
PLAIN TEXT HTML:<script> // Browser-side script function save(){ // Runs when user clicks save var name = document.getElementById("name").value; try { // Validate in browser, if successful // save on server validate(name); // Call server-side function 'saveToFile' // and get return value var savedDate = saveToFile(name); // Update the confirm DIV browser-side document.getElementById("confirm").innerHTML = "Saved on " + savedDate; } catch (e) { alert(e.message); } // Show any errors to the user } </script>
This is the tip of the iceberg. There are other examples available as part of the download, and as screencasts.
What does this mean?
If you don't like context switching between the Web world of HTML/CSS/JS/DOM (Ajax) and the server side language of your choice, then this could be the programming model for you.
Unobtrusive Ajax
There are some interesting benefits, such as the ability to do a good job with certain accessibility without much work. If the browser doesn't have JavaScript turned on, the server can run the code and produce the HTML for you. Obviously, the HTML interface that is returned would be less dynamic.
The execution flow looks like this:
Prototype/jQuery/Dojo/... on the server
You can use your client-side library of choice on the server (e.g. Prototype, Dojo, jQuery, etc). My screencast below in fact does just that. The aim isn't to create a totally new programming model, but to rather be part of the Web. That being said, they had to add a set of libraries to allow you to do things on the server that you can't on the client. For example, the file reading in the example above: Jaxer.File.read("name.txt").
Databases
To build server side Web applications you normally need to persist data. Database access is provided via Jaxer.DB.*, and SQLite is built in. As soon as I saw this, I pictured a wrapper for Jaxer that would bridge the Google Gears database API. There is the ability to build some simple syncing, and have the framework do the right thing depending on if you are offline or online, and shifting data between the local and remote SQLite database. Very promising.
Cross domain XHR
Since you can have XHR calls which are really coming from the server, you can talk to any domain. Again, in my example, I proxy through to Twitter, which allows me to do a Greasemonkey type solution that works in all browsers.
JavaScript 1.8
Since the latest Spidermonkey is available on the server, you can write JavaScript 1.8 using new features such as expression closures, generators, and more. You have to be careful here and remember that this will only work for code ONLY running on the server. For all other code, you have to do the usual thing and test it with the various browsers that matter to you.
Rails for JavaScript?
I hope that we do not see a lot of huge pages with runat="server" all over the shop. We did that in the ASP/PHP/JSP of old. I am sure that frameworks will pop up to do MVC nicely with Jaxer. One option would be having Jaxer work nicely with projects such as Trimpath Junction and the project that Steve Yegge often talks about.... which is Rails-like but for JavaScript (using Rhino). Integration will also be an issue for a certain class of applications. I can imagine there being a particularly strong connection for something like Java.
IDE independence
Although Aptana Studio has top notch support for Jaxer (it better!), the product does not depend on any IDE and you are free to use it with anything. To show this, I use the stand alone Jaxer server and write my code using vi.
In fact, let's check out the video that builds a Twitter proxy in a few lines of code, showing how the beast works.
(I recommend watching the video at Vimeo to make a larger window to see the type).