Challenges of Server-Side JavaScript

Just last week Aptana released Jaxer, dubbed "The Ajax Server", the latest - and greatest entry into the Server-Side JavaScript arena. Jaxer is not the first SSJS framework, and (Steve Yegge willing) won't be the last either.

A couple of years ago, sun released project Phobos, which is a very well documented and powerful SSJS Engine with support for direct subclassing - in JavaScript - of loaded Java classes à la Groovy. It also has a kind of proto-rails opinionated structures, with Controllers and Views. This is not something I condone on the server, but let's not rant about that right now. Some people will find it useful.

Then there's TrimPath, which looks like what Steve is trying to do, with Google Gears integration, alleged Ruby on Rails-like MVC and a lot of other good stuff to boot. Another feature of TrimPath is that is can execute on either the server or the browser, just like Jaxer.

Another great SSJS is Helma, which includes an MVC framework, just like most others (except Jaxer). Helma also lets you access any Java Class in your Classpath, but more interestingly it has something called HopObjects, which is a JCR (JSR-172) like data repository, built in to the framework itself. You create object in JavaScript, on the fly, and they gets immediately created and RESTfully accessible.

This brings us quickly to another class of SSJS, namely the Mozilla Rhino integrated Java-based frameworks, like Apache Sling, for instance. Sling _is_ an über-JCR implementation which uses REST for object management, can be a webDAV server and is violently OSGi compliant :) But for the purpose of this discussion - it most importantly has a generic Scripting support, letting you script resource behavior in JSP, JRuby and, yes, SSJS.

Sling is probably not the last framework to enable productivity by simplifying development by allowing server-side scripting inside a 'classical' framework - Sling being anything but, but you understand what I mean.

But back to Jaxer. Is jaxer really an also-ran even before it came out. Does it have anything to contend with beside these other frameworks?

Well, yes, actually it has. Jaxer has (not yet) integrated support for any Java class in classpath - which should be in their number five priority list), but it has server-side DOM rendering.

Huh? But the DOM is on the client..

Not any more baby, check out these pix and see what I mean. Jaxer can take any HTML/js/css combo, and if you want execute the (standard) jQuery calls to set up the markup the way you want, and then sent the finished, static page to the client.

It could, for instance, detect if your poor user was forced to use a version of Internet Explorer, and then use the Mozilla engine included in Jaxer to render the page on the serve, and give them the right page looks anyway. How's that for flexibility.

Also, Aptana has financing, has released Jaxer under GPL, and has integrated Jaxer (which can be standalone as well, as an Apache mod) into their Eclipse-based IDE, Aptana Studio.

Yes, I like Jaxer, and I like the Studio as well, in case you didn't notice :) But what Aptana really need to do is to check out their SSJS competition and offer framework services, Java, and possibly PHP integration and more out-of-the-box services. And more Dojo. Lots of Dojo.

Actually, the SSJS (non-web) framework issue was on the top of my mind when I started writing this, but I'll have to get back to it later, due to bed-putting constraints .

Until then,


Uri said…
Thanks Peter, I think you really nailed what we're trying to do with Jaxer: a full Ajax server, not just another SSJS stack, of which there are many good ones, as you mention. There's no question server-side scripting is incredibly important, and there are some good reasons for choosing JS. But it's the ability to use the full Ajax stack on both client and server, with natural integration between them (e.g. transparent callbacks), that we think will make Ajax development a lot smoother.

I also agree with your plan for what we need to do next, although there are a few other important directions I'll add to that, namely server scalability and more generally the deployment story and hosting. Look for more news on that every week.

As far as frameworks go, e.g. an ORM or persistence framework, we're very curious to see where the community would want us to go. Please let us know, here or on our forums (
Script Uncle said…
Hi Uri,

I agree that server scalability is very important, and I must admit to being very curios about hosting. I'm a bit tired of wrestling with EC2 and S3, so a reasonable hosting would be great news.

But still, I think the absolutely most important thing is integration, by framework or by other means. If you can (or someone (me? :)) provide easy integration with existing frameworks and services, you'll make it easier to push for Jaxer in the enterprise.

On the top of my list would be to push hard to bridge the Java divide, because you're nearly there, and the programmer base is enormous.

Secondly, bundle Spring and Hibernate with Jaxer, and provide examples on how to use existing databases and services.

I just saw that you'll be leveraging the SOAP/WSDL support from Mozilla, which is a large step in the same direction.

It'll be interesting to see what Jaxer will grow into.

Uri said…
Hi Peter,

The SOAP/WSDL capabilities are now in our latest release, as are other web service-type capabilities.

We're actively working now on the hosting aspect, and our intent is to make even the creation of the hosted offering an open process so people can see how we're building it out and help us make it what they want.

And in parallel we're actively developing the bridge to Java, and again that will be an open process. We already had a bit of a prototype to show the concepts make sense, so we'll be posting more about that very soon. Our solution will support Spring at least, and should support Hibernate, but we'll need to see how deeply they're truly integrated: unifying the page and session contexts, etc.

Script Uncle said…
@uri: That's great news!

I've been too busy doing actual work to be able to do the stuff I want to do this week. I'll get the bun of the rack and see what i can do with it.

Leveraging existing things with Spring is a big win. Thanks. :)
Jaxer is not the first one introducing the server-side DOM approach.

Some moths ago ItsNat was released with a similar approach but in Java using no special infrastructure, only one servlet.
Script Uncle said…
@Jose: O_o That's interesting. I wonder if Aptana knows about this project. Since both are GPL, they might be able to share resources.

I'll have a closer look..

Unknown said…
First I must to say, Jaxer approach is smart, really.

But one competitive advantage of ItsNat over Jaxer is client-server automatic sync: you can change any piece of server DOM on load time and in an AJAX request too, the client DOM is changed accordingly.

AJAX requests are received in Java as W3C Java events and processed with user defined W3C Java EventListeners, because ItsNat simulates a Universal W3C Java browser including events.

This way you can build complex AJAX based applications with no client JavaScript, only Java based code using Java W3C DOM APIs.

Moreover ItsNat supports server-sent events, from Java you can fire and send to the client W3C DOM events (or directly to the server DOM) simulating user actions.
Script Uncle said…
@jmarranz: Yes, I must say that I was very impressed with ItsNat.

What makes it really easy to start to use is the custom-built Ajax/JavaScript framework which really is astounding in it completeness.

On the other hand, I think that ItsNat would be more simple to adopt if it had simple to use examples for Dojo, Ext, jQuery, et.c. which would be fairly easy (is my guess) to integrate into the event model of ItsNat.

Also, the most attractive thing with Jaxer is that it is JavaScript on the server, and not Java, but YMMV :)

The most important thing, though, is that ItsNat - just as jaxer - separates the client and the server cleanly.
Unknown said…
Thanks for your comments.

I think Rhino could be optionally integrated in ItsNat with no much hassle to execute JavaScript code embedded inside the (initial) X/HTML page as Jaxer does. Java W3C DOM objects would be seen as JavaScript W3C DOM objects as in a W3C browser (FireFox,Opera,Safari...).

Furthermore, anyone can do this with no ItsNat modification because developers have access to the server DOM tree and can do any kind of DOM parsing.

And I agree, Dojo, JQuery etc in the client side can be mixed with ItsNat in the server, in fact ItsNat has "user defined events" for this task, these events can fired and sent to the server from the client programmatically and received as W3C DOM events (implementing, and server code can return custom JavaScript to the client easily with one simple method ItsNatDocument.addCodeToSend(Object)
to interact again in the client with the JavaScript framework.

This integration may be useful for instance to create client centric components bound to the server to receive new data from databases etc.

Furthermore I think server code could "extend" client JavaScript frameworks from server because the client DOM tree changed by client JavaScript code can be synchronized with the server (ItsNat provides techniques to do this) and server code can change client DOM automatically changing the server DOM. Anyway this approach is difficult and requires some work and deep knowledge of the client framework.

Anyway I don't want to bind "by default" ItsNat to any external JavaScript framework (and because there is no clear "winner"), ItsNat is server centric.
Script Uncle said…
@jmarranz: Hi again. Welcome back!
You make good point about stuff that important to know about ItsNat, and which are not readily available from the web pages.

Actually, my point was not to integrate any 'winning' framework into ItsNat, but to show how to use any framework to access the server using user defined events.

That way you could leverage developers existing expertise of an existing client-side framework, to try ItsNat out, much in the same way that Aptana has done with their jQuery examples.

Also, it emphasize more SOFEA style coding, which is a good thing :)

I'm not sure that DOM-modification on the server is a good thing as such. It's complicated, and it's a killer app for the problem domain that really needs it, but most normal apps don't, and I suspect that it might actually be a more complicated way of doings thing.
Unknown said…
@Peter Svensson: Also, it emphasizes more SOFEA style coding, which is a good thing :)

I don't agree with you Peter, this item separates us :)

SOFEA promotes the return of the thick client again with web technologies. I think the web success on application development is mostly because the application is in the server highly controlled (cooking the view too) and the client is thin. SOFEA introduces again the need to transport "the application" to the client.

A client centric model brings almost the entire application again in the client and compels again to build custom "bridges" between server and client, is a return to the fat client/database model with a new tier in the middle (the server doing the SQL queries and sending the results).
Anyway I must recognize this model *works well* with very rich client applications and applications with no very much source code. But if I'd be an IT chief of a bank I wouldn't follow the SOFEA principles to build my web applications, because banks are paranoid "by default", and SOFEA promotes give too much to the client... and to thieves, competitors… and SOFEA promotes scripting as the main language, too much scripting code introduces maintenance problems.

Jaxer and ItsNat aren't SOFEA frameworks because they both promote cooking the view in the server, of course in a new way: DHTML on the server. With this approach data and view live in the same space (the server) and no special data transport bridge must be coded to feed with data the view.

@Peter Svensson: I'm not sure that DOM-modification on the server is a good thing as such. It's complicated.

Why? In a very few hours you can be a master of the W3C DOM Level 2 Core. DOM-modification in the server is in no way different to coding in the client, furthermore the framework can adapt to the specific browser any JavaScript generated, for instance in ItsNat you can call elem.setAttribute(“style”,”color:red”); this code doesn’t work with MSIE but ItsNat transform this call to = “color:red” if MSIE is the client target, no need of client JavaScript frameworks, pure W3C DOM.

Jaxer does a very good job supporting JavaScript frameworks like jQuery executed in the server “out of the box”, with ItsNat jQuery could be used with Rhino. jQuery and any other JavaScript framework could be ported to Java with no very much problem; furthermore the code would be cleaner removing very much browser specific code.

And DOM-modification on the server is a dream if AJAX is used. Classic server-side frameworks are introducing AJAX with black boxed, highly intrusive components because they can’t give to the developer the absolute power of the custom DOM modification.

Anyway you are the “uncle script” and me “uncle server Java” so we can meet in the middle… tier ;)

Regards from the server side
Script Uncle said…
@jmarranz: Thanks for your good comments, and yes, I suppose we have to meet in the middle tier somewhere :)

The reason I consider doing DOM on the server is complex is the same reason I consider doing view (in the MVC sense) on the server complicated.

And your points on security and confidentiality does not stand, I'm afraid. The only thing that happen when you put the view on the client, is that you get a cleaner separation of concerns between server and client.

Naturally no security concerns will ever be implemented on the client, and the formatting and user UI, will be seen anyway, even if implemented on the server.

Also, the complexity issues arise when you're using Ajax communication to the server, because you already have a decoupled client at that point. But some of its state is generated on the server, for some actions.

That is the reason I advocate a SOFEA (or SOFEA-like) approach for building web applications. It is a clean interface. View is implemented on one side only, and the most important part is this; The server can focus on only implementing core business logic, security and provide data.

I have written a couple of things which I hope make my points clearer, hopefully listed in this short slideshow;
Unknown said…
We can encounter in the middle: you are thinking on classical server frameworks like Struts, JSF... but ItsNat is another world is SOFEA on the server :)

Because ItsNat is a complete Java W3C Browser on the server including events.

Jaxer falls near to this approach too (but without automatic client synchronization).

Anyway ItsNat approach fails if your application is highly interactive if you need to process in the server mouseover/out, keyboard events etc (too many events sent to the server), a client framework can be a good complement.

In this case, with user defined events ItsNat can provide the communication bridge and server back end that SOFEA proposes. Server based W3C EventListeners (listening user defined events) can be used to provide SOA services to the client (client view modification from server is optional or no necessary in this case).

Sending user defined events is very easy:

var elem = ... (some DOM element or null)
var itsNatDoc = document.getItsNatDoc();
var evt = itsNatDoc.createUserEvent('myUserAction');
// Optional user defined extra params
// Dispatch to the server

your registered
receives this event on the server.

See you soon in the middle tier.
Script Uncle said…
@jmarranz. Thank you for providing examples on how to use ItsNat. I think that w3c events are something I need to look more into, anyway, when trying to make the specification of TSA (or what i/we might call it).

I still think that even though in-server DOM rendering and transparent event models are really neat concepts (It's a great Hack, and it feel *good* somehow :) , putting presentation and View on the client and only ask the server for raw data makes for a much simpler development model.

And it's a little bit this that I'm trying to advocate; We only have so many projects left in our lives, and I want to spend as much time as possible coding my actual projects, rather than massaging all meta-information around it.

At the moment, the most simple solution, that gives me the best problem/metainfo ratio is to just make simple clients and simple servers, with simple protocols in between.

Of course, there are always edge cases, but still .

Well, why can't we have a conference around these issues anyway? What do you say? Clientside symposium :)
Unknown said…
@Peter Svensson: Well, why can't we have a conference around these issues anyway? What do you say? Clientside symposium :)

If it is online...OK
Script Uncle said…
@jmarranz: I'd say we're in conference now, in that case :)
Well, I've started thinking about a simple site for collecting ideas around simplifying web application development.

Maybe that would do as an online conference?

I'll try to compile a list of questions around different fields of interest. These mainly revolve around how to use available technology to reach the next step in web application development, so the obvious questions are the following (at first);

1. What are the goals(, more than just simplifying development)?
2. Are these goals reachable with current standards and technologies?
3. If not, where are the holes to be filled, and where are the road-blocks?

Fairly generic, I know and I'm sorry, but given that, what is your take on that?

Unknown said…
I don't have very much free time...but I can contribute to that "new web site" with new perspectives to build web sites using client techniques but on the server and how client and server can collaborate using the same paradigm. They will be related to ItsNat because is the "thing" I'm strongly involved these days.
Script Uncle said…
@jmarranz: I don't have much time on my hands either, but I feel that this is such an important issue.

It would be great if you could be part of the group and help to draw up the general guidelines.

I would hope that we can formulate both framework- and language-neutral recommendations and/or protocols.

I'll try to formulate some basic goals for the group and mail them out to all who have been expressing interest during the week.

Jerng said…
How's this going? I'm new to web (about 18 months going on CakePHP and jQuery). Next, thought I'd look into SSJS and write a MCV framework on node.js + jQuery for client-side integration; also interested in having the application store webpages as objects, and have developers work on the objects per se, rather than having (e.g. CakePHP style) a mish-mash of insertions into a linear text document (read: e.g. .php file).