Let’s face it, Server-Side JavaScript is the most powerful and flexible language that I have ever come across, in twelve years as a Domino developer. Yes, you need to build a few muscles to automatically type commas instead of semi-colons in @Formulae and learn how to create a vector for doing getDocumentByKey against multiple columns. But whether you come from a Domino or a web development background, there is the flexibility built in to leverage the skills you already have to manipulate strings, handle numbers, manage conditional statements and much more. Plus you can include Java code in SSJS, vastly increasing the resources an XPages developer can draw on.
Coding in SSJS is considerably quicker than coding the same functionality in CSJS because of in-built partial refresh functionality. Only today I heard of a developer wanting to code in SSJS to handle radio groups because of an aversion for doing the kind of looping that’s needed to get values and update the page via CSJS. And at the start of the day two developers were discussing how they feel XPages is as quick as Notes Client development once you get to grips with it. I’m not sure I would agree – there are always new gotchas to come across and CSS conflicts can really mess up your look and feel, causing hours of time and extra bits of code to get pages looking just right. But I would definitely agree that it’s light years ahead of what traditional Domino for the web can do. And much of that is because of the integration of SSJS.
But as with most things there’s a big ‘but’. Matt White has just blogged about the benchmark for debugging, a new Flash debugger based on Eclipse. An SSJS debugger was raised in Domino Designer sessions at Lotusphere 2011, so I’m sure it’s being worked on. Hopefully the underlying Eclipse version Notes and Designer are based on will not cause too many problems.
But the debugger is not the only issue. From what I can tell, the SSJS editor is based on the JavaScript editor available for Designer. The limitations of the JavaScript editor are probably not an issue for XPages developers. But place those same limitations in the SSJS editor and they become quite painful.
The biggest is the frustratingly limited compile-time validation. For example, a basic one, picked up immediately in the Java editor. Try doing sessionScope.myVal == “Test”. If it’s a comparison, it should be in parentheses, otherwise it should be captured as invalid because there should only be one =. Yes, the solution is to always use get and put, but as human beings we tend to take shortcuts. This is why for years we’ve used the dot notation for setting fields in LotusScript (and why we have to add validation to our applications!). Do the same in SSJS and again, compile-time validation doesn’t capture it. I had the brainwave that perhaps this was because the NotesDocument object could be extended by using prototype, like you can extend the String object in CSJS, but no. Another one, accidentally miss out ‘var’ when trying to initially set a variable. It fails at runtime with a message that’s not particularly helpful, but because global objects are known, couldn’t this be captured at compile-time? Sometimes short cutting code throws no error at all, like using copyItem(doc2.getFirstItem(“myField”)). And it’s not just validation. In LotusScript and in Java we have code templates, we can hold down Ctrl and click to navigate around functions. Compared to these editors, the SSJS editor is a very poor sibling.
I would hope that these pain points are evident to XPages developers at IBM and something is being done about it. Because with a debugger and a decent editor, SSJS would be a real joy to use. At the moment though I find myself much preferring to get to grips with Java.
Couldn’t agree more. I love the power you get from SSJS, but I’m constantly struggling with the lack of real debugging data, and the confusion between datatypes – notes document vs. xspdocument, for example. Sure, you can fill your code with error traps and pseudo-breakpoints – how many times have I written logging statements simply saying “Got here OK”? – but a decent debugger built into the IDE would be a godsend. This is routine grunt work – the IDE should be doing it for you. Every minute you spend putting in debug or trap code is a minute you could have been spending doing the actual job you’re trying to get done.
It’s not helped by the fact that my JS skills are patchy anyway, and I rarely last long without a reference browser tab open at w3schools (and another couple elsewhere, since w3schools isn’t always great).
“With great power comes great responsibility”, they say. I reckon they forgot to add “and great need for good documentation and toolsets”.
IMHO the difficulty using and debugging SSJS will be a major impediment to corporate developers coding in xpages.
In my experience BPs are reskilling in Java for this reason but it is a big ask for many corporate developers – possibly even enough to drive them to another platform ?
Any conversation about xpages being RAD is nonsense when there is no debugger for the primary language.
Can you remember how refreshing it was when you moved from formula language to script and realised that you could loop and debug ?
To be honest I never used the “new” formula looping because there was no debugger.
I once blogged that the lack of a debugger was adding at least 10% to every job we do. The feedback I got was that this was far too low a figure.
If IBM is serious about this being an efficient platform for development they need to address this in 854 or sooner. I wonder could they release a new designer via open to ? Obviously not open source.
That was openntf before auto correct got hold of it
I agree 100%. It’s worth noting that IBM reaaaaaaaally knows that they need to get a SSJS debugger.
Unfortunately they would need to be on Eclipse 3.6 to get there. DDE runs on 3.4, because it’s shackled to the Notes client’s version. I can’t say much more since I’m in the Design Partner program, but ask yourself this: how could IBM tackle that problem?
@Erik Your question does throw up some interesting ideas, considering that Eclipse is extensible and an XPages-ONLY IDE would require less functionality. Hopefully any move will look at improving the JavaScript / SSJS editor as well.
@Sean I would hope that if corporate developers are already on Notes they would welcome the benefits of XPages. And, if not, I think there are still a lot of strengths that the weakness in the user experience of SSJS still outweigh.
@inteac – I believe 8.5.3 uses the Eclipse editor for all JS/SSJS now
It does look better and the outline and reference areas seem more useful. But unfortunately validation seems no better. Templates would be a huge help, especially as ‘Template Proposals’ are a checkbox in the preferences under JavaScript – Editor – Content Assist – Advanced. At the moment it’s rather analogous to the LotusScript editor before R6 with Option Declare not set.
Paul, I agree that hopefully they would welcome the extra functionality but no boss in the current climate will tolerate a drop in productivity ( or increase in head count )
Xpages is definitely a slower development platform for the Rich Client than traditional Notes in a like for like comparison – it then becomes a cost benefit judgement as to whether the additional functionality is worth the additional cost.
A decent debugger and the compile time validation is therefore key.
To be honest I was bitten by the compile time editor thing just yesterday. In old Notes you could add an updated script library and if someone had changed a sub routine parameter the system would tell you. In XPages the first time you know is when you actually try the functionality.
This comes as a BIG SHOCK to the average Notes developer who does not generally run full system tests after changing some code. It also explains why developers on other platforms think so highly of automated testing systems.
Sean
Yes, I agree XPages Dev is slower than traditional Notes. But it’s significantly quicker and more flexible than traditional web development with Domino, even without the extension library. There are still some cross-browser issues, usually around CSS rather than functionality (the one exception being onchange / onclick). But in my experience there are many fewer quirks than in traditional web development in Domino.
The problem of parameter changes is something I’ve also come across when developing Java for XPages. Whether using refactor or just changing parameters, SSJS references are not updated, but the Eclipse platform provides us with a very strong search tool which was missing from the R8 designer. There are pros and cons, as often happens with change.
Great discussion – hope IBM developers are listening. Yes- there will always be pros and cons of a change and the next release of domino in susequent years should bring some releif for developers.