Topic: Code Generation

Clorox – Shared Memory Abstraction for AJAX Applications

Dietrich Kappe, Monday, October 23, 2006 @ 6:00 am

Take a step back and squint and you'll see that Ajax, with it's ability to pass structured data back and forth between client and server, can be used to implement just about any architecture or abstraction that involves communication between execution environments. The only things getting in the way are the platform and performance limitations of the browser. Even with this limitation, we've already seen implementations from the obvious RPC (DWR, JSON-RPC, etc.) all the way to X11 (XML11) and various client engines and protocols in between (TibCo GI, ZK, Echo2, JackBe, etc.). If you haven't realized this already, there's more than one way to do things with Ajax.

Now along comes Clorox, a different kind of abstraction on top of Ajax. Developed as an MIT class project (see the paper here), Clorox hides all of the asynchronous request business behind simple Javascript data structure access.

In place of the asynchronous, RPC-based abstraction furnished by AJAX, Clorox provides the illusion of synchronously-accessed data structures shared between the web browser and web server, which is to say, it provides a shared memory abstraction. These data structures look exactly like ordinary JavaScript objects on the client side, allowing programmers to focus on what they do best (writing compelling web applications) without worrying about data locality, message reordering, callback functions, or data prefetching. Additionally, to free programmers from concerns over locking, Clorox allows multiple operations on these data structures to be grouped into atomic actions.

Clorox is a client-side technology. You have to write the backend code -- returning JSON objects with a TTL that controls caching -- yourself. Clorox consists of the Javascript runtime (which incorporates MochiKit) and a compiler (based on Rhino) that transforms application Javascript to Javascript. Why this extra step of compilation?

The Clorox Compiler compiles Clorox JavaScript files (.cjs files) into plain JavaScript. Didn't we just say that programmers write their applications in ordinary JavaScript, you ask? Yes, they do. However, under the hood, Clorox does have to make asynchronous AJAX calls to fetch data. The Clorox Compiler takes in JavaScript code that makes synchronous accesses to data structures and transforms it into JavaScript code that accesses the data structures using continuation-passing style programming. (This means that every time a data structure is accessed, we supply a method that indicates what to do after fetching the appropriate element). Essentially, this involves breaking up the code into a collection of callback functions. At runtime, these CPS accesses will generate the appropriate sequence of RPCs. In any case, installing the compiler is very easy. Just download it from the Clorox web site. It's packaged as a single jar file, so there's nothing else to do. It's written using Java 1.5, so you'll need a recent version of the Java Runtime to use it.

So you write code like this:

var cache = new ClientCache(new SimpleAJAXTransport("/path/to/your/script.pl"));
var cs_array = new SmartArray("basicArray", new NoPrefetchPolicy(), cache);
function printNumbers() {
for (var i = 0; i < 100; ++i) {
doWork(i);
}
}
function doWork(i) {
document.getElementById("outputDiv").innerHTML += cs_array.access(i) + " ";
}

and the compiler turns it into some ugly stuff with callbacks that does all the Ajax stuff for you. Clorox also allows you to configure whether it prefetches values or not for improved performance. You can see the framework in action in a mapping demo and a search suggestion demo.

Right now Clorox is in Alpha and has only been tested with Firefox 1.5. The documentation is brief but serviceable but more code examples are needed to provide a good framework to start your own application. Future developments will include automatic cache tuning. As this toolkit evolves, it could become the foundation for other, higher levels of abstraction. ORM for Ajax anyone?

Technorati : ajax, shared memory

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

More Javascript Code Generators and Another Ajax OS

Dietrich Kappe, Monday, September 18, 2006 @ 8:00 am

So, I missed two Javascript code generators, found the new home of a third, and found one more Ajax OS beastie. First the code generators:

• ParenScript has a new home. This is the Lisp->Javascript code generator. An example:

  (js
  (defun foobar (a b)
  (return (+ a b))))
  

  and the Javascript:

  function foobar(a, b) {
  return a + b;
  }
  

• ST2JS - A smalltalk to Javascript translator. Not a project overflowing with documentation and friendly explanations.
• jsc - this is another C# (or ) to Javascript code generator.
  
  

  The compiler extracts CIL from a .net assembly. It filters out the classes which are marked with the ScriptAttribute. It selects the target language and emits the source.

  I've already blogged about this tool once before, but it does belong in any listing of Javascript code generators, so in it goes.

Next, on the heels of our entry on Atomic OS, we have another cute little command line shell toy in Ajax: JS/UIX Terminal.

It's cute to be able to play invaders in the browser, for about 5 minutes. Under the covers, it purports to be an OS written in Javascript, implemented on top of the browser:

JS/UIX is an UN*X-like OS for standard web-browsers, written entirely in JavaScript (no plug-ins used). It comprises a virtual machine, shell, virtual file-system, process-management, and brings its own terminal with screen- and keyboard-mapping.

Cute as well, and probably an interesting learning experience. Not sure if the OS on top of the Browser is where the future of Ajax is. Abstracting services down to that level seems like overkill.

Technorati : C#, ajax, ajax os, code generation, lisp, smalltalk

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Eight Javascript Code Generators

Dietrich Kappe, Thursday, September 14, 2006 @ 8:00 am

Javascript code generation seems to be here to stay, with GWT taking roots and Ruby providing it's RJS Templates. It seems like it's time for a roundup of the little critters.

• RJS Templates for Ruby on Rails - Not quite a true Ruby->Javascript compiler as it seems to me, but cuts down on lots of coding.
• GWT - Java->Javascript. Everyone has heard of this beast. It's the 800 pound gorilla sucking the air out of the room for many other frameworks. Unique in that it provides a "hosted" mode that lets you debug in Java rather than Javascript.
• pyjamas - Python->Javascript. Open Source project inspired by GWT from which it borrows some ideas. Fairly active.
• Morfik - Java, Basic, C#, Object Pascal -> Javascript. Commercial offering from down under (Tazmania, dontcha know). Comes as an IDE that also provides server side development capability.
• Script# - C#->Javascript. No "hosted mode," so you are stuck debugging the generated Javascript. Runs out of Visual Studio. One man's effort right now, though that man apparently works for Microsoft. Unclear what the future of this project might be.
• Java2Script - Java->Javascript. Eclipse plugin. Predates GWT. Has a set of widgets based on SWT. Claims to allow you to convert your SWT based desktop apps into Javascript-based web apps. The demos (see screenshot of one of them) look promising.
  
• 
• Scheme2Js - Scheme->Javascipt. If you feel the need to get that LISP-like syntax when you write code, here is the compiler for you. There's an article describing the inner workings for those interested.
• Haxe - Haxe->Javascript. Haxe is an OO language used to write web applications, among other things. You can also use it to write Flash and server side apps. All in one language. Didn't I just see a resume for a Haxe developer here somewhere?

I'd only feel comfortable using RJS and GWT at this point, since RJS doesn't really "hide" the Javascript all that much, and GWT provides the hosted mode. If you are debugging a complex, generated hunk of Javascript, you'd better be able to either make sense of the code (RJS) or go back to the source language (Java in GWT). I'm surprised the other tools don't think to provide some sort of high-level language debugging capability. I guess too few developers these days remember what it was like to debug assembly language generated from a compiler.

There's also the ParenScript LISP->Javascript compiler, but it, alas, seems to have gone the way of all single developer open source projects. Last, there is this article from Microsoft Research about the implementation of an Oberon to Javascript compiler. An interesting how-to of how such a thing can be built. Sorry, just the article, no download.

Technorati : ajax, c#, code generation, eclipse, gwt, javascript, morfik, python, ruby, script#

• Digg
• Reddit
• del.icio.us

Comments (4)

Software Development