Whither XPages?

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

Some may disagree with me, but I firmly believe XPages is still relevant. I’ve said throughout this year that XPages is still miles ahead of JavaScript development on Domino.

• How many customers regularly deploy JavaScript applications?
• How many use a REST service API layer as the standard interface for new Domino-backed applications?
• How many customers have developers who are not comfortable with HTML, CSS and JavaScript?
• 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?

The simple fact is that when HCL took over XPages was way head of JavaScript development and how enterprises deploy web applications, it still is today when V10 has been released and for many customers it still will be for many months to come.

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.

So what are the options? Firstly, let me say expanding learning is nothing new. In an XPages developer roadmap I created a few years ago I was already encouraging people to step beyond XPages, whether that be JavaScript development with bootstrap or jQuery (at the time) or Java development with frameworks like Vaadin.

Node.js

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.

Earlier this year John Jardin built a React application with Redux for state management and a separate websockets server talking to a Node-RED server for routing. I spent some days going through the application commenting it. Because of my work on REST services, because of getting familiar with Visual Studio Code, because of familiarity with Node-RED, because of a deep understanding of what happens under the hood of XPages for state management, because of understanding the server-side lifecycle steps in XPages, because of a strong familiarity with MVC in XPages – because of all this I was able to feel reasonably familiar with a React application that was beyond a “hello world” basic example. Even so, I was often flipping between multiple JavaScript files, keeping the complex structure of multiple functions in my head. Few if any Domino developers will have manually coded any server-side state management, and experience of Redux gave me an additional appreciation for what in XPages – as with so much of Domino – just works. Keeping in my mind what the current state would be on the web page, in the Redux state store and in the backend Domino application was something I was pretty comfortable with, because it’s the similar in XPages – if you understand the structure of web page, component tree and database. For many XPages developers and certainly Notes developers, all of this could be overwhelming. As I was commenting it with a thorough understanding of what was intended, what happened on the front-end and the architecture, the risk of obtuse mistakes and spaghetti code from those less familiar was obvious.

I don’t know Vue.js or Angular (although Angular itself seems to be on the wane). So I can’t say how easy they would be for Notes developers or those XPages developers who are not comfortable with JavaScript or TypeScript. Vue is often positioned as less complex. And Thilo Volprich’s session at ICON UK sold it very well. But there’s a lot that would draw on what I’ve learned by moving away from what might be called basic XPages development.

Yes, JavaScript developers can be recruited and will easily be able to pick up Domino. But unless significant training is made available and embraced by existing Notes and Domino developers, I would say they will not be comfortable in Node.js development for some time. Indeed a good XPages developer will still be able to build more complex applications in XPages significantly more quickly than they could in Node.js well beyond Domino V11, based on the number of new applications I see commissioned by customers. And personally I feel XPages with Bootstrap 3.x gives a decent enough look and feel, and the feedback I’ve had from customers is positive.

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.

Java Development

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.

Domino HTTP

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.

HTTP/2 is a significant step forward and obviously does not require specialist XPages knowledge. I’m not sure what the benefits of updating the servlet container to 3.0 would be for XPages. For CSS management within the NSF, SASS or LESS or SCSS have become more standard. JavaScript editing within the NSF is not great. And then there’s web sockets. For our IBM Think application, websockets was it’s own Node.js server. With the obvious PubSub enhancements coming in the future in or adjacent to Domino, should websockets be part of the Domino HTTP stack or separate? An assumption has always been that it should be part of Domino, but that was before Node.js was part of the Domino app dev landscape.

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?

No.

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.