• Nov 2, 2018

(Fair warning: this is a meandering one and I'm basically a wet blanket the whole way through)

Last week, HCL held the third of their Twitter-based developer Q&As, with this one focusing on XPages and Designer. The majority of the questions (including, admittedly, all of mine) were along the lines of either "can we get some improvements in the Java/XPages stack?" or "is XPages still supported?". The answer to the latter from HCL, as it would have to be, is that XPages is still alive and "fully supported".

I don't doubt at all that XPages is supported in the sense that it has been for the last couple years: if you as a customer encounter a bug in the platform, support will take your call and will most likely either have a workaround or will get a fix in. This will no doubt happen naturally as time marches on, primarily when a new version of a browser breaks something in the version of Dojo that XPages uses (currently, I believe, a couple notches down the list as 1.9.7). So, that's good, and is better than the worst-case scenario.

It's not great, though. Version 10 had essentially no changes for XPages - that makes sense with its "stanch the bleeding" market goal, but it continues the history of very little progress. Outside of the forced-for-security-reasons bump to Java 8 in 9.0.1FP8 (which is admittedly nice), the last major addition to XPages was the Bluemix tooling via the Extension Library, which, as far as I can tell, only exists because of the way funding politics works inside IBM. Before that, I'd mark it as the promotion of Bootstrap renderers from Bootstrap4XPages to the main ExtLib just shy of four years ago. Before that, it was... I guess adding the ExtLib to the main product in 9.0, which sort of counts. Before that, it was pretty much the introduction of the extension points and ExtLib in the 8.5.2 era. And sessionAsSigner, I suppose.

Not to belabor the point too much further, XPages developers are in an uncomfortable spot. For a decade or so now, XPages was the clear "this is what Domino developers should be doing" choice, especially in the face of many Domino shops wanting to at the very least get rid of the Notes client. However, though it was modern enough when it was introduced, the stack has missed the boat on a lot of evolution, both in simple terms of its Java EE common ancestor improving on its own and in larger terms of changes in the web development world.

Had XPages continued under real active development, it could have gradually improved to fit more comfortably in a world of transpiled JavaScript and CSS pre-processors, strict focus on REST APIs, and reactive and streaming APIs.

But...

But even in that "active development" alternate universe, the path would have been awkward. Though XPages has the capacity to be well-structured, Designer and IBM provided no help on this: no model framework, no internal routing, not even an indication that writing Java code was possible in an XPages app until several versions in. The "MVC" aspects of its JSF components were beaten down to match the expectations of an NSF container and of LotusScript developers. There's very good reason for that - very few Domino shops were likely to send developers to computer-science boot camps to learn about proper Java EE structure, and the only way XPages was going to work at all was if it started out as "forms but with partial refresh".

And, after that first unstructured version, it largely fell prey to the usual problems of enterprise software: IBM isn't in the business of doing things their customers aren't asking for, and the community members asking for, say, a faces-config.xml editor weren't backing those requests up with big licensing checks. I get that, too, I really do. If you spend too much time hypothesizing about and implementing what customers might want, you run the risk of throwing your money down a bottomless hole while your actual customers suffer and leave. So IBM generally swings hard in the other direction, and it's understandable if unfortunate in cases like this, especially when what your customers are strictly asking for is stasis.

So What Now?

Our current situation now is that HCL plans to have a roadmap in Q1 2019, so I suppose we'll wait and see what they say again. I've been mulling over what I think should be the way forward for XPages and its users, and I don't see any clear good solution.

The option that immediately springs to mind is "add more features to it": HTTP/2 and WebSockets, newer renderers, an IDE that encourages good development practices, better way to bring in third-party libraries, cleaner JavaScript, and so forth. But what makes this questionable for me is the sheer amount of work, especially since they'd have to start by digging out of an immense amount of technical debt. And this would be very specialized work indeed - the XPages stack is complicated. I'd wager that just the part of the stack that handles ferrying attachments between the browser and a document is more complex than most entire Domino applications by a good margin. While some of the improvements would be handled via the core Domino server team (part of the HTTP upgrades, namely), HCL would likely have to acquire a team of Java developers and have them learn a giant stack of OSGi, JSF, Domino APIs, a couple decades of legacy decisions before even getting going. Possible? Certainly. It's just kind of a hard sell.

Another possibility would be open-sourcing the stack and either maintaining it as a project themselves, giving it to OpenNTF, or handing it to an organization like Eclipse, which now holds the reins of Java/Jakarta EE generally. I think that open-sourcing it would have immediate benefits to XPages developers regardless of what else they do with it, but I'm skeptical of how much of a life it would have if it was converted to a community-run project. As it stands, I can only think of a handful of people who a) are aware of XPages and b) would be capable of contributing to its core code. That's not a problem if you are employing people to work on it full-time, but I don't think it has a large enough base to exist on a "side project" basis. Attracting new blood would be an uphill battle: even projects like Andmore that have a clear purpose for existing and a contingent of people desperate to keep their workflow can wither on the vine immediately. Outside of Domino developers, XPages would be viewed as "JSF, except old and restricted to a platform you thought died in the 90s".

The other main thing to do with the stack that doesn't involve killing it, I think, would be pushing it to a state that focuses on REST APIs instead of handling the UI itself, which is something that some XPages devs have been doing already, either by switching to plugins serving up JAX-RS services or via in-NSF controls. This is something that IBM kind-of-sort-of said they were aiming for a couple years ago when they put forward SmartNSF as a good option, but the effective demise of the Extension Library cut off its path into the core, at least for now. Overall, I think that this would make sense. The experience of writing REST services inside an NSF (or in an OSGi plugin) is significantly worse than JAX-RS in a normal Java EE or Spring app, but it provides a clear path for existing NSFs and code to continue being used - more or less - without having to set up a second app server. It may not be the preferred solution for Java in Domino, but it would have the advantage of improving the platform without having to worry anymore about how, say, all the core renderers use tables for layout.

For Developers

For XPages developers, my long-proffered advice remains the same: learn things that aren't XPages. Whether that means diving head-first into Java EE or Spring, focusing on client-JS development, learning Node, or any other option, you'll likely be well-served by it.

It's possible that you could continue to do XPages work or go back to the Notes client indefinitely - XPages will get patches if nothing else, and Nomad breathes undeserved life into LotusScript - but there's no guarantee there. There's no guarantee anywhere else, I suppose, but staying too tied to Domino-specific technology keeps you at immediate risk of a from-above directive to switch away.

In short: do not expect a cavalry to ride to your aid.

Nov 2, 2018
Ben Langhinrichs

It sounds like somebody needs a cookie. Not that I disagree with anything you say, just that a cookie sounds good right around this point in the discussion. That is, if stiff adult drinks are out of the question.

While I am not any sort of technical expert, I do like the idea of the REST API internal communication, if only because it sounds like a place where I could dip my toe in and provide a better mousetrap or two. While I work with XPages complexity for the sake of AppsFidelity, it is a bitch and a bear, or perhaps even a bitchy bear.

Nov 2, 2018
Russell Maher

Very, very sage advice. Thank you for taking the time to put these thoughts out here.

I agree with your analysis 100% and am now, for the first time since 1996, looking for a new platform on which to develop applications. The likelihood of XPages "improving with age" feels low now. The good news for my company is that we never really pushed the boundaries of core Domino and XPages functionality (a complex execution of that functionality, yes, but still well within very basic core functionality) so we have weathered quite well since migrating our main application to XPages in 2010 but it feels like sometimes we have dodged a bullet (or three) when browsers have updated or issues arose on the Webby World. From what I am seeing now as someone who relies on this technology to deliver an application to paying customers, staying on Domino 10 + HCL feels like playing Russian Roulette and I get to add another bullet about every six months. No matter what, eventually I'll lose.

Sadly, there is no obvious path away from Domino as an app dev platform. Every other option is likely to prove more costly to operate in almost every way and more complex to manage although the results will, more than likely, be significantly more future-proofed.

The upside of it all? More learning.  I always like that!

Nov 2, 2018
David Leedy

I totally agree.  There is a big difference between "Supported" (Life Support) and "Supported" (Enhancing and making it better).

 

I'm only seeing the bare minimum "life support" options.  And now having to wait till 2019 reminds of what IBM did last time.  They gave us hope and made us wait for a roadmap and then that roadmap was 3 different migration strategies.

Nov 3, 2018
Henning Heinz

I am not sure if this is a fair statement

" For a decade or so now, XPages was the clear "this is what Domino developers should be doing" choice "

IBM XPages technology were  the remains of a failed IBM product, put into Domino because component recycling is what has been hip at IBM those days. IN my opinion It never had a great future. I've had a look and did not like it, most of for the reason you count as sacrifice for Lotusscript developers.
It is a rough end for believers, some people have invested much and now have to think all over again. This is not IBM's fault alone asOracle has done much harm to the Java Ecosystem, mainly because for Oracle everything has to become a cash cow.

It is good to remind people that they should think carefully when moving forward with IBM and I really had a good laugh for the "undeserved life into LotusScript". Now it might be cool to run some ancient Notes applications on a mobile device but I would not bet that this is moving forward either. Node.Js has the advantage that is is quite successful product outside of the IBM universe. I have used it but I am still not sure if I would like to develop with Domino as a backend.

The greatest thing about IBM XPages was/is its community. I say this although I have never been an active part of it but there are some people that really wanted to make this platform succeed and pushed very hard. Even when I stopped using XPages some years ago it has been energizing and motivating to see others fighting sharing their knowledge and trying to fix things IBM did not want to deliver.

I hope that HCL will find a way to move Notes and Domino forward.

Nov 5, 2018
Slobodan Lohja

I agree with most of it.  I'm glad you wrote it.

I think it can be easier to work the Domino Server to allow any JSF view controller (PrimeFaces, angularFaces, bootFaces, OmniFaces) to run and bind to Domino data.  That will require HCL/IBM to produce a 'dominoFaces' library.  I'm sure they can pull this out of a XPages package.

That will help Domino Developers who want to stick with the Java stack to integrate with the Java EE community. 

XPages itself can be given to the open source community as dojoFaces.  Its a even exchange to get access to angularFaces, bootFaces, React from PrimeFaces.

Loading of a SpringBoot app can also use a domino plugin on Maven Central so these Microservices can use Domino as a backend NoSQL storage at minimum.

Imagine JSP/JSF projects running from Tomcat, JBoss, ect. can now include a NoSQL storage solution using Domino using dominoFaces or a Domino plugin on Maven Central.

I cannot see a traditional Domino Developer (Not the exceptional rock stars who can do everything well) adopting React and Node and all of a sudden becoming a web developer.  Remember the Notes client provided the platform, UI, security, and everything needed to run apps.  Hence why Domino and Notes are in this predictament.  I remember Lotus telling us to learn Java almost 20 years ago.... the typical Domino Developer just kept pushing LotusScript.  My point is integrating with the larger Java EE community will bring in new blood and we'll start seeing apps built professionally with unit testing, source control, and automation.  If I was IBM or HCL I wouldn't put any hope into Domino Developers... I would start engaging web design firms and web developers outside the Domino community to make Node/React successful.

There is another confound in the Node/React adoption, the iPad Notes client will keep Domino Developers into LotusScript and Formula language especially with the http request in LotusScript with Domino 10.

Back to reducing technical debt, IBM/HCL may have less work to do to reconfigure/rethink the Domino server configuration so it can be a more open server to run any JSF project.

Post New Comment