Tuesday, January 22nd, 2008

Aptana releases Jaxer, Ajax server built on Mozilla

Category: Ajax, Aptana, JavaScript, Library, Screencast, Server

Aptana Jaxer

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:

  1. <script runat="server-proxy">
  2.     // Set the value of the input field 'name'
  3.     // to the initial value
  4.     document.getElementById("name").value =
  5.         Jaxer.File.read("name.txt") || "A Long Entry";
  7.     // Function to save the value to a file
  8.     // once validated
  9.     function saveToFile(value) {
  10.         validate(value);
  11.         Jaxer.File.write("name.txt", value);
  12.         return new Date();
  13.     }
  14. </script>

Part 2: Share code with ‘both’

Then you write a simple validator that can be run on both client and server:

  1. <script runat="both">
  2.     // Use the same function to validate on the browser
  3.     // for user feedback and on the server for security
  4.     function validate(name) {
  5.         if (name.length > 5)
  6.             throw new Error("'" + name +
  7.                 "' exceeds 5 characters!");
  8.     }
  9. </script>

Part 3: Client side script

Finally you have the client side code that calls in:

  1. <script>
  2.     // Browser-side script
  3.     function save(){
  4.         // Runs when user clicks save
  5.         var name = document.getElementById("name").value;
  7.         try {
  8.             // Validate in browser, if successful
  9.             // save on server
  10.             validate(name);
  12.             // Call server-side function 'saveToFile'
  13.             // and get return value
  14.             var savedDate = saveToFile(name);
  16.             // Update the confirm DIV browser-side
  17.             document.getElementById("confirm").innerHTML =
  18.                 "Saved on " + savedDate;
  19.         }
  20.         catch (e) { alert(e.message); } // Show any errors to the user
  21.     }
  22. </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:

Jaxer Flow

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").


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).

Posted by Dion Almaer at 3:00 pm

4 rating from 63 votes


Comments feed TrackBack URI

Wow, this looks wonderful. It’s often annoying to find myself duplicating the same validation routine or what-not between the server and client.

Until now the closest thing I’ve seen is hAxe, but that’s a separate language that compiles to JS/SWF + its own server.

Looks like the Linux version is still forthcoming, and it does bundle Apache with the Mac OS X release vs. using what’s installed… I’m sure they have reasons for that. Taking a better look now.

Comment by nathany — January 22, 2008

Very impressed! Now will this be bought by google or microsoft? :)

A great step forward. Does it work with ASP.NET when calling a .asmx service though?

I like the fact no one has to learn yet another language and that we don’t depend on any server side specific components like asp.net grid or java displaytag. Just simple javascript, do what you like with it.

Once some type of collaboration with Trimpath type of project is in place for Javascript MVC like the author mentioned here, it will really be extra sweet.

Now is the time to re-think about web programming!

Comment by Liming — January 22, 2008

*Stunned*. I’ve toyed with Phobos before and Sling at the moment, to be able to use js on the server-side (of course Sling is its own db as well), but it’s very difficult not to come up with a paraphrase that’s fit for prime-time TV :).

I wonder how much fluff there’ll be in the generated pages. Hopefully not much. Argh! They should have begun with the Linux version.

Comment by peter svensson — January 22, 2008

OK, my alarms were going off when I saw write to server capability in javascript, but then I saw the “runat” script attribute. So will the client NEVER see the runat=”server” code in a view source?

Comment by Jigs — January 22, 2008

Indeed. It’s about time this sort of solution came along! :-). Noted that it is still beta, some of the jQuery compatibility tests fail and such. Play-ready, not quite production ready.

With SQLite support suggested in HTML 5, with planned support in Firefox 3, as well as the Google Gears and Adobe AIR solutions, it looks like a good offline/online database wrapper is needed. If everything is JavaScript/HTML/CSS, the move between offline/online web could potentially be a lot smoother. Yay. This is exciting!

Comment by nathany — January 22, 2008

@jigs, i don’t think so, or else it will reveal too much. I wonder though, what about code that have runat=”both”?

Took a look, their server side has application, session, request, response, page and all that, got the full stack there. Too bad, SQL server 2000/2005 and Oracle is not yet there. Somebody fund this company and get them to release these adapters!

API documentation is well done too. I wish though, they can write an adapter for IIS server to forward all .html request to Jaxer, or are the microsoft lovers like me not invited to the party?

Comment by Liming — January 22, 2008

Thanks for the in-depth review and the sample Twitter app, Dion. We’re all about community participation, so we really hope people come up with cool ways to apply Jaxer.

@nathany and @peter svennson, the Linux version just needs a bit more testing before we set it free, look for it very soon. We chose to bundle Apache even though OS X has it because we’d have had to ship multiple versions of mod_jaxer for various OS X platforms, and explain how to configure. Our aim was to ship a simple, self contained package you can just start up and go. We’ll be making those platform-specific mod_jaxer modules available soon for people who want to use their own Apache.

@Liming, we very much want to have you an dthe rest of the IIS community on board! We’ve already started working on the IIS adapter, and we’re thinking of how it should fit within various IIS flows (like the .asmx web service flow you mentioned). What are your thoughts?

@jigs and @Liming: runat=”server” (and “server-proxy and server-nocache”) indeed will disappear from the page before it’s sent to the client. The client will NEVER see that code unless you explicitly send it there, e.g. by making a script block or an individual function runat=”both” (or “both-…”, you get the idea) or “client”. Code you ask to run on both client and server will indeed be made available to both ;-).

And as for SQL Server, Oracle, and so many other integrations we’ve been dreaming about and are now starting to look at: we’re very much demand driven. Please come join us on our community forums, and let’s get the conversations going!

Comment by Uri — January 22, 2008

Nice, but it’s all been done before

Comment by Mikael Bergkvist — January 22, 2008

Ok, as soon as the IIS version comes out, I’d be all over this.. I just need to find a host now, lol. I wonder… how would the system behave if you set something like ExtJS to “both” and tried to run it on the server… does it build the dom extras it needs on the server side?

Comment by Jon Hartmann — January 22, 2008

“Everything has happened before and will happen again” – Old Cylon in BSG Razor

Yes and we called it classic ASP using JScript :-) Before that Netscape Livewire, etc.

Actually this is a good idea and is no different in some ways than pushing Java everywhere as GWT does but without the translation. Since browser languages are somewhat non-moveable it does spell some trouble for server languages that have a mismatch with JS, like strong typed -> weak typed.

Comment by Thomas Powell — January 22, 2008

only looking at this as ‘javascript’ on the server misses a big part of the coolness. It is really the DOM on the server that is the big innovation.

@thomas. never been able to code the app i want in only gwt, always end up in javascript land somewhere, same for rails and scriptaculous.
but you are right about the impedance caused by crossing the language boundary from server to client.

Comment by geekfreak — January 22, 2008

“It is really the DOM on the server that is the big innovation.”

Depends how you define ‘innovation’, we have used it for several years over at widgetplus.

Comment by Mikael Bergkvist — January 22, 2008

@Mikael: People have done JavaScript on the server before, but this is the first publicly consumable server-side JavaScript API that I have seen. You need the documentation, screencasts, pretty packaging and support from the big guys to really put fire under a project. The Aptana team has done a great job of that.

The fact that it can run in conjunction with Apache makes me excited. If they figure out how to get this to run side-by-side with other languages (like PHP) to leverage existing frameworks then I think this project could add to my career right out of the hopper. I would have the missing link for writing killer Ajax components on top of current applications.

@Dion: Thank you for the screencast.

Comment by iMarc — January 23, 2008

I hear you, and I respect what you say, I just want to make sure I got my point across right, and then I’ll be on my way. ;-)
First, I AM talking about running the DOM + CSS access on the serverside and not *only* JavaScript, second, widgetplus is also publically a consumable API, third, it’s also something that blends well with other languages.
The ‘support of the big guys’ part is a bit suspicious to me as an argument, since it usually just means ‘all markets belong to the existing big guys and everyone else is shut out’ and that’s just plain wrong.
However, I’m glad the approach gets further validation by the ‘big guys’, so that part is really cool.

Comment by Mikael Bergkvist — January 23, 2008

Just need to get it running using FastCGI…

Comment by Steve Roussey — January 23, 2008

I don’t understand why you would want to ever run javascript on the server side.

You can already do anything you want with PHP, ASP.NET, Ruby, C++ etc on the server side. You have no limitations. You have ultimate control over the HTML on the server.

Plus, Anything dynamic on the client still has to be done on the client, otherwise you end up with a postback, hence the entire reason for javascript and AJAX.


Comment by pennyfx54 — January 23, 2008

Hey anybody: performance?

When netscape server-side javascript was hyped, it proved to be slow as… [anything slower than a snail, or a statue]

10 years passed and what do we hear?

Javascript is good for the client, where it only has one instance (per application)… for the server… not surely.

It’s good tt o maintain only one language, but straight javascript isn’t necessarily the way… I prefer larger applications in javascript, with a JSON server backend (in anything)

Comment by Adam Nemeth — January 23, 2008

I’m also excited about Jaxter, but to me the whole discussion also throws a sharp light on Javascript as a language (think performance). I think it’s more than time JS comes of age, and leaves the confines of the browsers and the scripting-the-browser-and-HTML cliche. I think everything available (Seamonkey, Rhino, …) is not entirely convincing (with JScript maybe a notable exception). We want JIT compilation and the ability to spawn muliple interpreter instances – from within JS code. We want module support in the language and a threading API. We want native implementations on various platforms that conform to the language spec, network and file I/O and the ability to develop and test code ouside of browsers. I’m fine with restricting JS in the browser, reducing it to a ‘jslet’ type of platform. But I wish Brendan Eich would make the minimal provisions in the language to have all this infrastructure built upon. Which of the then possible enhancements will be implemented in or only outside the browser is left to another discussion.

Comment by Thomas Herchenroeder — January 24, 2008

It looks like every single Ajax framework vendor on the planet has commented here, so I feel I have to dive in ;)
(widget+, Qooxdoo etc)
There exists as you all say similar technologies, one is ours (Gaia Ajax Widgets) which can manipulate DOM on the server through building up the page using WebControls which are typed and compiled and sent to the client over XHR channel. The technology behind this thing is surely great, and the ability to only think about _one_ language when doing development of Ajax apps is brilliant, but to call this “new” is like calling sliced bread “new”…
Our samples at; http://ajaxwidgets.com/AllControlsSamples/ is for instance built 100% in C#, not ONE line of “Custom JavaScript” there…

Comment by polterguy — February 2, 2008

Jaxer is not the only kid on the block of “DOM in the server” paradigm, some months ago ItsNat an AJAX Java framework was released using a similar approach but in Java. If Jaxer is a Mozilla/FireFox in the server, ItsNat is a Universal Java W3C Browser in the server too build using servlets. In Jaxer view logic is in JavaScript W3C DOM, in ItsNat is Java W3C DOM, both share many things (conceptually).

Anyway ItsNat doesn’t need to create new persistence APIs etc because is Java, you can use the persistence framework (or any JavaEE part) you like more.

Comment by jmarranz — February 19, 2008

A similar approach is to use Python on client and server side, since Javascript is a quite young language for server side programming. Pyxer is an implementation of this idea.

Comment by perenzo — March 10, 2008

Sorry, forgot the link: http://www.pyxer.net

Comment by perenzo — March 10, 2008

Hmm, I think this is an interesting idea. I’m not going to lie, when I saw the article I heard myself almost yelling “woah”. But after taking a closer look at it, it isn’t that special. It’s nice to have the same language on the server and client, but it’s not needed. JavaScript was not meant to be a server-side language. Something like Python or Ruby serves the purpose much better.

Aside from my opinion, there are several technical problems with this implementation:
1) Speed. I think that’s obvious, but parsing the DOM and all that stuff for every single page requested, even if it has no JavaScript on it, is a huge performance hit.
2) Flexibility. Or lack of flexibility. You can’t really control things like HTML formatting with the DOM. I mean, that’s not too important, but for someone like me who likes their HTML clean and indented when they click View Source, it’s a bit irritating to see it formatted the Mozilla way. You can’t even make a template engine (well technically you can, but it would be slow as hell compared to the same one written in another language).
3) Limitations. There are currently some technical limitations as to how it can be set up. For example, you have to set it to parse every document in a specific directory. You can’t associate certain file extensions with Jaxer (or at least not that I know of), like you can with PHP and all the others.

All in all, I don’t think Jaxer is ready for use. Of course, it’s a newborn baby, and I can see it growing up in the future, but I don’t believe it is ready for a production environment yet.

Comment by musicfreak — March 10, 2008

What kind of functionality does an Ajax server offer thats different from a normal server. Is it the same as StreamHub Reverse Ajax Server? Or am I missing something here?

Comment by CometDude — October 1, 2009

Leave a comment

You must be logged in to post a comment.