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 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?


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.

6 thoughts on “Whither XPages?”

  1. Very interesting. I can’t speak much to the more technical aspects as I mostly deal with Notes/Domino (whether XPages or Classic Domino or Java or JavaScript) from the inside API level not the outside UI level. But what I am struck by most in both your reference back to the 2012 Notes client predictions and your current XPages predictions is the analogy with turning a large cruise ship. You don’t do it easily or quickly or without a damn good reason. There may be smaller, quicker, more agile ships, but you already have a ticket on this one, so it is easiest to stick with it. Most large businesses, and many small ones, may fully recognize that those other ships are out there, and still make a sound business decision to stay the course, so long as the large cruise ship hasn’t run aground. HCL’s biggest goal in V10 is to give them faith that the ship is still floating. Their biggest goal in V11 will likely be to build in some reasons for others to climb on board while keeping current customers on course.

    1. I agree. But I’d also take the analogy further and say the flexibility of Domino and the knowledge of the platform also means the ticket also gives you cheaper priced tickets for the other cruises by the same company. The challenge for IBM for V11 and beyond is making a wider audience aware of the cruise ship and promoting the tickets.

  2. Very interesting article. You have many more knowledge that me regarding Domino and all this technology. If you allow me, I’d like to give you my background so you get a better understanding on my position regarding XPages, Java, etc…

    My background: I’ve personally been developing Apps on Domino R3… from 1992 to 2002 and my company still use Domino (xWork) to package our LowCode development platform build on Domino. We decided to move away from the Notes client in 2006 just before the first iPhone was introduce. We wanted our customers to access their information (mostly business workflows) anywhere without the need of deploying anything on their PC (they may had Notes on their office PC, but not @ home). We didn’t got into XPages. At the time, we could not wait for the different components to shipped and we needed to move fast.

    So we developed a new front-end for PC and another one for Mobile (ExtJS and Sencha Touch). In 2010, after maintaining 2 different front-end we moved to Bootstrap to build our next release that would be a responsive web app coded mostly in Lotusscript and Java to generate javascript, json, html and css. In 2012 we wanted to bring our platform to the CLOUD but we still had one or two pieces of software (our Studio and Reporting) that used client-server stuff. This is not very compatible with a CLOUD approche. The other thing for us, in regard to the CLOUD, is the scalability of Domino which is the main reason for us to move away from Domino today.

    Last December I attended the Domino 2025 Jam session in Toronto (Canada) and most developers wanted to see more javascript in Domino mostly to HELP GETTING NEW DEVELOPERS ONBOARD. Here in Canada, it is very hard to find Notes Developers. I think that too many Notes Developers stop learning new technologies and stick with Lotusscript and sometimes Java.

    We really loved Notes/Domino for all of what you described Paul, but we won’t wait for its revival or its death. We need to move on.


    – Pierre

    1. Thank you for taking the time to comment in such depth. It sounds like you’ve built a very powerful application using the platform and it doesn’t sound like the enhancements will easily address the scalability issues you have. DQL performance stats I’ve heard from talking to the developers and at conferences are impressive. But it sounds like scalability of the agents may be a problem you’re hitting rather than document read performance.

      What you say about the reasons for JavaScript in Domino coincides with what I heard from the jam I was at and from others. Hopefully some customers will see it as an opportunity to give then the depth their looking for in their team, and allow both old and new to learn from one another. I agree with what you say about too many Notes Developers not wanting to learn new technologies. I’ve had discussions with various people this year about the challenges of taking people on a journey they may be reluctant to make, and a team with Notes and JavaScript developers together may give them the support and encouragement to learn.

      Good luck with wherever you go next. From your experience it sounds like you’ve got plenty of skills to give you a wealth of options.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top