Beyond The Yellow Bubble

Over the past three weeks I have started conducting an autopsy on XPages.  I am still in my preliminary analysis but I believe the most likely cause of death was that these things simply didn't bleed yellow.  The same thing that killed Workplace probably killed XPages...

OK, OK, Xpages is far from dead.  In fact there are some truly great things in Xpages that I am sure many many Notes developers have been yearning for a long time.  But for Xpages it really is a case of The Good, The Bad, and The Ugly...  I am sure IBM are well aware of some of the deficiencies of XPages in a Notes platform.  IBM have a difficult task taking something that was clearly never designed to be part of Notes and integrate it into a product that has always dared to be different.  Its a good thing we have so many brilliant minds inside IBM and the Design Partners trying to solve this.

I see a patchy future for XPages in the short-term with uptake being slow:-

1. The product is very complicated and difficult to learn, epecially without top grade reference material.  Also, in an economic downturn companies are not going to invest as heavily in training.
2. At the very least you will need 8.5.0 for Web client and 8.5.1 for Notes client development of Xpages.  Many companies are just now getting to 8.0 or 8.5.0 and I suspect many will pause before contemplating another upgrade.
3. There is almost no migration path to XPages for existing Notes applications other than to throw them away and start again from scratch - and I don't see that happening!
4. XPages cannot yet replicate all the functionality of existing design elements such as Forms or Views.  Given these things are presently so hard to mix together this causes a problem.  Many simply won't bother.
5. IT People tend to resist change.  I am sure there are many who are like me and love new and interesting stuff, but in general I have always struggled in most IT environments because it was so hard to sell new ideas.  Few view Notes as a strategic weapon.
6. Xpages will leave behind a great many people who are not full-time developers and prefer to play with @Commands and LS.

My prediction for the next 1-2 years is that XPages will carve out a niche market in Notes development.  It will find favor with Web-Client  applications, Java developers, and those applications requiring some of the specific things that only XPages can do.  After that the future is less clear.  The future may well depend on the extent to which IBM can pump some yellow blood into XPages and turn them into YellowPages.  When we have a larger pool of organizations on 8.5.1 or beyond, a larger pool of the yellowverse trained and experienced in this technology, migration tools, and when Xpages provides access to other database sources then we just might see a huge surge in XPage development.  If this does happen then there is an opportunity there for those Notes developers that make the effort now (and absorbed some of the pain) developing expertise in this technology.  This just might be the dawn of an entirely new Notes for us all.

The Notes community has a HUGE role to play in this future by providing feedback and encouragement to IBM.  By participating in OpenNTF projects and/or developing and sharing you own solutions that can bridge the gap between what we have now and where we want to go.  For my part I plan to develop a new XDomino Framework that will fill in some of those gaps.  Anyone interested in contributing ideas and code please join my community on bleedyellow. and lend a hand.

More observations on Xpages from my first few days in XPages kindergarten.

The Good: Source View.  This is up there as one of my favorite additions to Domino Designer.  It is also something I can easily relate to having used a similar feature in MS Visual Studio for ASP.Net development.  I am a developer and so I like to look at code.  Being an OOP developer I am used to seeing all my LS code in one place (LS library).  So being able to see visual elements such as XPages represented as a single block of XML code is really cool.  It provides options for me to do things I haven't been able to do with other visual design elements.  I can now see what I have done with my Xpage without the need to click on an endless number of controls and review all the tabs with various radio buttoms, check boxes and keywords.  I can use the source view to edit visual elements too small to see.  I can copy/paste the xml and do search/replace much as I can with LotusScript code.  I havent tried this yet, but I can probably now use TeamStudio code snippets as a way of creating a library of common xPage components (over an above custom controls).  I am hoping IBM plan to extend this capability to all other Visual design elements, especially forms and views.  If I do I might then be able to copy/paste codes between these design elements (see legacy code yesterday).

The Bad: Programming Language Support I was tempted to classify this as just plain UGLY, but that might be a little unfair.  I am sure a few people out there such as Nathan T Freeman and Andrew Pollack will disagree with me.  That's OK, I respect their opinions, even when they are wrong :)... Without doubt my single biggest disappointnment with xPages so far is the decision to support server sided scripting for XPages with a new variation of JavaScript.  Sorry, but I just don't accept that JavaScript is a programming language.  Most other development platforms employ JavaScript for client events only. If they could get Java or C# to run in a browser I am sure they wouldn't even be using JavaScript.  Most server sided programming outside of the Notes world is now done using OOP languages like Java or one of the .Net languages - C# or VB.Net.   Outside the yellowverse it is also pretty much accepted that OOP is the programming style of choice.  Within Notes Java is OOP and LotusScript can be (sort of, kind of).  JavaScript does not support classes (outside of hacks such as prototype), it doesn't even support strong typing, everything is a variant.  There are some cool things with this version of JavaScript such as implementations of @functions, but it is still a procedural scripting language.  It seems with this current version of XPages OOP is sadly not an option (agent hacks aside).

I have seen suggestions that JavaScript was chosen as a way of getting Xpages implemented and out there quickly using JFaces.  I am not sure if that is true.  If it is, I am not sure if that then means in the future support will be added for both Java and LotusScript for Server events and LotusScript for client events.  I hope that is the case as it creates a real dilema for me as to whether or not I would want to rewrite my applications from being OOP to procedural.  For me that is a giant step backwards from a software engineering perspective.  Xpages need engineering as they can be very complicated.  I am not sure if IBM have ever publicly commented on its choice of JavaScript for XPages and where this is leading....  It is is still my hope that one day soon IBM will publish a road map for Notes Development programming languages that clarifies the future for both LotusScript and Java.  In every Notes shop I have worked for in the past 10 years LotusScript has been the dominant programming language (95%+) .  Convincing people to move away from LotusScript may prove to be just as hard as convincing these same people to move away from Notes to Workplace.