Jesse Gallagher posted a thoughtful blog about the challenges for the way forward with XPages. It's a challenge I've had a number of discussions around, many of which are ongoing.
The reason there's not a simple solution - throw whatever resources are required into XPages - is that it simply doesn't make business sense. There are very emotional arguments, but there are some inescapable points which those emotionally invested into the technology rarely discuss:
- XPages did not grow the platform as was hoped.
- XPiNC was a nice idea, but it had problems that could never be overcome. The XulRunner (the web container for the application) got out of date, Mozilla deprecated it, "run on server" had a lot of quirks, and the extensibility (so powerful on the server) was never quite as easy on client.
- Dojo may have been a good choice at the time, but the rise of jQuery and Bootstrap wasn't anticipated. Integrating Bootstrap was achieved, but is constantly changing and introduces breaking changes (e.g. icons). Whereas jQuery or Bootstrap seem to focus on modules of web development, Dojo seems more monolithic. So replacing parts with something else are more problematic.
- The lightweight client will run in a browser, competing with XPages and traditional Domino web applications potentially. Authentication raises question marks about whether external users can use the lightweight client, an obvious expected requirement would be multiple browser tabs using multiple Notes IDs, which may be possible, but it's unclear whether the architecture will allow this.
- Offline on iOS was never a possibility, because of Apple's avoidance of running Java on iPad and iPhone. UPDATE: Jesse has reminded me that solutions like RoboVM can convert Java applications to run on iOS.
- There may be a lot of XPages applications out there, but as a percentage of all Notes applications, it's got to be small. I would estimate probably 5% at best.
- The XPages team at IBM reduced significantly as they were moved to other initiatives and do not appear to have been in scope for the acquisition, for whatever reasons. Whether teeth are gnashed or not, it won't change. And wailing about it at those responsible for the platform won't gain sympathy, it will just imply someone focused on resurrecting the past not moving forward.
- There are various enhancements required for the HTTP server - servlet container, web sockets, HTTP/2, adding LESS/SASS support to the NSF. These are required for modernising XPages, but is the HTTP server as it is a key component for the future? And would a more modern HTTP server be able to support XPages?
All of this means modernising XPages to what's required needs substantial investment, with little potential for growth of the platform as a result. Looking at it objectively, the return on investment is highly questionable at best.
One potential route, that has been discussed on occasion by various people, is open sourcing XPages. But the painful truth is that XPages will never appeal to an Apache or Eclipse open source organisation. OpenNTF is far too small. And even with an open source organisation backing it, I don't think there are enough developers willing or able to support it, because of the requirement for a developer base with the requisite technical skills and who are still invested in Domino.
But even if there were, there are still some platform-specific enhancements that would be required and some parts of the runtime that would almost certainly never be open sourced.
Java can run as Java anywhere. As Jesse says, there are some "XPages-isms" - the XspContext, the scope maps, etc. If you have the key Java classes for e.g. dominoDocuments and dominoViews, you get a long way to running it agnostically of the XPages runtime. But SSJS requires a lot more. It requires a Language Server Protocol in the IDE to give the content assist and validation. And it also requires something in the runtime to parse the SSJS, which is stored as text strings whether it's inline or in a Script Library, and process the calls.
Unfortunately, SSJS was never positioned as a stepping stone from LotusScript and Formula Language to Java. So many developers never progressed. Admittedly, even if IBM had proclaimed it as a stepping stone, I suspect there would still be a good proportion who would never have followed that advice.
So we have a lot of XPages applications that will always be a lot harder to port to something else, whatever is chosen.
The Challenge of Business Logic
Even if it was, that's just a fraction of XPages code. We don't trigger an onclick and just run the code. We pass back a portion of the web page, or more typically all of the web page. We process a portion or all of the XPage (the "execId"). And this runs SSJS or Java beyond just the onclick code. It runs SSJS or Java that's tied to specific UI components, that manipulates the properties of those components. And it returns HTML for a portion of the web page (the "refreshId").
Converting SSJS or Java to REST services may not cover more than a small percentage of the business logic coded into an XPages application. The bulk of it may be tied to components.
And this is where the wide variety of XPages applications has a big impact - that XPages is quite accommodating, letting you code how you wish and adapting accordingly. And this is why converting XML to components is the easy part of the problem and why whatever solution arises, it won't be quick.