Nathan CrauseMusings of a Software Developer

A while back I started a little project to enable scripting in a browser in languages other than JavaScript. Let's be honest - JavaScript is horrible. The project was inspired by several others I came across, and like those projects I opted for a Java Applet which would facilitate communication between the browser and the language implementation.

I had managed to overcome the vast majority of the problems the other projects encountered, mostly by avoiding the Java Plugin's own "DOM" package and instead creating my own using LiveConnect and querying JavaScript directly for the DOM objects.

This is all well and good, but it's not really the point of this post. It occurred to me while working on this, and working on several other JavaScripts, that this new scripting paradigm could overcome some serious problems currently facing web developers.

Firstly, the scripting would be cross-platform by it's very nature. The Java Applet itself would identify the browser being used, and would internally adjust it's LiveConnect communication accordingly. The web developer would be immune to these differences between browsers.

Secondly, the scripts could be multi-threaded. JavaScript is notorious for being single-threaded, which causes no end of odd programming techniques requiring "setTimeout" to accomplish anything useful and complex.

Thirdly (but related to #2), the hosted scripting languages would likely support "sleep" or "wait" or some variation thereof. Since the primary processing isn't occurring within the browser's own JavaScript engine (with only small, quick queries to JavaScript via LiveConnect) there would be no need to worry about tying up one thread of processing.

Fourth, since we're using an Applet anyway, we could offer more "dialog"-style options other than "alert()", "confirm()" and "prompt()". We could expose all the various flavours of the "JOptionPane" and offer an astounding number of variations.

Fifth, but probably not all that important, would be JavaScript standardisation. Microsoft's JavaScript engine is garbage, and it doesn't normally operate like any other vendor's, despite there being a governing body for this sort of thing. Using the Java Applet, we could offer the Rhino engine, which would fundamentally mean every single browser would be using the identically same JavaScript runtime.

Sixth, we could enable cross-domain HTTP requests. The various browser's JavaScript engine's enforce "same domain" rules, even when simply performing an XMLHttprequest. While this is punted at helping prevent malicious information gathering, my personal opinion is that simply reading raw data from another site cannot cause sensitive information being leaked. If the developer decides to JavaScript "eval()" the results, then the onus is on the developer to make sure they are processing clean JavaScript. Besides, which site is really stupid enough to store sensitive information in cookies, anyway? Frankly, preventing cross-domain HTTP requests is a vastly more heinous crime against humanity than supposedly letting one domain read some benign information from another.

The only glitch to #6 would be the Java sandbox - it, too, prevents I/O with a server outside the source from whence it was loaded, unless it is signed. Unfortunately, signing the applet might open the browser to script exploitation by allowing the language runtimes to execute without security restrictions.

Well, those are my thought. I haven't had a chance recently to work on it directly, but another JavaScript library that I am working on, Browser Toolkit, will make embedding and using Browser Scripting a lot easier, and hopefully attract a wider user-base.