Scott Souder was recently extolling the skill of the IBM developers and added as an aside “these are not your average domino developers”. I flinched at the statement and thought defensively “does he mean me?”
The more I think of it, though, and it becomes obvious that this is a central assumption that affected the design of XPages. It’s even there, in the introduction to the mastering XPages book.
I would like to humbly submit to IBM that domino developers nowadays are not an unskilled community, and that its modeling of who domino developers are needs some updating, in the hope that this will positively affect further design decisions. We’re not the Samanthas of the programming world.
It’s immediately obvious at any notes gathering that we are not the youngest community – I rarely see anybody in their twenties, for instance. It’s therefore obvious that we are all experienced. Even those without a computer science background (and this applies to me) has learnt, the hard way, that it’s the maintenance and debugging of code which is complex, not the writing. I learned, the hard way, that copy-pasting code is a shortcut which kills you a couple of years later. I learned that structuring code cleanly, with small functions doing a single thing, ends up being far easier to maintain than two thousand lines of procedural code. Making the switch from procedural code to object oriented code helped tremendously, along with the concept of separating business logic from the displaying logic.
Then, in the course of my XPages learning curve I stumbled into managed beans, and everything clicked into place. This is where the beauty lies, this is where I can put my layered, easily debuggable, easily testable code. It’s easy to bind to the XML source, and the Expression Language is concise and powerful. And yet these sections are under-documented, the know-how gleaned from stack overflow and numerous blog entries on the subject made by us, dummy domino developers.
The resources could have been better spent elsewhere. Learning java is but one of the challenges of learning XPages, and it’s a challenge for which there are tons of documentation.
There’s often a picture made about misguided security in IT – a brand-new lock on a rotten door doesn’t increase your security. Here there is a parallel with misguided condescension – Removing Java out of the learning curve is just a small contribution to making XPages simpler. There’s a plethora of new stuff that we must learn, we must get our heads around conflicting terminology (e.g. Notes View, JSF View, Eclipse View), a lot of functionality comes from knowing that the CSS class you need is called ‘lotusInlinelist lotusUtility’, there are missing tools such as JUnit, refactoring, renaming so you end up having to do a lot of things manually…
SSJS annoys me because of the underlying assumption – I am dumb.
SSJS also annoys me architecturally. It breaks the MVC model pretty badly. It probably also affects performance and scalability (although I have no figures to support this)
My tip: circumvent SSJS as soon as you can and go straight to Java.