Tip of the Iceberg

Category xpages
I've been following Peter Presnell's posts about his experience with XPages, and am looking forward to seeing what code will result. Anyone familiar with his .Domino framework knows that he's one of the best LotusScript developers anywhere. So his initial reaction was a bit surprising to me. In particular, his most recent post made a few assertions about server-side JavaScript that conflicted with my experience thus far with the language. Since I haven't seen any response from IBM thus far, I'd like to propose a few counter arguments about the language in the hopes of clearing up some corresponding misconceptions.

Server-side JavaScript is not JavaScript.

Syntactically, it is almost identical: semicolons, curly braces, and so forth. However, the language is really just a veneer - every variable, every object, every function is interpreted at runtime as Java. Assigning {} to a variable, for example, is actually instructing the server to create a Java Map descendant. This is why IBM's implementation supports most existing @Functions: the server isn't executing the code as JavaScript, it's interpreting it in order to execute Java code, so any syntactical deviation is fine as long as IBM's intepreter knows how to respond.

Perhaps I'm just splitting hairs here - after all, the client- and server-side LotusScript runtimes sit atop layers of C, so any LS code we write ultimately results in the creation of C objects. Yet LotusScript can rightly be considered its own language, with plenty of strengths and weaknesses, some particular to itself, others shared with other languages. But I think this is still a crucial distinction, because the implementation of SSJS in XPages is its own beast, and acknowledging that makes it easier to understand how we can make it work for us and not against us. This is not just a matter of remembering that it has no window object and alert() is pointless; rather, remembering what's going on "under the hood" helps to structure the objects and functions we define in ways that maximize the language's strengths.

Server-side JavaScript is strongly typed.

Peter's exactly right: the lack of strong typing in traditional JavaScript is often a crippling limitation, which is why I'm thrilled that it is a limitation that SSJS does not share. As more and more XPage applications emerge, you're going to see a lot of code that looks like this:

var NAB:NotesDatabase = session.getDatabase("","names.nsf");
var peopleView:NotesView = NAB.getView("($Users)");
var myName:string = context.getUser().getDistinguishedName();
var userRecord:NotesDocument = peopleView.getDocumentByKey(myName, true);
//...

The colon syntax is how you declare a variable's type. In traditional JavaScript, the typeof operator returns one of only 4 possible results:

1. "number"
   
2. "string"
   
3. "function"
   
4. "object" = everything else...

SSJS objects are Java objects. Java is strongly typed. Ergo, SSJS objects are strongly typed. Like regular JavaScript, typeof will return "number" or "string" for primitive types (and it shares the silly limitation of calling any array an "object"), but invoke typeof on the global session variable, and it returns "lotus.domino.local.Session". Invoke it on the result of any valid call to getComponent() and you'll get "com.ibm.xsp.component.xp.XspCommandButton" if it's a button, for example, something very similar if it's any other core control.

As Nathan and I both mentioned in the comments on Peter's post, Squawk is a textbook example of an application that relies heavily on the strongly typed nature of SSJS. Nearly all of the code is in the form of custom Java classes we wrote that are simply being instantiated within an SSJS context. Every time you load a transcript, add someone to your flock, or post a new squawk, the application is executing two or three lines of SSJS that, in turn, execute dozens, or even hundreds, of lines of Java code. It's like LS2J without all the memory leaks. We could easily have written most of what it does in "pure" SSJS, only using Java classes where an equivalent construct wasn't built directly into the language, but structuring it the way we did had numerous advantages, most of which I'm not even permitted to reveal. The point is that this flexibility allows us to take full advantage of the benefits of strong typing without losing the fluidity of the JavaScript syntax... we can still create inline objects and arrays, anonymous functions, and everything else that is appealing about JavaScript.

One additional note about strong typing: the colon syntax is entirely optional. At runtime, a call to session.getDatabase is going to return a NotesDatabase whether I explicitly indicate that in the code or not. Likewise, DDE's code assist is pretty good at guessing the return type of a method call even without type declaration. But including the declaration ensures it knows what it's looking at... and so does anyone who has to maintain your code, including you.

JavaScript doesn't need classes.

I know, that sounds heretical coming from an OOP fanatic. But it's true. When used properly, closures render a classical structure nearly irrelevant: JavaScript objects can have private properties and methods, and can be extended to provide new members while still inheriting the members of a parent object. So... what more would we want? Such a claim deserves its own post, so as time permits I'll provide an example of this in action... and it doesn't involve a single use of .prototype.