Remember Server Side JavaScript (SSJS)? (okay you are probably far too young) It came out of a time when the most popular browser was NCSA Mosaic, some people were still trying to use C libraries to create CGI scripts and when Java was in early beta. SSJS has not been widely integrated in application servers. With the recent trend in AJAX applications it looks like SSJS might be on the brink of a renaissance.

In the AJAX sphere there has been much interest in Direct Web Remoting (DWR) which allows JavaScript access to Java beans methods via servlet generated JavaScript files. But why stop there, why not have JavaScript talking to JavaScript? (there is a certain perverse logic in there somewhere). It turns out that there are already several like minded offerings where JavaScript has become the Server Side scripting language of choice.

Mozilla produced Rhino, a Java based JavaScript engine as part of the Xena project. Several server side application platforms have been produced based upon Rhino. You can use Rhino directly, see these interesting articles on using Rhino with web services (1, 2) and it also supports E4X. I must also mention Seppia which is an application that embeds Rhino that might also be interesting to look at. Now to the Server Side JavaScript applications, here are a few examples that caught my eye:

• Rhinola (based on Rhino, well duh!) and seemingly Unix server oriented uses mod_gcj to run JavaScript files as server side scripts much in the manner that you would expect Perl or PHP scripts to run.
• JSDB is a versatile JavaScript scripting toolkit environment with support for database access.
• Whitebeam is an application server with the Rhino engine at its core. As you would expect from an application server it integrates support for accessing databases and with Rhino's built-in support for E4X is also a dab hand at anything XML based (such as web services).
• OpenMocha is an application server based on Helma which uses the Rhino JavaScript engine to do server side scripting. To my eye this looked like a distinctly content management system (CMS) based application.

In conclusion, it looks like JavaScript is rearing it's head in more places than in client side browsers. We're seeing JavaScript in desktop applications and on the server side once more. With E4X it has actually become easier to use JavaScript for XML manipulation than it is in many other so called real programming languages. From where I am sitting it looks like the future of JavaScript will be a bright one.

With all the recent interest in AJAX applications, all manner of JavaScript related technologies have the potential to take to the spotlight. Yahoo!'s Konfabulator and Apple's Dashboard are two such fascinating applications. They serve up small desktop applications called Widgets. A widget could be a clock, RSS feed, a search engine, a CPU monitor and other fun little desktop distractions (think XTeddy and XEyes from the Unix days of yore). As you might expect of a product originating from the Mac arena some widget designs are close to aesthetic perfection. Konfabulator and Dashboard offer the same sort of functionality and are both based on an underlying JavaScript engine but are implemented in slightly different ways. Konfabulator and Dashboard files use the .widget file extension, this is only an alias for the ZIP file format and this means that anybody can look at the source for any widget and learn from the masters. I want to sidestep the Dashboard versus Konfabulator debates if I may as despite all the arguments they are sufficiently different internally to both have unique merit.

This is what a Widget looks like: this example is a butchered DHTML version based on the Flip Clock Dashboard widget from Neometric Software. It looks best on browsers with good PNG support.

Apple's Dashboard

Apple Dashboard widgets are created from HTML, Images, JavaScript and CSS. The Dashboard server uses the same engine as the Safari browser. The engine called WebKit is open source and consists of WebCore and JavaScriptCore; an HTML/CSS renderer and JavaScript engine based on KDE's KHTML and KJS. Widgets use and Safari supports certain non-W3C standards such as the <canvas> element. A Dashboard specific JavaScript mechanism called the widget object is available that allows a widget to run system commands, access other desktop applications and obtain online content.

Yahoo!'s Konfabulator

Konfabulator widgets are composed of JavaScript, Images and driven by an XML document (written in a Konfabulator specific XML dialect). Unlike Dashboard, Konfabulator has been written to be both Mac and Windows compatible. Konfabulator utilises Mozilla SpiderMonkey (written in C) as its JavaScript engine, this is the same JavaScript engine used in the Mozilla and Firefox browsers. Konfabulator provides specialised extensions to JavaScript to enable system interaction and widgets call the same API irrespective of what platform they are on (only the server implementation actually differs).

Thinking about Clones...

There is already a Dashboard clone called dotWidget and although it looks quite similar to Dashboard the underlying mechanism uses VBScript rather than any kind of JavaScript engine. Now being a Java sort of person I couldn't help but speculate how one might go about producing a Widget type of application using Java technologies. I'm not a Swing or AWT programmer so an actual implementation is probably beyond me but nonetheless it is interesting to think about the possibilities.

Musing about a Java Konfabulator clone...

SpiderMonkey is not the only JavaScript engine that Mozilla have produced. The now defunct codename Xena project, sometimes called Javagator, attempted to create a 100% Java version of the Mozilla browser. Xena produced a couple of interesting subprojects including a newsreader Grendel and a fully equipped Java based JavaScript engine called Rhino. Rhino would be a particularly good choice for any XML handling application because it now includes the power of E4X which makes XML programming very easy. Rhino is very easily embedded in other Java applications and so it would be quite feasible to produce a Konfabulator clone based on Rhino.

Musing about a Java Dashboard clone...

Since Dashboard widgets utilize HTML and CSS, a HTML renderer of some sort would be needed. There are some interesting HTML renderers about including Flying Saucer XHTML renderer but this does not currently integrate the JavaScript engine that we would also require. So I would think that a more suitable approach would be to use a Java browser wrapper. Via Joshua Marinacci's The HTML Renderer Shootout articles (Part 1 and Part 2) I found two projects that might fit the bill, JRex and Blackwood Webclient, both based on the Mozilla browser codebase. Using either of these would essentially harness the power of Mozilla in the same way as Dashboard harnesses the power of Safari. There is also a possibility that a Mozilla based browser could even support the <canvas> element. Specialised system JavaScript objects could also be supported using something like JRex's JRexLiveConnectSession. So at least in principle it would seem that it would be possible to create a Dashboard clone using Java.

Roundup

A Java, JavaScript engine based clone of Apple's Dashboard and/or Yahoo's Konfabulator is within the realms of possibility. I also got the distinct impression that widgets are not that different to their web counterparts such as JSR168 portlets. Indeed there are already some widgets for the web types of application such as the Flash based OpenLaslo and AJAX based Bindows. Given the growing popularity of toolkits like Direct Web Remoting (DWR) to produce AJAX applications and quality of the JavaScript engines available a resurgence of server side JavaScript might be on the cards...

More about this in my next entry... The Return of Server Side JavaScript (SSJS).