As far as I can tell that decision has already been made with most development time spent on Server Side Javascript. I am certainly happy with that as the possibilities offered by XPages are a huge leap forwards.

LotusScript should be put into maintenance mode from my point of view.

Isn't Lotusscript in maintenance mode since R6 (at least feature-wise)?

I started off my comments thinking Im sitting on the fence here too ... but I gotta say that I think this comes down to [the quality of] the implementation of xpages in the client ... client development isn't going away anytime soon, and we've been screaming for a good "develop once, use in either client or browser" solution. To get there we need an environment that is good for both ... if xpages for the client works seamlessly in the client, and in the browser, LotusScript will naturally fade into the background, because it isn't for the browser (without a round trip to domino, which is slow old world web dev).

The only thing really left for LS then is "power code" ... heavy lifting agents, etc ... and Java and LotusScript are getting very close to being equal in power in manipulating notes data/objects ... once UI events can be handled by Java, where's the need for the proprietary LS versus Java/Javascript ?

The Javascript part in XPages is not native Javascript but automatically translated Java code. In theory you could do that with Lotuscript too. You then write your code in Lotuscript and it is compiled as Java code. I think Adobe has done this to further support ColdFusion. Microsoft does it too with C#, J#, C++ and VB .NET all translating to the same code. The cool thing would be that in theory this would allow Lotuscript to work on the web too). Throwing your old stuff away has advantages but I currently have one customer that is also thinking about throwing away their whole Notes system (they just have 400 seats so this is no deal for IBM but a problem for me) because in some way they think that their 15 years old grown Notes infrastructure is now made redundant.

I voted to demote because your subject does not match what you are suggesting. The LotusScript language has not been enhanced in many years, and it was not the language chosen for xpages, yet it is a critical part of many core Notes features, partner applications and customer applications. Replacing it would require a rewrite of massive amounts of code. This isn't going to happen any time soon.

I am with Richard on demoting this. It's too early to kill something that's still an integral part of the ecosystem.

I like the "LotusScript running under the JVM" concept because it should theoretically allow legacy code to be leveraged while offering a migration path to new technologies. No "Bite the bullet" migration cost and risk of failure.

This would give the technology time to gain traction and acceptance, as well as a chance for the innovators to gain experience and build tools.

However I don't think we're anywhere near ready to pull the plug yet. We need clarity on how the Client UI is going to evolve first.

Too early.

What *should* happen is that XPages should be allowed to consume LotusScript (see my Ideajam ticket here). That lets you transition to XPages immediately with all/most of your legacy script libraries, custom classes, etc.

Then (as of 8.5.1) people can really move forward with XPages on client AND browser, and gradually rewriting their legacy LS code in JS/SSJS/Java.

The final destination (XPages + JS/SSJS/Java) is really, really awesome. BBut as of today the road to get there is really tough.

Based upon some of the feedback so far I have chosen to rename the title of this idea as I agree it was somewhat misleading. Clearly all existing LS needs to be supported moving forward and Lotus/IBM have always gone out of their way to provide backward compatibility - even to the expense of the product at times. So I changed the idea from Replace LotusScript to Retire LotusScript. So to be clear I am asking you to vote on whether you plan to stay with LotusScript moving forward or plan to jump to SSJS asap. Those wanting to stay with LS would most likely want to see LS extended or at the very least supported in XPages. Those planning to jump to SSJS would probably prefer to see all language development focused on making SSJS more powerful.

one language to conquer them all please

LS has already been retired as far as I can tell

First of all I am a big fan of Peters series about xPages. They contain lots of information, motivate other people for nearly as interesting own related postings and are nice to read.
Otherwise I see no reason why not to use different programming languages. LotusScript is a *good* language for classic notes stuff. Why replace it with another language? I guess we will have a tendency towards more languages on other platform, too. I allways suspect nasty opportunity costs as consequence of this language consolidation.
And we never had 1 language on Domino as there allways was formula language, which helped me a lot in understanding xslt btw.
I am also against a lotusScript implementation for xpages. A good LotusScript developer will learn it in a week or 2.

Definitely retire long term, better JavaScript skillz for Notes heads is good for career.

@Mark Remember SSJS is not JavaScript it is actually a completely new langauge that follows JS syntax. Probably as much use as LotusScript would be getting a job doing VB.Net development.