What is holding back XPages adoption

A question that is asked - monstly by non-developers or "old Notes hands" - quite often recently: "Why would I want to develop in XPages rather than classic Notes and Domino". Part of that question might be driven by Cainotophobia. However it is valid. When a new way of programming comes around, like switching from punch-cards to terminals, from Assembler to C, from Cobol to Basic, from VB to VB.net or from Terminal to GUI draught of competency happens. The existing paradigm is well understood (including all its quirks) and backed by a huge body of knowledge represented by a huge code base. The transition from classic Domino to XPages is no different.
The transition between LotusScript and XPages

The transition between LotusScript and XPages

Until the new paradigm is backed by a similar level of competencies and skills doubt will exist if "that new thing" is really the way to go. With increasing adoption of XPages the skill level in classic Domino will gently decline (people retire or simply forget) while XPages skills will rise. Now the graph for XPages isn't fully accurate once you take developers into account who haven't developed on Domino before. After all XPages embraces and (horrible IBM word:) leverages existing technologies and open standards. Unless you live under a rock you have (at least as a consumer of the results) encountered HTML, CSS and JavaScript by now. Also XPages' foundation in JSF is well established. Of couese it very much depends on the "readiness for innovation" in the individual companies' development team if they want to contribute to the growing body of knowledge around XPages or wait until the moment where late adopters move. IMHO XPages' early adopter phase is coming to an end and XPages enters Domino mainstream. Very soon the question will change from "Why XPages" to "Why stay back".

Posted by Stephan H Wissel on 08 October 2010 | Comments (4) | categories: XPages

posted by Patrick Kwinten on Monday 11 October 2010 AD:
I guess the mix of comfort with LotusScript, age of (corporate) developers, workload, time pressure in projects makes the adaption rather low. (at my company)

Also really taking benefit of XPages requires understanding of Dojo, JSF.

Translating more functions into SSJS would certainly help adaption...

posted by martin on Monday 18 October 2010 AD:
On my end it's the general consent that "Notes is dead" which makes developers look for other alternatives. I'd love to pull off passport renewal forms using secure Xpages relying on Domino's PKI for validation to be able to sleep well. But that's a strategic decision and I have to stick with triple shots long blacks for breakfast.

posted by Wayne Allen on Friday 22 October 2010 AD:
Stephan thanks for your training the other day - I think that training people in XPages specifically will speed the adoption across the community. After the training, I went away and had a go at creating my first XPages application. It is a powerful tool. One question, is it possible to place "pass-thru" HTML in the <head> section of an XPages generated page.

posted by Rob Shaver on Wednesday 03 November 2010 AD:
The biggest stumbling block I have to xPages is understanding how to make them look the way my customer requires them to look in all major browsers. This is a combination of learning how xPages uses JavaScript, CSS and dojo. (I have a lot of problems with CSS that does not play the same with all browsers not to mention trying to decode how it works in xPages.)