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.

6 comments on “XPages And The Death Of LotusScript”

You actually can write agents in SSJS already. (Ok — it is a hack). Write an XPage and populate one of the load events with the code you want to execute.Then write a scheduled agent as @Formula that does a @URLOpen().Or a Java agent that does a HTTP GET on that page. stw

I would agree with you. xPages is nice, but for most Domino installations it’s years down the road. I just got a customer updated to 8 from 6.5, they plan their next upgrade for end of 2010. They run a major app that I built in 2000 using R5. If I told them they had to re-write it, they they would look at other technology instead. I’m planning on adding R8 features such as composite apps but no xPages.

While I think you’re correct in that LotusScript will be around for a good while, I’m personally counting the days until I can be rid of it forever.After tinkering around with elegant languages like Ruby and then finding a lot of the same kind of expressive power in JavaScript, it’s just painful to go down to LotusScript with its developer-hostile anachronisms or Java with its excessive verbosity (though it’s better than it used to be since 1.5).Though it’s not perfect, the more Notes development can be done in JavaScript, the better.

The highway is littered with the corpses of people who have predicted the death of LotusScript, since about 15 minutes after it was first released, in 1996.

Until Java/JavaScript becomes as easy to learn/use as LotusScript is, and until someone offers a migration path to xpages (or anything else) for the millions of lines of working LotusScript out in the wild, LotusScript will never completely disappear.