XPages And The Death Of LotusScript

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.