Aptana's Jaxer Server

A couple weeks ago Aptana released "Jaxer: The Ajax Server" as with most new products (I am a technology junky) I was interested to find things I could do with it. So I started to dig into it. The product installed when I upgraded to the latest version of the Aptana IDE, sweet server installation and running is usually hard. Being new, there wasn't to much documentation but more that I expected and I was able to play with the product quite easily.

When I look at any new product I usually evaluate along the following items:

• Problems I have
• Things I can do with it
• Things I want to do with it

But, before I can even start with the list above, I need to figure the list below first.

• What does it do?
• How does it work?
• Where does it fit in the application development stack?
• What unique features does it have?
• What are its limitations?

I am no expert in the product, I have just begun looking into it but you need to start somewhere. So let me run through my findings thus far.

What does it do?

Jaxer givers developers the ability to use JavaScript on the server to access a HTML DOM model of a Webpage before it is sent to the client. Jaxer also gives developers a set of API's that can connect to databases, do remote connects, access files and other web framework stuff.

How does it work?

Jaxer embeds the Mozilla engine so it can process the HTML page before it is shipped off to the client. Developers add script tags to their HTML page, "<script runat="server | both | server-proxy"/>. When the server parses the HTML it will execute JavaScript designated to the be run on the server. Check out this page for an overview of the architecture.

Where does it fit in the application development stack?

This is a tricky one... Jaxer has many features of a web framework, but I am not sure if it is a replacement for things like; php, ruby, or Java frameworks... YET. The APIs are fairly robust but not as completed as the frameworks previously mentioned. Jaxer though can be integrated with Tomcat, Apache (mod_jaxer.so) so it can also "front-end" current infrastructure as well.

What unique features does it have?

Using JavaScript on the server isn't unique, neither is a server-side DOM model (JSF), but Jaxer is unique in the approach it takes to making development of Ajax application easier. The ability to use <script runat="server-proxy"/> and have the client automatically marshal the function call to the server, then be able to use the DOM APIs on the server, which will change the client is really cool. At Nexaweb we have this term "Distributed Model View Controller" that allows people to execute controller code on the client and server side. This is very similar. Being able to call controller code on the client or server seamless makes programing easier. Also changes to the server DOM effecting the client removes the need to transport data to the client just to synch.

The concept of pre-rendering and being able to change the HTML DOM before it is sent to the client is also really cool. I will use the term even though I don't like it "First-class" support for JavaScript on the server, makes it easy and seamless to use.

What are it's limitation, these are the things I see?

1.) The parsing of the HTML on the server will be problematic for sites that get heavy traffic. No matter how fast Mozilla is at parsing; do it for lots of pages will be slower than not parsing them. But hardware is cheap, put it on the Amazon EC2.

2.) You still need to have a web framework for some applications. Jaxer does have quite a few features, but it is still not as complete others.

3.) You only can use the JavaScript in the processing of HTML pages. I couldn't immediately find how to use JavaScript and APIs to work with an XML document in the same manner as a HTML document. I would like to be able to use JavaScript to pre-process a JSON or XML document before it is sent to the client.

What problems do I have?

I'll keep this centered around software and in particular web development. This isn't a bitch session, but the role of software is to solve problems, both technical and business. So I need to put together a list of problems I would like to solve:

• Web application security. Remember when perl.com changed into porn.com or listen to any talk by Douglas Crockford.
• Mashups, being able to easily pull together multiple sets of data and present them easily.
• My iPhone Problem. Even though the iPhone has "this part of the web and that part of the web", it's still a pain in the ass to view the web in the iPhone. I am always zooming and panning to view the content. It really sucks, especially if you have to laterally pan to read the content.
• Accessiblity - Think my iPhone problem is bad. Imagine having to zoom and pan every page you visit.
• Simplify development, the easier it is to create applications the better for everyone.
• Web application performance - As web pages become more rich the slower they become.
• Role-based access to content. Not so much of an issue with consumer sites but for enterprise developers people need to have access to only certain content, fields, and modifications.
• Personalized presentation, storing the state of an application when a user is finished and representing it to them the next time they accesses the application is an important part of any application. Ajax brings desktop richness but doesn't bring the desktop capabilities yet.
• Symentic Web - Not everyones think about it about it but it will be an important going forward. By the way, I am working on the Beta of Web 3.0
• Browser compatibility, old browsers - new browser, everyones different and coding around their idiosyncrasies is a pain to deal with on the client and results in more code and slower performance.
• The broken trust relationship of the web. All the widgets, JavaScript and cross-site XHR that directly access code from third part sites breaks the trust relationship of the web and causes perl.com to become porn.com or worse.
• Multi-device presentation - Today people access the web from many different devices; computer, iPhone, mobile device and each one has a different resolution, aspect ratio and capabilities.
• Offline access.

Well that's all I have off the top of my head. If you think of more or disagree, add a comment. I actually think that this pre-processing of the HTML like Jaxer does can help solve many of the issues I outlined. This is step one. Be able to solve the problem. There will always be more than one solution to a problem so the second question is "I would want to solve them this way". I think I would. The pre-processing of the HTML and giving the DOM to the developer would make things much easier.

Things I can do with it?

I am not going to run through all of the problems to show how Jaxer could solve them, but lets take Performance as an example. I have done lots of work documenting JavaScript Performance and building tools to find and fix the issues. Having the DOM on the server, I can find all the JavaScript included in a page, then compress and combine the files before sending the page it to the client. This would make deploying the application easier, the server could just do the compression and I wouldn't need a build step. You could to the same thing for; CSS files or make sprites from images. Again there is always multiple solutions to problems so it comes down to "Can I do it?" and "Would I want to do it?"

The same thing with security. I could check the HTML for and 3rd party JavaScript. Load the those script files and see what is going on and then possibly store a copy, if the file changes, flag it and notify a administrator. perl.com wouldn't be able to become porn.com.

Things I want to do with?

Jaxer would be a good way to solve many of the problems above. I need to dig more into but at first glance Jaxer has a unique place in the application development stack, people will definitely take advantage of it in the upcoming months.

Bob (Buffone)