I was fortunate enough to have a number of discussions with various people from IBM and HCL while I was at IBM Think. Some of those were with people I’ve known for a while, like Jason Gary and Barry Rosen, while others were with newer contacts like John Paganetti, Andrew Manby and the (quite new) marketing people. John Paganetti is a name I’ve known for a while but not someone I’ve ever really met before. His knowledge of the Domino server is profound and it’s good to see that he and other key IBM technical staff are heavily involved in the future. It’s also great to see Jason Gary in such a pivotal role at HCL and I hope he’s allowed to do what he can for the products. He may have been seen as a loss for Connections by some, but that reinforces what is evident, that he is a big win for Domino. His time with a Connections shows that he is not averse to making hard decisions for the best of the product and willing to embrace innovative approaches, as well as work closely with the community. As someone who’s been more than willing to work for the best of the product from an open source standpoint, that’s very welcome. My time may get more limited as I work on other initiatives for the ICS portfolio, and my knowledge on JavaScript technologies may currently be limited, but I will continue to be involved in a variety of roles (as I already have).
A comment first on atmosphere around the brand: it’s refreshing to see the enthusiasm and fun around the brand, as well as the effort around marketing already in place (all those Domino2025 stickers and other products, as well as the Destination Domino microsite which will evolve as time goes by). I look forward to continuing to work with these people throughout the year and beyond, as before.
Before IBM Think, at the end of February NodeJS support and Elastic Search was announced in the webinar. At Think it was confirmed that the initial delivery will include an npm module to provide CRUD access to Domino via JavaScript APIs equivalent to the NotesDatabase and NotesDocument classes, but I asked if this would continue to embrace other Domino APIs. I’m very passionate that the strength of Domino is not just as the original NoSQL database. It is way more than a dumb NoSQL database. The APIs ensure that Domino provides a consistent master API layer for workflow and Mail routing as well as server and user management. There are even APIs for encryption management and APIs have been built for management of design elements. The richness of the API layer, which is an integral part of all Domino app dev, is something ignored by many migration demos and a major reason DAS has not provided the bridge to JavaScript development.
This is a good time to mention a discussion I had with Theo Heselmans on the Sunday before Think. He asked how I felt about the focus on JavaScript development in the webinar, considering my heavy preference for Java. I’ve never been one to put personal desires before wider needs: what’s the point in preferring Java on Domino if the focus in development of the product means customers continue to move away to the extent that there are not enough left? It would be a Pyrrhic victory in which all would suffer. At this time, Java development on Domino and XPages is in a relatively strong position. We are able to do what we need, able to integrate standard non-proprietary code in a standard way. We are able to leverage Java 8 now and most samples on the web will work with Java 8 syntax. The servlet container may be dated, but it is an edge case for which anyone who wishes to use something more recent has the skills and certainly the samples to take an alternative approach. Java is not where work was required and Java is not where the competition for Domino comes. NodeJS is the right area for focus and the right approach at this time. And as my recent work on Node-RED has shown me, it has significant benefits for all developers. If they have not already, developers should investigate Node-RED and bear in mind that it should be possible to combine Node-based web pages alongside XPages or traditional Domino web pages, for greater flexibility and ability to use best of breed where appropriate (e.g. node-RED dashboards).
This emphasis on NodeJS and app dev should also be seen in context. A key requirement for HCL is to grow the products. Attracting younger and new developers will not come by competing with Java frameworks like Spring or Vaadin but by addressing JavaScript developers. JavaScript developers are also typically more familiar with NoSQL than SQL. So taking the necessary steps to attract JavaScript developers – whether people think that is too late or not – makes total sense. It is also the major aspect where Domino has, over the last ten years, done least to enhance support. Domino V10 will also move towards standard open source functionality like JWT, OAuth and OpenID for more flexible authentication and inter-operability options. This also makes sense and will benefit all web developers on Domino.
Notes on an iPad was announced. This required ID Vault , supports encryption and all Domino security. It only allows a single ID and connection to a single Domino server, but for most end users that will be sufficient. Offline usage is supported and this will be the big benefit, although careful thought will be required around replication formulas. It will be available through the app store and supports all standard Notes functionality. Some components are styled to fit more in with iOS functionality (e.g. dialogs, pickers etc). On the whole, most functionality will just work (including formula language and LotusScript). iPhone will require coding changes to fit the form factor, but the groundwork will be laid in Domino V10 to make those coding changes. Android tablet support will follow, though it’s unclear the effort required and so a realistic timescale to commit at this point. Fitting in with this, Windows support will also work for touchscreen in Notes Clien to support those devices.
However, the fact Notes apps will predominantly “just work” must not mean customers do nothing. Application modernisation is not about giving it a web UI. It’s about giving it a modern feel. Putting an app that is ten years old and looks it onto an iPad is not modernisation. It’s a travesty and a tragedy, it is an IT crime. For the love of Domino, spend some time reviewing the apps you’re deploying to iPad to ensure they look half decent. Otherwise spend the money to migrate them off the platform. If, because of IT laziness or line of business unwillingness to invest, an app makes Domino look bad then it’s bad for Domino: get it off the platform I love and suffer elsewhere!
The key background that needs to be borne in mind with the announcement about Notes on iPad has two aspects. Firstly, no one – IBM, third parties or migrators – have come up with a good, cost-effective tool to modernise Notes Client applications for mobile devices. Notes on iPad was achievable for Domino V10 and also supports offline usage. Secondly, Apple do not support Java on their devices. So XPages for offline support is not a viable option and Android (which does use Java) is not a major competitor for Apple in the enterprise. In the context of these key deciding factors, the approach is understandable and should not be deemed as anti-XPages, just pro-iPad and iPhone, whilst still leaving room for Android in the future. Like the common code set announced at IBM Think for Windows and iOS desktop clients, it is logically sensible to ensure best ability to support the platform going forward.
In terms of XPages, Bootstrap 4 support was also stated as an enhancement again. Application developers and customers should be aware that XPages is already very mature as a development framework and is not particularly lacking for browser development. Looking at functionality added in future versions of JSF but not already ported back into XPages, there does not appear to be anything significan that would be a game-changer for all developers. If there is, I haven’t seen anyone blogging about it or giving those examples during the Domino2025 Jam. And if customers do consider using JavaScript frameworks in the future, effort will be already have been minimised if they have taken the approach I’ve recommended in my Java training course of minimising code on an XPage so it just covers UI and using controller classes and separating business logic into Java classes and methods merely referenced on the XPage. It’s one Jesse Gallagher enabled with his open source projects. But XPages support is not in consideration for removal, is still very strong for those who have embraced it, and is still a quicker route than other web development frameworks for custom application development.
For anyone considering whether, in hindsight, XPages was a mistake from IBM, it’s important to bear in mind the state of web development in 2009 and the Domino development landscape, when XPages was released. To my knowledge jQuery was barely known, Bootstrap wasn’t around, AngularJS and React didn’t exist. Dojo was the front-end web development framework I was already using in web projects. In the Java web development landscape, JSF was the best-known mature framework. Web development on Domino needed urgent action and many Notes devs did not have adequate HTML, JavaScript and CSS skills. XPages made and makes sense in that context, not least because it supported Notes developers around HTML, JavaScript and CSS. Three years ago, DAS existed but was not an appropriate API layer – nor is it still. Those who had not moved from Notes development typically still lacked HTML, JavaScript and CSS skills. They certainly lacked skills to create effective REST service APIs. Was npm as pervasive or was AngularJS / React a viable option for Domino app dev in the 9.0.1 timeframe? It’s hard to make an argument for that and few in the community took that route, though I know of some advanced individuals who did. Did IBM make the wrong choice at the time or misdirect developers? I think it’s hard to justify IBM taking any other route for Domino 8.5 or, given the resources available at the time, for 9.0.1. I would have preferred if IBM had strongly recommend developers move on from SSJS and separate UI and business logic better a few years ago, but IBM have historically tried not to be prescriptive about a certain style of development. But I firmly believe XPages was right at the time, still has a valid place in the present and a future for those comfortable with it who require rapid app dev for web and mobile. If the full XPages component library is open sourced, the community may give it a future not yet envisaged. But it’s worth stating that the developer roadmaps I created some years ago didn’t stop at XPages and encouraged developers to investigate other JavaScript and Java frameworks, so I’ve never considered XPages the sole endpoint. After IBM Connect last year I developed a training course on REST services on Domino, I’ve created an OpenNTF project that makes it easier for XPages Java developers to build their own REST services, I’ve just delivered a session where I built a REST service for Domino to be consumed by a JavaScript app by John Jardin and integrate with Watson Workspace, so it’s consistent with my work over the last year or two. But I’m glad I embraced XPages. It helped me transition and I’m still transitioning as I see benefits of Node-RED. Hopefully XPages also helped transition those I’ve trained. And I hope it will be as feasible to integrate NodeJS elements into XPages solutions as it has been to integrate XPages elements in traditional Domino web solutions. Ideally this is not a shock for anyone, but web development and the experience of the last few years has taught me one thing above all: for everyone involved in IT and development, change and the necessity to keep learning is at the core of our careers. In the words of Solon, the lawgiver of Athens in 6th century BC, “I grow old always learning more”.
The interessting question from my side point of view is how IBM / HCL will support the developers when using Node.js on Domino. Will there any good documentation, examples etc. available?
XPages was and is still a good option to develop modern applications, but it is a shame that only a few know how to use and extend it correctly. Knowledge is the key for success. I think it was the biggest mistake by IBM not to bring more effort for the quality of the developer support. If they won’t change their behavior the Node.js adoption will fail like it failed with XPages before.
From my side the running of a Node.js application on Domino is nothing new. Did this two years ago. Nothing spectacular.
Today my daily development for Domino is mostly using the Spring Boot framework which runs fine as OSGi plugin. But there is still no support for modern servlets, so WebSockets are still not an option. That’s why I now plan to run my apps directly in the Domino JVM without using the HTTP task. “mvn spring-boot:run”, that’s it. This allows the latest IDE with the freshest tools currently available, gives access to the complete Domino stack and cuts the dependency of IBM as much as possible.
Dear HCL, please update the JVM reguallary. That’s everything I need. Then the other points on my 15 year old wish list are no longer required.