The paper on Oberon Script that I submitted to the Joint Modular Languages Conference (JMLC 2006), and that I wrote about in my last post was accepted. Thank you! In the mean time, two toolkits were announced to the public that allow developing AJAX-style Web Client Applications (WCAs) in a high-level language which is then compiled to JavaScript as a high-level object code. The two are Google's Web Toolkit (GWT), based on Java, and ASP.NET architect Nikhil Kothari's Script#, based on C# (snappy name, by the way, isn't it. "GWT" looks rather clumsy next to it, and too close to GWB for comfort). I haven't tried any of them yet, but the code examples look promising (in particular the JavaScript translations). I can see a few problems developing in a "foreign" i.e. non-script environment, but perhaps that's just superficial.

Anyway, the main difference between GWT and Script# on the one hand, and Oberon Script on the other (apart from the language) is that they are offline compilers while Oberon Script is a load-time i.e. online compiler. Also, Oberon Script is a proof-of-concept whereas the other two are production systems (that they are both still beta quality does not negate that). The offline-online distinction is significant. You certainly don't want to compile a full application client-side into JavaScript. This makes Oberon Script in the current form a loser. However, there are situations where it makes perfect sense to generate a few bits of JavaScript on-the-fly:

• Mobile code. There may be situations where one wants to transmit a few bits of code together with a blob of data, e.g. as part of an XML message. Surely, you dont want to execute arbitrary JavaScript code within the context of your application. But, instead of trying to validate the mobile code it can make sense to limit what can be expressed in the first place by specifying some sort of mobile language and compiling that into JavaScript.
• Component wiring. A composition of Web Controls is a static arrangement of high-level objects (components), of input and output connections, customizations etc. It is more natural to express such a composition using a descriptive method than using code. The description can be, say, an XML document specifying what component uses what other component, and which outgoing interface feeds which ingoing interface. Such a static description can then be compiled on-the-fly into a JavaScript program that actually creates and establishes this arrangement.

The Oberon Script project can be seen as an attempt to stake off the limits of what can be reasonably accomplished on-the-fly. In any case, I think we can expect to see more development in this area of compilation to JavaScript, and some of it certainly also client-side.