Some years ago I wrote a blog post called “Whither the Notes Client”. At the time (2012) XPages was flourishing, the Notes browser plugin (subsequently ICAA) was being launched, Symphony was being stopped and the IBM-specific enhancements routed back to Apache OpenOffice and iNotes was being integrated into what is now Connections Cloud. My takeaway point was that the I could not see the Notes Client disappearing, that it still had a big strength in local replicas.
A variant on that seemed apt for now. IBM Mobile Apps is using the basis of the Mac Notes Client to bring those local replicas to iPads and an Android version is also in development. On the flip side, there has been a lot of discussion about XPages during this year. This blog post is designed to give my thoughts on the topic, in the context of what’s now and what’s future for Domino app dev. And when I’m talking about XPages here, I’m eclusively talking about browser access, not XPiNC.
My Thoughts on Timescales
First of all, let’s add some realism to expectations, many of which I believe have been unrealistic. Let me start with two important points.
Firstly, while IBM was deciding what to do with Domino, the XPages team were moved to other areas of development, all beyond the Domino platform. This is a significant point for two reasons. Firstly, a cursory review of LinkedIn will show that Phil Riand had gone back to Trilog a long time ago and the other IBMers who were speaking at conferences about XPages are still at IBM. Secondly, the skills they gained on XPages made them of use on other IBM technologies. This is not intended as any value judgement on those individuals or the ones who remained on Domino, it’s a factual statement which will be of relevance to this article.
Secondly, HCL were tasked with going from startup to the first full release of Domino for over five years – in less than a year. It’s no secret that a lot of what’s in Domino V10 had already been partially developed before HCL took on the product. With the timescales involved and much of what was 9.0.2 already delivered in feature packs, that was always going to be a key factor. Brand new development was going to focus on quick wins.
What this means is that an overhaul of XPages in Domino V10 was never a realistic expectation. Open sourcing was a possibility, but I can’t say how feasible that was. It still remains the closest to a “quick win” that’s possible, though as Jesse says what’s not clear is the appetite for taking it on.
If that’s not the approach adopted, in my opinion Domino V11 is the earliest realistic date for anything new in the core.
XPages is Still Relevant
- How many use a REST service API layer as the standard interface for new Domino-backed applications?
- How many customers have developers who use SASS, LESS or HTML/2?
- How many have a non-Domino web server deployed for web applications that uses their Domino server as the database layer?
- How many customers will be ready for the shift to deploying an application that wraps a server, with the associated security coded by the developer into that server?
- How many developers are comfortable with developing applications in a microservices architecture and the coding changes required?
- How many admins are comfortable with technologies like Docker and Kubernetes, with managing on-premises or cloud versions and managing up-time of a microservices architecture?
I’ve still been developing XPages applications, I will continue to develop XPages applications, I will continue to encourage my customers to continue to develop XPages applications providing they’ve started that journey. It is still a good web development platform that more than does its job. The existing applications will still date better than traditional Domino web applications have.
But there is a lot of discussion about what people should change to. There’s a reason for this: for those who have gone beyond the basics, XPages has given Notes developers transferable skills so that they can ask what they should use instead. The same as it gave skills to the XPages team so that they were moved to other areas of ICS development.
Node.js development is an obvious choice. What may hold some customers back is deploying “additional” web servers and the DevOps requirements. Managing node.js servers is likely to be new to Domino admins and the best practices of coding for security will be new to developers. Managing access from those to the Domino servers is likely to involve new learning too. And it’s a method of development that will be new to all Notes or XPages developers. Just setting up the development environment is a learning curve in itself. Those who have just used Domino Designer will have a whole new toolset to get familiar with. For developers who chose not to embrace XPages because of the learning curve, or developers who stayed at drag-and-drop XPages with SSJS, many may never make this step.
That said, because of the experience I gained on XPages, I enjoyed React as well and enjoyed building a small application with new functions. But that’s because of the depth in which I’ve dived into how XPages actually works and the willingness gained to step beyond Domino Designer and embrace API-driven development rather than relying on a more WYSIWYG approach.
There’s been a lot of talk of other JSF-related frameworks like PrimeFaces. Personally, for Java my preference was set some years ago, and if I was to use a different Java framework it would most likely be Vaadin, most probably with Spring Boot. Vert.x is another I’ve played with, but Spring Boot seems more popular.
But a critical issue remains: I struggled to work out how to use non-Domino datasources with those frameworks – that area is framework-agnostic and so omitted from the tutorials. And if you’re integrating with Domino, then there are key areas of document and collection management that no out-of-the-box APIs or open source solutions seem to cover, in an easy consumable manner. Domino JNA may, it wasn’t around when I was doing that work, so I can’t comment. But this is where open sourcing XPages would have benefit beyond XPages – the challenges of Java access to Domino documents and attachments have already been addressed in XPages classes that are not currently available as source code. Alternatively, a Java gRPC approach to hook into DQL may also be a good way forward.
But regardless of the technology, I think HCL’s recommendation with Node.js is leading the way here. Java development, if it’s standard Java, is best outside the Domino HTTP stack and as standard as possible. This is the route chosen by many Java developers who have stepped beyond XPages, for example in CrossWorlds or sessions by Frank van der Linden.
The root here is that the HTTP stack has not been modernised greatly. Many XPages developers don’t understand OSGi or have an Eclipse development environment. Maven and OSGi don’t play nicely together. Examples do not abound and, as I have said, Spring Boot or Vert.x applications each packaging their own server seem to be a more popular approach. For full-fledged JavaEE, a server specifically targeting that like Tomcat or Websphere Liberty / Open Liberty seem more standard. These already deliver the latest servlet containers and HTTP/2.
None of these will require specialist XPages skills. Even creating renderers doesn’t require XPages knowledge – a renderer in XPages or Vaadin or React is all pretty similar. Replacing Dojo with jQuery – if that’s a preferred requirement – would be a more considerable effort. As would be updating the JSF version of XPages, but the ideas request for this has no information on what the actual benefits would be.
But whether this happens next year, in the next three years, not in the next five years – do I think I’ll have to completely redevelop all my XPages applications in the next five years?
I know of traditional Domino web applications that are still running. They may not look or feel great, but they feel better than some Notes Client applications I’ve had to use and the kind which will be deployed without changes to IBM Mobile Apps. XPages is still a decent framework that does a good job.
Is it the best that’s out there? No.
Is it RADD? It will be more RADD than other web alternatives for many XPages developers for a while.
Does it need some love? Yes.
Does it need a major overhaul. If you want to market it as a competitor to Vaadin or Node.js, yes, but that battle has been conceded, so no. And IBM Domino Mobile Apps / HCL Nomad is the obvious choice for offline mobile access to Domino applications, Apple’s avoidance of Java means there’s no chance of XPages offline access on an iPad, so the same is true for other mobile or desktop offline ProgressiveWeb Application access to XPages.
Is it dead? Only if it stops being used and XPages apps get redeveloped into something else.
So like the Notes Client in 2012, it’s not dead in my opinion, and in a worst case scenario won’t be for a while. And I have no qualms continue to develop on it or recommend it as a reasonable fit for customer applications.