XPages And The Death Of LotusScript
Wednesday, July 8, 2009 10:25 AM
There have been some mussing in the 'Yellow Bubble' about how XPages and the move to Server Side JavaScript is going to be the death of LotusScript and I just have to say I completely disagree.
When people first starting seeing XPages, many for the first time at Lotusphere, there were big oohs and awws, XPages was destined to completely change the way many current developers write web applications for Lotus Domino, and from my own point of view it really has changed the way I write web applications. No more having to write massive LotusScript libraries to output the HTML code that I want to send to the browser via a web query open agent, Just design the XPage and custom controls, add in small bits of SSJS at different point to show/hide/compute stuff and bingo, a fully functional web application with a lot less work.
With XPages announced to be accessible from the 8.5.1 Lotus Notes client there has been some concerns that there will no longer be a need for developers to learn LotusScript, why would you need to bother to learn LotusScript when you can create a write once deploy anywhere application but that is where the entire argument falls down for me. There are times where you need one interface on the web and a different interface on the client. While it might be possible for you to write your application so you can do everything from a web based interface that does not always mean it's the best thing for you to do. There are lots of things in the Lotus Notes client that are much easier to do in or are just not offered through a web interface so there will always be a need for developers to think about creating a full client experience as well as the XPage experience.
Lets not forget that not all applications will be web based. There is no way I'm ever going to put a web interface on some of our internal applications, especially our HR system that contains secure information protected by document encryption keys. If I ever need to write a web interface for our HR system I'd rather sync a subset of the data that needs to be on the web into a separate database and put the interface on that database, thus protecting the original source. In fact I already do this for our internal phonebook application ( which I must upgrade to XPages at some stage ).
There is also the question about agents, even in new applications your going to need to write scheduled agents, currently you can write them in LotusScript or Java and I personally don't see IBM getting any benefit from adding SSJS to the mix here as there are aspects of SSJS that would not fit, for example scope variables, context and facescontext. An agent version of SSJS would need to be different from the XPages version of SSJS so this would just be introducing yet another language for IBM to maintain into the mix.
So if your sitting on the sidelines wondering if you need to need to learn LotusScript or SSJS then my advice is that you learn both, you can use the skills you get from learning LotusScript to speed up your leaning of SSJS and vice versa. LotusScript is not a dead language and I certainly don't see it disappearing from your applications even if you make the move to Xpages.