Over the years I have given a lot of thought to programming languages, especially as they relate to Lotus Notes development. I blog about it a lot. Yes Nathan I'm hitting them all over the head with a stick again.... I have expressed my frustration at the lack of development of the LotusScript language that is core to so many Notes applications. I have wondered about the lack of penetration of Java into the Notes development world. And lately I have been asking the question why SSJS and do we need yet another programming language in Notes? So just what is the best programming language for Notes?
:
The Case For LotusScript
Some may view me as something of a LotusScript biggot. I love the language and what it allows me to do with Notes. Basic was the first language I ever used. It was so easy to understand I taught myself by simply reading other people's code and experimenting. There was a time when LotusScript was more advanced than Microsoft's VBA but now it has fallen lightyears behind VB.Net. It is popular in Notes because so many people find it (relatively) easy to learn. It is popular because it can be used almost anywhere inside Notes applications (except View selection formulae, hide-when formulae and a few other spots). It is popular because so many applications are already built with LotusScript as its core. And finally with 8.5.1 we have a half-decent editor for LotusScript.
:
The Case For Java
In many ways Java is a superior language to LotusScript. It provides vastly superior support for Object Oriented Programming. It comes with an extensive library (framework). It is also one of the most popular programming languages. Two of the things that have been attributed to holding back Java in Notes (access to Notes UI classes and a decent editor) have both been provided in 8.5.1. And yet..... despite all this I do not expect to see a significant momentum towards Java anytime soon (outside of Eclipse, Expeditor, Plug-In development etc.).
:
The Case For Server Sided JavaScript
This is a completely new language, so why bother given I have all my existing code is in LotusScript, Java, @Commands (or a combination of all three)? Well for one thing it is presently the only language supported directly by XPages. There are ways to execute Java code and even more obscure ways to execute LotusScript code but I don't see these being very practical. So if you wish to develop Xpages you have little choice. And if you don't wish to develop with XPages you have little chance to use SSJS at the moment either! One of the key reasons to consider SSJS is that this seems to be where IBM is investing most of its time and effort on program language development for the forseeable future. But perhaps the most compelling reason (at least for me) is that when all things are said and done SSJS is probably the best match for Lotus Notes than any of the other programming language choices.
:
Yes you did read that right. The LotusScript flunkie is actually suggesting SSJS may be a better fit for Notes development than his beloved LotusScript. I have done a lot of SSJS programming over the past six weeks and the more I use it the more I like it. I have begun to realize the complexity in using SSJS is not with the SSJS language itself but rather learning to understand the complexities of Xpages. SSJS is not vastly different to LotusScript but it allows me to do things I could only dream about with LS. There are still areas left for improvement but if IBM are focusing on this language there is more chance these will be fixed than any of the 100+ ideas for LS posted on IdeaJam.
:
One of the key reasons I like JavaScript so much is that it is built on objects (and remember I am an OOP). Until recently I thought it was a weakness that JavaScript was so loosely typed. Now this seems to be such an asset. And this seems to fit in so well with whole Notes concept. Documents as a collection of fields that may or may not be present in any one document and may or may not be of the same data type in every document. Documents copied and pasted en-mass from one database to another (when allowed). Views that may contain a collection of doccuments of different types whose only association may be they share a few fields with the same name (if at all). And yes, love it or hate it there are none of those foreign key constraints that stop me adding whatever document I want to my database. And replicas of each database created just about everywhere just in case... In an ordered world of tightly defined tables with fixed columns, column types, key constraints and nullable fields a tightly structured language such as Java makes perfect sense. And C# with its interfaces, sealed classes, abstract classes, partial classes etc. is well suited to projects with 10+ developers. In the unstructured world of almost anything goes just get the application out the door as quickly as you can Mr/Ms. sole developer, multi-tasking Notes programmer -- a language such as SSJS seems to be an almost perfect fit. And not just for the minority of us who write OOP with Notes. For procedural programmers we have the nifty ability to invoke many of the @Functions as a standard part of SJS language. The bous for SSJS is that it shares the basic syntax with JavaScript, the dominant language for Web client programming. So after a while you get used to placing those braces around all your compound statements and you remember that different casing means a different variable/functions.
:
To put it simply, there is a reason we have many programming languages. Each has its own style. Each its own strengths (and weaknesses). The style I see in SSJS seems a very natural fit for Notes and a great many (but certainly not all) of the developers who are attracted to Notes.
:
Of course it is not a clear cut as switching from one language to another. We still have all those legacy apps to maintain. And there is no sign of SSJS being supported in any of the Notes Classic design elements or even agents real soon. So that leaves XPages, and the rub with that is for the Notes client, XPages really does not (yet) offer much outside of a glorified embedded browser (I can see the hate mail on this already!).... But that is today. IBM have already indicated that they plan to extend XPages to provide Notes client control. When they do, that opens up the chances of doing some Notes client development with SSJS. And hopfeully some time soon we will get some sort of clear indication whether or not IBM plan to provide a single programming language that can be used anywhere across the product. Because as much as I now appreciate SSJS I still see little value in investing too much effort into it outside of Web Client or (possibly) dual client applications. Until I can build the majority of my apps with XPages alone or SSJS is supported in all the design elements I need, it is difficult to find a compelling reason to consider using two programming languages (plus some @Commands here and there). So the challenge is very much there for IBM so make some sense with the programming languages it supports. Can IBM afford to let LotusScript slowly die before it has established a viable alternative? Do LotusScript and Notes classic design elements need an extension to make them more like SSJS & XPages to tide us over until the transition is complete? Is it OK that I like hot-dogs without mustard but would still kill for a meat pie with sauce.....
:
Related Posts
Programming Language - Does It Matter?
LotusScript v JavaScript
Does LotusScript Have A Future
LotusScript Revamp (20 Things I'd Like To See)
Ratings
0
Comments (12)
Well, what I liked about Lotusscript was that some years ago it was used in both, the Microsoft and Lotus world. It offered me the flexibility I needed because Microsoft is a reality in a lot of companies (and still is at least where I work). With Java we got a powerful language but many companies went through a process of standartizing on either Sun Java or Microsoft .Net. Now there is SSJS with its roots being Java Server Faces. While it seems to be a powerful technology I am again at a point where I have to make decisions. I can only speak for myself and I do recommend that everyone gets his own opinion. I only have little time and I have to make priorities. While I will not completely ignore new IBM technologies I will be a late adopter. Why? Because companies are late adopters too and I really want to see if IBM is not yet running another "experiment". XPages currently is for the browser. If you solve the single sign-on and directory problems you are quite flexible in the technology you use (outside of the Domino world). And I am not sure if I would not prefer to develop using a technology that does not force me to buy server and client licenses and give me more choices about the database and server platform (I only speak about the browser part here). This all web only. If we speak about the client. I really loved the Notes client with all its power and ease of development, it's robust server architecture and even the Notes datastore. I am not giving up on this and it is up to IBM to make the XPage experience better in the client so that it goes beyond an embedded browser, off-line capabilities and a @ClientType formula (ok, I am exaggerating here).
Last but not least if IBM is not going to publish some kind of
roadmap revealing where XPages are going and how long it will take
I believe that the future of XPages are doomed. I would be silly to
put my weight in a technology with just a vague promise that a lot
of things are going to happen. Fortunately the future of IBM and
XPages do not rely on my decisions (indeed those are quite
irrelevant to the success of any platform).
@1: "XPages currently is for the browser"
As of 8.5.1 XPages is for the notes client and browser.
I recommend the following demo by one of the developers with
regards to the client.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/XPage_Components_in_Notes_851_Videos.htm
Simon I am aware that XPages now run in the Notes client. It basically seems to run a local webserver and use a HTML rendering kit (I have heard Mozilla in this case). For me (and again I can only speak for myself) this approach offers too little to deploy a gigabyte client on every users desktop that uses lots of RAM to at the end just render web pages.
In fact I have one customer that is currently thinking about
dumping Notes for mail and just run applications on Domino Utility
Servers Express. The cost savings would be huge but what is holding
him back is the pure mass of existing client only applications.
Don't get me wrong. This customer is very happy with Notes. I have
just not been able to explain to him why the Notes client is worth
the hassle. Off line access is getting less important nowadays (not
for me but for others). At least I know of companies that are
moving the client to Citrix environments which makes off-line
capabilities totally useless (imho). And that was about the basic
client. The standard client has even raised the complexity.
"There are ways to execute Java code..."
I'm not sure that's a fair way to put that. It's not like it's
obscure. Switch to the Java perspective in Eclipse, as a SRC folder
to the right place in your project, then in your SSJS, use an
IMPORT statement for the package you created. It's not like that's
some kind of elaborate workaround.
If you're starting to like SSJS, then you should really learn a bit
about closures. They're fully supported, and as an OO fan, I think
you'll like them. They're a lot more digestable than the .prototype
hack that's typical of Javascript.
@Nathan. I think prototype represents a little more than a hack. As for me liking Java... I have never disagreed. But from a purely economic point of view. I am most likely to get hired as a Notes developer based upon my Notes classic skills, including LotusScript. Moving forward I would anticipate opportunities for those that know XPages and SSJS. I do not see a lot of demand now for Notes/Java nor do I see that changing. So why would I invest my time mastering a technology few people want. It only seems to make sense when an employer/client invests in that technology. There is definitely a role for Java, I just don't see it being big anytime soon.
@3. " It basically seems to run a local webserver and use a HTML rendering kit"
Bit of an oversimplification IMHO. The client version also allows
you to interact with composite applications you have created (shown
in second demo). So it goes a beyond a "rendered web page".
My first answer was a bit longer but I ran into a session timeout and gone it is. The short version is that maybe I oversimplify (or just don't know better). Then it is good that anyone can raise its points. Afaik Composite Applications can interact with many websites not only XPages but it might be simpler and more powerful (I haven't looked into it). My overall problem with Composite Applications are that they require a 100% Notes 8 Standard environment. That is a tough requirement (as powerful as Composite Applications might be).
Here is a screenshot of integrating a Composite Application with a
Non-XPage but looking at your comment link you are already well
aware of this.
http://www-10.lotus.com/ldd/compappwiki.nsf/xsp/.ibmmodres/persistence/DominoDoc-269-content/_1_1256147169328112-C2.gif
@Henning, in my opinion, IBM is absolutely running an experiment, but a rather clever one. The JSF specification is over 8 years old, and SSJS has been around even longer (Rhino, for example, was orginally created in 1997, and LiveWire was released in 1996), so the underlying technology isn't exactly new. On the other hand, in many ways, XPages have allowed Domino to leapfrog most of the web development platforms that are currently trendy... a phenomenon I honestly never thought I'd see.
I found this video about SSJS on the YUI Theater site intriguing:
http://developer.yahoo.com/yui/theater/video.php?v=isaac-ssjs
It's a short clip (at least compared to most on that site), but the
implications are clear: platforms implementing SSJS are still
considered leading edge, but there's strong momentum behind this,
and over time, having a rock solid implementation is definitely
going to be a strong selling point for any platform.
In case you're curious, Wikipedia has a listing of all known
implementations of SSJS:
http://en.wikipedia.org/wiki/SSJS
...and yes, there's a glaring omission. :(
Thx for the history lesson Tim. I didn't realize SSJS had such a long history. It kind of makes sense given how dominent JS is in the Web client arena.
Peter, you're going to like the next version of Javascript. It's known as Ecmascript 5th Edition and it will most likely be official by the end of the year. Will IBM implement it for XPages?
One new feature will be getters/setters. Java getter/setter syntax
is a non-goal. Most widely used Javascript implementations have had
getters/setters for a while. This doc discusses problems with
current implementations (rhino) and ~how getters/setters will/may
be implemented in the new spec, along with some other cool stuff.
It's also a fascinating discussion on API design.
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methodsaug26.pdf
I hope iterators and generators make it in too. Then you could
easily do this:
var apps01 = rhomino.getserver('APPS01/SOMEOU/SOMEORG');
for (db in apps01('finance/sales')) {
print(db.title) //do db stuff
}
Yes, the server "instance" is being called() . rhomino.getserver
returns a function that takes a path and has a ref to the
DbDirectory. This function (closure) implements the iterator.
var pnab = rhomino.local.getdb('names.nsf');
var peeps = (doc for (doc in pnab) if doc('form')== 'People');
//lazy - evaluated when referenced. Assumes that the iterator in
pnab returns a closure that takes an item name and has a ref to the
Document
for (peep in peeps) print(peep('fullname'))
or the more JQuery-like:
peeps.each(function() {
print(this('fullname'));//'this' is bound to each doc
});
all of this can be done in Rhino now. Only some of the Rhino
enhancements will be in Ecmascript 5th Edition.
Before anything else though, we need a MODERN Java API!!!
Please?!?!! That would make leveraging other JVM languages so much
easier.
@Tim
I am very well of the Wikipedia site. I also know that the
technology is IBM Lotus Workplace + nsf support (oversimplification
again and the server part is lighter now) so IBM's first try is a
few years old (and by the way it failed). Aptana also had an
experiment called Jaxer (see http://www.jaxer.org ). It is now
considered a dead project. Maybe the problem was that many web
developers in general do not like javascript (although Aptana as a
company has many problems that have little to do with Jaxer). You
call it cutting edge, I remain sceptical.
And for what it's worth. I cannot confirm that XPages on the web
are fast (and the Notes client version is not either). In my
opinion XPages now have the same click and wait experience than
many IBM websites. It is not really slow and in an Intranet
environment you would need a tool to measure the delay but on the
web I even find some classic Domino websites perform better. And
yes I am aware that with a raising level of complexity XPages would
definitely be the winner because for classic Domino this would
probably mean extensive usage of agents. You probably can't have it
all.
But I haven't criticized XPages anyway. To the contrary I think
that the focus on XPages is so strong that I think IBM is in danger
of losing the rich client. While this is not a disadvantage in
itself the competition in pure web environments is much stronger.
Supporting both, the web and the rich client is a competitive
advantage that I would not sacrifice.
Maybe it only is IBM's way of pushing the platform. There is much
focus on putting browser stuff in the rich client (integrating,
Facebook, Twitter, Google, aso.) while if you use a browser all
this is already there.
If I would be a bit provocative I would ask where are the Lotus 911
Bones applications from IBM or Business Partners? I am not in the
medical business but this really does not get out of my mind since
I first saw the video.
I don't want to convince anyone of everything. I describe my
personal situation in a certain segment of the market (Micro SMB
with a still doing strong Microsoft and a raising Google
awareness). What fit's for me does not work for others and
depending on your work environment IBM's current strategy may be
the perfect fit.
To me it clear that xPages is a chosen path (By IBM) for the future of Lotus/Domino development, some people might not like it while others do.
As from a technical perspective, I think SSJS + Java are a great
combination, both great languages (but different) in their own, and
when combined (via XPages), extremely powerful.
Java’s network capabilities (java.net et al), collection classes
and widely available and often free projects/ API: s makes it great
(relatively speaking and in contrast to LS) as a pure “back-end”
language and a perfect “side-kick” to SSJS imho (Aside from the
fact that xPages is a java technology that is).
On the other hand, in the future, if SSJS inherits some of the key
advantages of Java with maintained flexibility, the need for java
might perhaps not be as obvious (for me) any more. ECMAScript (5th
ed) looks promising (thank you @Dan for some of the details (here
and on the XPages blog)).
Another aspect of implementing widely adopted and standardized
languages, instead of maintaining your own, is money. I’d imagine
it very expensive to maintain a language by your own and to keep up
with the never ending demands on a language. The decision to use
JSF, JS, Java and other open technologies will hopefully allow IBM
to utilize and incorporate future language
specifications/implementations more quickly and at a lower cost.
This is a good thing for the Lotus/Domino platform as a whole.
Sure there are still things that needs improvements, but in all, I
think it’s nice and promising that we finally can *see* the how the
platform has begun to evolve again (from a dev perspective). The
8.5 and 8.5.1 releases contain more new stuff for us developers
than 6 and 7 together.
Fredrik