Apparently my recent appearance on hanselminutes caused some stir on twitter. People think I was laying to heavily into JavaScript as a feasible platform for server side development (node.js, etc.).

This might sound odd coming from someone that has built a JavaScript runtime, but my point of view after having developed IronJS is that there are a couple of critical problems with JavaScript that prevents it from ever being a viable alternative as development platform for server application development.

Lack of language defined modules and namespaces

The language doesn’t define the concept of a module or namespaces, several work-arounds exist like require in node.js but there are several problems with using something with require.

• It’s implementation dependent, which means it’s not standardized and you can’t count on it existing in every javascript implementation.
• You can re-write anything in any namespace at will, some people like this since it allows for something called monkey-patching. However this just leads to a whole new can of problems.
• You can replace the require function, or any other function for that matter, at a whim or by mistake leading to very hard to track bugs.

ECMA specification doesn’t define how to organize code over several files

This ties into the previous modules and namespaces, but it’s such a major thing thing it has to be mentioned separately. The specification does not define how to load code from a file, this might seem like a minor issue as node “solved” it with require. But in reality the possible issues that can arise here are many.

For example, as already mentioned, require is specific to node.js and doesn’t exist on any other major platforms. There are major problems with having non-standardized and implementation specific behavior that effect such crucial parts of a language as loading code.

The most obvious one is how the code actually is loaded, for example:

require("foo");
require("foo");

Is the “foo” module/file loaded/executed once or twice?

There’s also more subtle problems, such as: When you use require to load a piece of code, is the code executed in the global environment or the loading context?

(function foo(bar) {
    require("foo");
}({x: 1}));

Is the code inside the “foo” module/file executed in the global scope or in the context of the foo function with “foo” and “bar” already bound? Most people will probably say “in the global scope”, but the designers of the PHP include probably won’t agree.

And before you mention CommonJS: It is what some people think is correct and does in no way represent some type of standard

Very small standard library

The standard library, as defined by the specification is incredibly small (compared to the Python standard library, or the .NET BCL, etc.) and only gives you access to the most basic operations, not even I/O is included. Sure you can build your own library for a specific implementation, but it’s not going to be universal and it will tie the code that relies on it to that specific implementation.

Language problems

If you’ve ever written any moderate amount of JavaScript code you’ll know that there are several problems with the language itself, things like with, eval or the inner quirks of how JavaScript applies the concept of equality. The http://wtfjs.com/ is a good read for some more WTF? moments.

Null vs. undefined

JavaScript has two “this is not here/doesn’t exist” values, they’re subtly different and undefined is the one that is most common. But why would you even have two different types of ‘nil’ to begin with? I know of no other language in existence that does this (I’m sure someone reading this is going to dig up another language that has this).

Context sensitive function keyword

In case you didn’t know, these two functions are not identical:

http://wtfjs.com/

(function bar() { })
function foo() { }

Finding out the difference I’ll leave as an exercise to the reader.

Limited set of data types

• Only 8 byte float numbers, how would you even interface to a database schema that has a 64bit integer column?
• No fast (as in native) arrays
• No int, byte, etc. number types

Fragmented runtimes

While pretty much every single one of these problems could be fixed by either extending the specific runtime you’re using or by ECMA releasing a new standard, it’s just not that simple. Assuming you extend the runtime you’re using to allow for things like native/fast arrays and you define a module/namespace solution like node.js has done, now any code you write will only run on that specific runtime with your extensions which punches a big hole in the “same language everywhere”-argument that you hear every day on twitter (and it really is server-side JavaScript’s only claim to fame).

So what if ECMA releases a new standard that fixes every single problem I’ve listed above (this is no way an exhaustive list)? I can currently count to about six different runtimes in use today (JScript, JeagerMonkey, TraceMonkey, V8, Chakra, Carakan, Rhino). And that’s not even counting the small emerging ones like IronJS, Jurassic, Jint, etc. that are platform specific implementations for embedding. A lot of these runtimes are available in different versions in different browsers and will never be upgraded, so you’ll have to exclude all those new features in our new utopia-style ECMA specification if you wan’t to be “cross-runtime” compatible (which you need for web development at least).

But what about node.js?

First I want to make clear that IronJS is in no way a competitor to node.js, IronJS is a runtime – node.js is an application server that uses another runtime (V8).

Node is decently fast, sure. But it’s nowhere near as breathtakingly fast as it’s zealots want you to believe. Nor are any of the ideas it employs new or groundbreaking. It also comes with several warts that have been inherited from JavaScript which forces you to do manual continuation-passing style. I just can’t see the reasoning behind using a language that wasn’t designed to be used in this context, it just feels like one big hack (albeit a pretty well preforming hack).

Assuming you want to run an asynchronous SQL query in node, it’d go something like this:

db.query("select * from person", function(result) {
    print(result);
});

Now compare this to a language that actually was designed (F#):

async {
    let! result = db.query "select * from person"
    print result
}

Conclusion

The way I see it is that JavaScript has dug itself into a hole that is impossible to get out of, at least if you wan’t to keep “same language/code everywhere” idea alive. And if you’re not, then why would you use JavaScript when so many better (and faster) alternatives exist? There are so many problems with the language, I’ll list a couple more that I haven’t touched on but I think this image illustrates my point of view better then any words could:

• The scoping of the this keyword
• Switch case fall through
• Automatic semicolon insertion
• Bitwise operators that work on doubles
• Type wrappers and type conversions, new String(“foo”) vs. “foo”
• The new keyword makes function behavior dependent on the context they’re called from
• with and eval (it doesn’t hurt to mention these again)
• The arguments object which is an array, almost. Except it’s not. And it’s also magically bound to the parameter variables
• The typeof operator
• The global object

Note the Jint failed on several tests and those have a zero as result. Click on the image for full size.

We’ve still got a long way to go until we reach our goal (within 300% of V8), but it’s looking good so far!

Update: Here’s the total test score also

IronJS is an ECMAScript 3.0 implementation built on top of the Dynamic Language Runtime from Microsoft which allows you to embed a javascript runtime into your .NET applications.

Thanks to

• John Gietzen for all his work on ECMA3 conformance whom without this would not have been possible
• Christian Knutsson for the awesome logo

Changelog

• ECMA3 Conformance
• Added 5,500 ECMA3 conformance tests with over 30,000 assertions
• Major API refactoring moving all Module/Functions located in Api.fs to their appropiate classes in Core.fs instead
• Re-implemented the AST analyzer to make it single pass
• Re-implemented variable handling allowing for faster and easier compilation
• Removed the dependancy of Microsoft.Dynamic.dll for CLR4 projects
• Removed dependancy on FSKit
• Implemented the Date object
• Implemented the RegExp object
• Implemented missing functionality on String.prototype (match, split, search, replace)
• Implemented F# operators ? and ?
• Implemented F# operators for all common binary DLR expressions
• Implemented a Sputnik test suite runner, courtesy of John Gietzen
• Implemented a proper REPL console, available in the aptly named “REPL” project.
• Implemented dynamic invoke operators for calling IronJS functions with an unknown amount of arguments
• Implemented a new F# based lexer and parser which allows IronJS to drop the dependencies on Xebic.ES3.dll and Antlr.Runtime.dll
• Cleaned up and removed a lot of old/redundant code
• Renamed ObjectClass to “Schema” and split out the dynamic functionallity into it’s own DynamicSchema class
• Replaced the FunctionCompiler class with an F# function with the signature IronJS.FunctionObject -> System.Type -> #Delegate
• A lot of smaller improvements to code stability and readability
• Added debug constructs in big parts of the codebase that only gets compiled when the DEBUG flag is set
• Refactored several constructors in the IronJS.Ast.Tree union to be more obvious
• Unified error handling, so it all passes through IronJS.Error and its members

Binary

• CLR4 x64
• CLR4 x86
• CLR2 x64
• CLR2 x86
• Mono 2.10 x64
• Mono 2.10 x86

Source

• 0.2 tag on github
• master branch on github

Information

• IronJS Blog
• IRC: #ironjs @ irc.freenode.net
• Twitter: @ironjs

What it does is it introduces a new symbol, @ – stolen from F#, which gives you access to the syntax tree of a function during runtime and allows you to modify it as you see fit and then compile it to a regular JavaScript function. While it could be abused to no end it allows for some pretty interesting possibilities. The example I’m going to show creates a function which reads a property out of an object, and optionally compiles a console.log statement into the function body.

function makeLoggedPropertyReader(includeLog, propertyName) {
    // Note the @ symbol infront of the function keyword
    var quoted = @function (x) {
        if(x) {
            console.log(x);
        }

        return x._;
    };

    // This is how the quoted structure looks like,
    // it's basically a syntax tree that you can
    // traverse, modify as you see fit and then compile

    /*
    quoted = {
        type: 19, // function
        body: [
            {
                type: 18, // if statement
                test: {
                    type: 5, // identifier
                    value: "x"
                },
                trueBranch: [
                    {
                        type: 9, // method call
                        target: {
                            type: 5, // identifier
                            value: "console"
                        },
                        member: {
                            type: 5, // identifier
                            value: "log"
                        },
                        arguments: [
                            {
                                type: 5, // identifier
                                value: "x"
                            }
                        ]
                    }
                ],
                elseBranch: {
                    type: 0 // void node
                }
            },
            {
                type: 25, // return
                value: {
                    type: 43, // property accessor
                    object: {
                        type: 5, // identifier
                        value: "x"
                    },
                    name: {
                        type: 5, // identifier
                        value: "_" // the value we're going to replace
                    }
                }
            }
        ]
    }
    */

    // The first statement in the qouted body
    // is the ifStatement, which we will conditionally
    // remove depending on the boolean value of includeLog
    if(!includeLog) {
        quoted.body[0] = Quotations.voidStatement();
    }

    // Pull the second statement out of the function body
    var returnStmt = quoted.body[1];

    // Pull the value node out of the return statement
    var propertyAccessor = returnStmt.value;

    // Set the value of the "name" node of the property accessor
    // to the string value of the propertyName that is passed in
    propertyAccessor.name.value = propertyName.toString();

    // We've modified our qouted expression
    // and we can now compile it so it
    // becomes a
    return quoted.compile();
}

// And here we'll use it:

var logged = makeLoggedPropertyReader(true, "myProp");
var notLogged = makeLoggedPropertyReader(false, "myProp");

var myObj = {myProp: "hello world"}

var xValue = logged(myObj); // will return and print the value of myProp to console.log
var xValue = notLogged(myObj); // will only return the value of myProp

I’m glad to announce that with some clever use of reference cells I’ve been able to both eliminate the need to re-build the AST and also, due to having access to the internals of the new TDOP-based parser, manged to make it require only a single pass over the syntax tree, the performance difference is pretty staggering.

As you can see with both the new parser and analyzer it’s a whopping ~13x faster then the old ANTLR based parser and multi-pass analyzer. It’s also ~4x faster then the new parser with the old multi-pass analyzer.

I’m glad to announce that I’ve finally gotten around to do this and that the new F# based lexer and parser were pushed to the master branch on github earlier today. I also decided to remove the dependency on Microsoft.Dynamic.dll which I only did about ten calls into. This means IronJS now only requires FSKit other then itself, the plan is to merge the FSKit functionality that IronJS requires into the IronJS project itself so it will only be one DLL.

Another great benefit of rewriting the parser in F# is a pretty nice speed boost, if I can direct your attention to the chart below you will see that the new lexer and parser is about eight times faster on the jQuery 1.5.1 (uncompressed) source code. This of course means that IronJS i getting even faster then it was.

Also, keep your eyes open for the first 0.2 beta that will arrive shortly.

Update:

I got a question on IRC on how the profiling was done, so here’s a description of it.

• System.Threading.Thread.CurrentThread.Priority was set to System.Threading.ThreadPriority.Highest
• Timing was done with the System.Diagnostics.Stopwatch class
• The source code was loaded into memory before lexing and parsing so no disk penalty would occur
• The machine, which is a i7 Quad Core with 8Gb of ram, was restarted between each test and as many processes as possible were killed when Windows was done booting
• The projects were compiled in release mode with full optimizations and no debug info
• Each test was ran ten times before timing started to make sure all assemblies were loaded in memory and there would be no JIT overhead
• After the ten warm-up runs the test was ran 100 times, the ten fastest were picked and averaged

If there are any flaws in the above process please do point them out and I will re-do the test and post new results.