Server-side javascript, yep!

Turns out the solution to server-side Javascript is V8, NodeJS, node-mysql and express. When I get a few spare tuits I'm going to see how all this fits together.

EDIT: Also dnode, expresso

Woah!

So I bit the bullet and installed MSIE 8 on my Windows VM. A task that would have been made easier if the download page didn't crash MSIE 6. Brilliant move there.

Today I was poking around a bit and discovered some startling things: A JavaScript debugger, logging console, CSS and DOM viewer and more! WHO'S A HAPPY PROGRAMMER NOW?

Mind you the MSIE Dev Tools are equivalent to a 3 year old version of Firebug. And the dev tools are pretty slow, about as slow as a ... a very slow thing. I'm going to have to up the resources to that VM.

And of course, this being MS, they go and muck up the console.log API.

The following works as expected:

console.log("Something");

This next snippet however fails:

console.log.apply(console,arguments);

Someone please track down the programmer who wrote this and all the team leads and suits who signed off on it and SLAP THEM UPSIDE THE HEAD! .apply has been part of JavaScript since 1.3, which was released back in the previous millennium. So we get yet another arbitrary work arounds for MSIE.

Because I can't just go sprinkle console.log() through out the code; many/most users will not have Firebug or MSIE 8 installed.

function fb_log () {

    if( window['console'] && window['console']['log'] ) {

        if( window['console']['log']['apply'] ) {

            console.log.apply( console, arguments );

        }

        else {

            // Assume this is the MSIE 8 console

            console.log( fb_format( arguments ) );

        }

    }

}

Firebug has printf-like formatting of console.log output. For MSIE 8 we have to do it by hand:

function fb_format ( args ) {

    var N=1;

    var string = args[0];

    if(typeof string  == "object" ) {

        return fb_object( string );

    }



    return string.replace( /%([sdi])/g,

            function (str, p1, offset, s) {

                var ret = '';

                if( p1 == 's' ) {

                    ret = args[N];

                }

                else {

                    ret = args[N].toString();

                }

                N++;

                return ret;

            } );

}

Firebug also has some magic for logging objects:

function fb_object (obj) { 

    var a = []; 

    for( var k in obj ) {

        if( typeof obj[k] == 'string' ) {

            a.push( k+': "'+obj[k].replace(/"/g, '\\"' )+'"' ); // "

        }

        else {

            a.push( k+': '+obj[k].toString() );

        }

    }

    return "{ "+a.join( ', ' )+" }";

}

Server-side javascript

Louis is looking into getting the contract for a big project. A really big project. Big enough that we'd have to hire more programmers, and user-friendly phone answers.

This got me thinking about what language I'd use. In the last 15 years, I've written pretty much everything in Perl. I really like Perl. However, there are many things that annoy me about Perl. Many of these things are solved in Perl 6 and/or Moose. But Perl 6 isn't ready and never will be, and Moose.... well lets just say that I like Perl!

Also if I'm hiring programmer(s) maybe Perl isn't the best language. This project will be used for 10 (read 20) years to come, by a diverse bunch of not very bright users. So what else would I want to program in? Erlang is dead cool, but not for common mortals.

I'll ignore Java as a bad joke, C++ or C wouldn't do for something of this complexity. Ruby, Python? I'd just as soon use Perl.

So how about Javascript?

Javascript is really my new favorite language. Remove the frustration of dealing with JS in MSIE, which is really the problem of MSIE's DOM implementation, and JS is a really nice language, with associative arrays, regexes, objects, inheritance, functions as data, closures, etc. It lacks low-level data manipulation like Perl's pack/unpack, and it has some silly legacy features.

What's more, if all validation is already written in JS, you can then do client-side and server-side validation of input for free.

So how is JavaScript on the server done? Turns out there are many ways.

yum --enablerepo=rpmforge install js will install SpiderMonkey, and I guess you could use #!/usr/bin/js in a CGI. But in 2010, you don't want to be implementing a framework from scratch, including things like MySQL access.

Jaxer is very very cool looking. It hugely shrinks the distance between the client and the server, as it were. The browsers' DOM is accessible from the server. Which is a very very cool idea that I've used in the past.

Jaxer goes one further too: the border between browser and server can be blurry when you use the runat="proxy-server" feature. It 'simply' turns a function call in the browser into a synchronous XMLHttpRequest which calls the function on the server. How cool is that? I'm going to have to implement something like this for POE::XUL.

One drawback of Jaxer is that it seems to need Aptana to compile. Having source code isn't very useful if you can't patch and rebuild it. Especially if you want to create an RPM. Or even do some heavy lifting in C++, and pipe-fitting in JavaScript. Another drawback is that Jaxer is dependent on Aptana to survive. Will Aptana be around in another 5 years?

The Apache foundation has been around for years and isn't going anywhere. They have bsf, which allows one to embed JS in a JavaBean, which brings us back to Java. On the one hand: Java! RUN AWAY! On the other hand: hiring Java programmers should be easy. And doing any heavy lifting in Java, then doing the high-level gluing in JavaScript might be OK.

Mind you, this is all speculation; we are still a year or more away from knowing if we get the contract.