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.
XPages was confusing to me at the beginning. It seemed like a step backwards. Squirreling bits of JavaScript into the XML code, into what clearly should strictly be a presentation layer, mixing business logic with presentation logic, after spending years moving code from buttons and hotspots in forms into script libraries? It doesn’t make sense – until you understand the central assumption of IBM, which was that we would not get Java. Too difficult. The dumbo domino developers will never get it. They only get quick-and-dirty RAD.
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.
In the face of the obvious scarcity of resources that IBM has devoted to the Notes platform, it is such a crying shame to have invested so much into SSJS and the whole formulation of formula language as JavaScript functions. (An impressive achievement, but a misguided one in my opinion).
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)
And it’s also a misnomer: It’s not at all JavaScript being run on the server (like node.js would do, blindingly fast on top of Google’s V8 engine). At runtime it’s really running as Java. Guess why it takes so long to build your projects? Our poor computers have to interpret the ‘JavaScript’ and translate this into Java code. And your guess is as good as mine when it comes to the new versions of JavaScript – will IBM update too, to ECMA 5 Strict, say?
My tip: circumvent SSJS as soon as you can and go straight to Java.
very good opinion. I totally agree. I hate SSJS. And try to avoid it as much as possible. SSJS is nothing, not CSJS, not Java, not @Formula language.
As Tim Tripcony mentioned in his session with Paul Withers at UKLUG in Cardiff, SSJS is just at string and will be interpreted by the JVM to convert it to Java, so why don’t write your code directly in Java.
Expression Language is key, it is the glue to bind the V with the C in MVC ;-).
Lately I did Enterprise Java project with Spring Framework and so on and I found out that EL was not invention by IBM, it is JSF based language.
So forget SSJS, only use real Javascript in combination with Java as backend. It is also a better approach for your career, because real Java en Javascript developers are most wanted.
In my experience a typical domino developer is a person that has learnt to work round limitations to produce a workable solution despite rather than because of a framework
Andrew, I totally agree. Go for Java – and learn the JSF lifecycle and you are well on your way. If in addition you can create a sensible MVC architecture in your application then it is even better 😉
I only use SSJS in those very few places where EL cannot do it form me (like including arguments) – and there are some very good references on EL that one can use to understand how much you can do with it.
Andrew – I think you’re both right and wrong at the same time.
I like to say that “SSJS is a waypoint – it’s not a destination.” Start with SSJS. Learn it, use it. But don’t stop there. Keep going and get to Java. It’ll be better in the long run.
But to be clear, it is possible to build decent XPages apps with just SSJS. There’s no need to limit your toolsets.
Personally I don’t think it’s practical for a Notes Client Dev or Domino Web dev to transition straight to XPages/JAVA without going though XPages/SSJS. Today in 2014 maybe it’s a little easier with all the information available. Back in 2009? No freaking way. It’s a little easier now in theory with the Java Design element and all the community information on the subject. Sadly there’s little to no information from IBM that I’m aware of.
SSJS is NOT the root of all evil. There is however, arguably, a better way to make XPages apps using Java. I also like to say that to XPages. SSJS is @Forumula language and Java is LotusScript. I lot of decent client apps were made with just @formulas. Then LotusScript came along and a lot more capability was created. To me that’s SSJs vs Java.
While SSJS is not evil – Java is also not to be feared. It’s a lot more like LotusScript then one might think. Paul Withers does a good demo of converting LotusScript to Java.
There’s a ton of reasons to want to use Java in XPages. You’ve listed some of those and I think they’re prefectly valid. We could probably go on and easly make a top 20 list of reasons why Java is better then SSJS. And I’d agree with them.
But I think we need to be careful of the presentation of the message. If all a developer can handle to begin with is SSJS then fine. XPages will work with that well and you CAN build apps with SSJS. But it would behoove you to keep an open mind regarding Java with the goal of eventually learning it. You’re XPages apps will gain far greater capabilities.
David,
It’s particularly gratifying having a response from one of the unsung heroes of the community. I’m a big fan of yours!
I find your point about ease of learning well argued; I must admit to being prejudiced in favour of Java since I tried to use it as much as possible for classic Notes development – so the whole Java world was not scary, and Managed Beans a snap to understand.
If your context is ‘How can I build an XPage with relative ease’ then, yes, I agree, SSJS does have its place. But if you’re looking at XPages development with the mindset of ‘What can I learn that will be useful for me as a developer in the forseeable future’, then SSJS is a time-wasting evolutionary dead end.
If you make a map of all the technologies involved in an XPage, there are some bits which don’t move, which are limited by the resources that IBM has, and other bits which are dynamic and evolving really fast – I’m talking about all the wonderful CSS frameworks, the JavaScript frameworks (i.e. angular), the Java Libraries, Eclipse. We can power-charge an XPage by using all these technologies which are being continually being improved on by a really large community of developers – that is the future, and I am loth to depend on those Xpages parts where I don’t see any investment.
I can very much agree that Java is the way to go. When I first started XPages it was a good transition from lotusscript to SSJS to Java. I also have found other developers that still do quite a lot of lotusscript find SSJS easier to understand manly. 80/90% of the server code I write these days is Java.
As for domino developers in their 20’s, I definitely know of one 😉
Having worked with Domino developers at all levels I would have to agree with David. Java is not for everyone and for those that have come up through the traditional Notes path (and have the gray hair typical of our age group!) SSJS is an easier transition. I know I am guilty of this too. I had an XPage (our TLCC catalog) that used a ton of SSJS and view lookups with partial refreshes, etc. to let users drill down into our catalog. I finally moved all the data into an application-scoped bean with lots of EL. I compared the performance and while it was about 2-3 times faster now the SSJS way of doing things was only about 300ms to generate a page. Quite acceptable. What I found challenging was developing the object in Java to reflect the data and how I wanted to access it. The actual coding part was not the challenge (thanks to Google and all the great stuff out there for both Java and XPages).
Remember Notes/Domino has always been a rapid App. Development platform. That was what we always told everyone. You can quickly pull together an application with full security using Domino. So, moving to a new paradigm of Java and MVC takes quite a leap from this old paradigm…
Agreed. Learning SSJS is a complete waste of time. If you code for Domino, and you still don’t “do” Java, you’re a dinosaur.
Andrew,
First, thanks for the kind words. I really appreciate it.
I think we’re pretty much on the same page here overall. I totally agree that time spent on SSJS is not portable to anything else while time spent on Java is. So that’s a great benefit to the developer. I’m not sure if I totally think SSJS a “waste of time”.. it’s just not portable or anything with a future. Sometimes you still need to use some @Formula in a view selection or column… or maybe LotusScript in an Agent. (Even though I do a ton of Java in XPages I’m still using LotusScript for agents). that’s not portable but can be the right tool for the job at hand.
My only concern is that when we have this type of conversation or post, especially with an “all or nothing” title like this post has, it seems to me that new XPages developers read it and think XPages is a waste of time if they don’t already know Java. I think this is a problem and that we just need to temper that message when we have this discussion. You can build apps without Java of course. Like I said, there’s probably 20 good reasons to want to get to Java and skill portability is just one of those reasons.
Right or wrong learning Java is scary for some. In the end I put up a huge fight because I didn’t want to move to Java. Some of that fight is well documented. haha But I was wrong. I was scared and I didn’t know where to start. I was lucky that my friend Jeremy Hodge spent time with me getting things explained and sorted out. There’s no way I could have picked up Java (for XPages) without him at that time. Not everyone has that resource to go to. Which is one of the reasons why NotesIn9 exists.
Honestly I think the next phase of XPages development is to use XPages as an API. And have it spit out custom REST or JSON whatever to feed either standard controls inside XPages – like a Select2 control, or calendar control, or even to feed non XPages applications – jQuery Mobile, Appcelerator, Angular, whatever. I’m trying to get shows like this on NotesIn9 right now actually.
Just my 2 cents…
Great post.
If I’m completely honest, I might just be one of the Samanthas of the programming world who have made a living out of Domino for quite a while now. I like simple solutions that get the job done and I’ll have to admit I’ve often been guilty of going with a quick and dirty solution that works and “hang the consequences”. I’m happy that they included SSJS – even if I’ll happily acknowledge that your points are all valid.
In my particular situation, the move to XPages has been made a little bit more difficult by the need to keep up with the workload and not fall too far behind by implementing new stuff in a new technology at newbie speed. I haven’t been all that successful on that front, to be honest, but if it had have been java-only and a steeper learning curve, I might have ground to a halt completely.
The great strength of old school domino (back when it was still a valid choice among the alternatives) was that it stacked up really well against the competition when you looked at the time requirements for an Average Joe programmer to create something that could deliver business value. I think IBM has to keep this in mind with XPages and not lose sight of this idea. I think the balance is good – the java world gives incredible power and unlimited options to developers who want to do really great things with the platform, and SSJS lets the quick and dirty guys get stuff out there that just works.
On the positive side, having this great new world available to explore is a great motivation for guys like me to get serious, spend more of my spare time studying, and actually improve as a developer.
Well… I have seen tons of Notes developers who already find JavaScript scary. in SSJS you can keep your code inside the page lean too. Obtain the variables you need (from the UI, a state etc.) and call a method in a SSJS object. Of course…. if all you did was maintaining that 1500 lines code in a querySave trigger, the idea of objects and functions are scary. 🙂
On the other hand: once you see SSJS as the small glue between some UI and your Java model, it isn’t a sing of condecension, but a handy way to keep things light and adaptable. David’s comparison @Formula/LotusScript is like SSJS/Java makes lots of sense.
… of course things could change once Domino uses the Nashorn engine and runs JS native on the JVM
Well stated, and I’m in agreement. Domino serves RAD needs better than anything else on the market. If IBM were to abandon that market and try to compete directly with hardcore JAVA or ASP platforms, it would quickly find itself in a ‘too little, too late’ situation. By not denying its roots, Domino is able to migrate the RAD community while continually refining the JAVA side.
Dear Stephan,
Many commenters have stated that there are tons of Notes developers still struggling with these concepts; I see that it was arrogant to assume that we would all be comfortable with these notions and stand corrected.
I would join Frank’s comment that the glue between the UI and the Java model should be EL and not SSJS.
… And I’m really excited about the notion of our own little, fast JavaScript engine on the server!