I've been thinking again, in between working on eclipsefp, about writing a multi player role-playing game in Haskell. OK, I'm not going to write something the size of WoW by myself in my free time (unfortunately my day job doesn't involve any game programming nor any Haskell hacking :-(), but since I enjoyed writing Mazes of Monad, I figured that a game is a good way to learn things. A MMORPG should get me into concurrency, persistence, graphics, performance etc...
What I'm trying to figure out at the moment is what architecture to use. Mainly, if I have no doubt there is going to be a server somewhere running Haskell code, I wonder about the client. Should I try to write a browser based game coupled with a Haskell web server? That way, users could easily play the game when (if) it gets to a usable state, and I won't have to worry about cross platform issues for the client. Getting proper server side events or push should be fun, and of course if I end up using something like web sockets I will probably require a fairly cutting edge browser, which negates the advantage. I'm not too sure meddling with AJAX long polling and dynamic HTML is such a attractive option.
The other path is to write a Haskell client. Granted, users will have to download it, which means either me dealing with cross platform issues (provide several exes) or restricting my users to people happy to use cabal install. But I'll get maybe into stuff like OpenGL in Haskell, and do everything in Haskell instead of mixing Haskell with HTML and JavaScript (I've just stumbled upon jmacro, which could be cool I guess).
I'm sure everybody has faced that question at some stage. Ah well, for the moment I'm still wondering what my game will do, so I guess I have time to play with a few things before I make my mind up.
In this blog I talk about some of the personal programming I do as a hobby. From Java to Rust via Haskell, I've played around with a lot of technologies and still try to have fun with new languages and APIs!
Showing posts with label RIA. Show all posts
Showing posts with label RIA. Show all posts
Friday, October 09, 2009
Friday, May 11, 2007
Poor man's JavaFX Script is, er... Javascript
Sun has release its own RIA framework called Java FX. It provide JavaFX Script, which is a language based on Java whose goal is to develop quickly graphical applications with the power of Java. Is it touted as competition to Flex that I have mentioned before. It is safe to say that it hasn't been received with a great deal of enthusiasm. The fact is, I don't want to learn another language again to do my Web 2.0 application. And I do believe that Fielding has a point when he reflects that applets break visibility and raise the barrier of entry for web developers. Also, I'm usually all in favor of static typing and compilation, but for GUIs I'm not too sure. When you want to tweak your borders or your layouts you probably happy enough with a quick cycle of change code/refresh page. So why don't we use Javascript and Java Applets together instead of inventing yet another technology?
Ok, it's time you get over your irrational distrust of Javascript. A multi paradigm (object, functional) language available for free in every browser!! And no, I don't suggest we go on using the HTML DOM or things like that. That's why we need applets.
Applets? I must be mad! Applets have not worked on the web. But what I suggest is not to develop one applet for each RIA application, but only develop one Applet that everybody could use, much like a plugin, that would bridge the gap between the JavaScript world and the Java/Swing world. If it has been done, please let me know. As for me, I've put together a prototype in an hour that works fine:
This web page creates a simple "Hello" button that when clicked changed its text to upperCase(). It demonstrate the two ways communication between the Javascript code and the applet (note how the function is serialized in JSON just with its name, that's the only thing we need). So the Javascript can deal with a model that is a slightly abstracted Swing model (no more hair pulling between different browsers). I stress again, the applet is a generic applet that deals with the link between the JSON objects and the Swing layer. Of course the applet could offer other services: simple API to call back the server (AJAX from the applet), etc...
Then the applet could be packaged with a cut down version of the JRE (only the classes really needed) as a plugin to do rich Swing application from JavaScript...
And voilĂ ! A scriptable RIA platform!
Ok, it's time you get over your irrational distrust of Javascript. A multi paradigm (object, functional) language available for free in every browser!! And no, I don't suggest we go on using the HTML DOM or things like that. That's why we need applets.
Applets? I must be mad! Applets have not worked on the web. But what I suggest is not to develop one applet for each RIA application, but only develop one Applet that everybody could use, much like a plugin, that would bridge the gap between the JavaScript world and the Java/Swing world. If it has been done, please let me know. As for me, I've put together a prototype in an hour that works fine:
- The JavaScript code constructs an object tree that represents the GUI.
- The object tree is serialized to JSON and passed on to the applet
- The applet deserializes the JSON and constructs a Swing GUI by translating the object tree
- The object tree can contain handlers that are the names of Javascript functions
- The applet calls the javascript functions on Swing events
- The JavaScript event handlers update the GUI tree and notify the applet with the changes.
<html>
<head><title>JSApplet</title>
<script language="Javascript">
var helloButton={type:"button","id":"helloButton","text":"hello","action":onClickHello}
var frame={"contents":
[
helloButton
]
};
function onClickHello(){
helloButton.text=helloButton.text.toUpperCase();
updateJS([helloButton])
}
function startJS(){
var msg=document.getElementById("JSApplet").setContent(toJSON(frame));
if (msg){
alert(msg);
}
}
function updateJS(objs){
var msg=document.getElementById("JSApplet").updateContent(toJSON(objs));
if (msg){
alert(msg);
}
}
toJSON=function(arg) {
switch (typeof arg) {
case 'object':
if (arg) {
if (arg.constructor == Array) {
var o = '';
for (var i = 0; i < arg.length; ++i) {
var v = toJSON(arg[i]);
if (o) {
o += ',';
}
if (v != null) {
o += v;
} else {
o += 'null,';
}
}
return '[' + o + ']';
} else if (typeof arg.toString != 'undefined') {
var o = '';
for (var i in arg) {
var v = toJSON(arg[i]);
if (v != null) {
if (o) {
o += ',';
}
o += toJSON(i) + ':' + v;
}
}
return '{' + o + '}';
} else {
return;
}
}
return 'null';
case 'unknown':
case 'undefined':
case 'function':
return arg.name;
case 'string':
return '"' + arg.replace(/(["\\])/g, '\\$1') + '"';
default:
return String(arg);
}
}
</script>
</head>
<body onload="startJS();">
<applet id="JSApplet" alt="JSApplet" code="fr/moresmau/jp/jsapplet/JSApplet.class" codebase="bin" mayscript="mayscript" height="100" width="100"></applet>
</body>
</html>
This web page creates a simple "Hello" button that when clicked changed its text to upperCase(). It demonstrate the two ways communication between the Javascript code and the applet (note how the function is serialized in JSON just with its name, that's the only thing we need). So the Javascript can deal with a model that is a slightly abstracted Swing model (no more hair pulling between different browsers). I stress again, the applet is a generic applet that deals with the link between the JSON objects and the Swing layer. Of course the applet could offer other services: simple API to call back the server (AJAX from the applet), etc...
Then the applet could be packaged with a cut down version of the JRE (only the classes really needed) as a plugin to do rich Swing application from JavaScript...
And voilĂ ! A scriptable RIA platform!
Subscribe to:
Posts (Atom)