: 4581 | 108544 | 12346

Retire LotusScript, Focus on JavaScript (SSJS) 
New idea submissions, commenting and voting are no longer available on this site. Logins have also been disabled.
Use this IdeaSpace to post ideas about Domino Designer.

: -54
: 15
: 69
: Domino Designer
: lotusscript javascript
: Peter Presnell26654 27 Jun 2009
:
: / Email
This is more a vote to see how the Notes development community might feel about Notes development moving away from LotusScript towards Javascript.  With 8.5.0 IBM introduced xPages and it seems a lot of IBM's focus for Notes application development is going to be on the use of this design element.  Xpages do not have any support at this early stage for LotusScript and given the way Xpages are implemented it is difficult to say if this will happen any time soon.
 
The LotusScript language has become a little outdated and needs work to make it competitive with languages such as Java, C#, and VB.Net.  There are a lot of ideas on this forum for this... Would you rather see IBM focus its attention on expanding the server sided Javascript language supported in xpages (promote this idea) or would you instead like to see significant redevelopment of LotusScript and support for Lotusscript in Xpages (demote this idea)????.  Personally I am on the fence but very interested in which way the yellowverse may go.
 
If this idea does not make the hot list I will assume that the Notes development community is ambivalent about the programming language used.



1) Matt White9275 (27 Jun 2009)
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.
2) Henning Heinz180 (27 Jun 2009)
Isn't Lotusscript in maintenance mode since R6 (at least feature-wise)?
3) Jeremy Hodge1383 (27 Jun 2009)
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 ?
4) Henning Heinz180 (27 Jun 2009)
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.
5) Richard Schwartz3723 (28 Jun 2009)
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.
6) Colin Macdonald45 (28 Jun 2009)
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.
7) Erik Brooks795 (28 Jun 2009)
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.
8) Peter Presnell26654 (29 Jun 2009)
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.
9) Patrick Kwinten22013 (29 Jun 2009)
one language to conquer them all please
10) Ben Poole1705 (29 Jun 2009)
LS has already been retired as far as I can tell
11) Axel Janssen5023 (29 Jun 2009)
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.


12) Mark Demicoli11742 (02 Jul 2009)
Definitely retire long term, better JavaScript skillz for Notes heads is good for career.
13) Peter Presnell26654 (07 Jul 2009)
@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.










:
:




Welcome to IdeaJam™


You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>






IdeaJam developed by

Elguji Software Logo