• Anonymous
  • Login
  • Register

Welcome to OpenNTF.org

The Mission of OpenNTF is to support the open source projects hosted at OpenNTF.Org. OpenNTF provides the framework to develop open source applications which may be freely distributed.

Browse the catalogs to find the latests releases you're looking for which have been made available under the Apache license or under the GPL license. Browse the project area to find the latest project updates before they have been cleared.

Collabsphere 2019 Beauty Contest

Paul Withers | 7:29:00 AM Wednesday, July 10, 2019 | Full Story and Comments
Yesterday Richard Moy announced a new contest to provide a modern user experience for DMA to a traditional Notes template.

After contest in recent years for Connections Customizer and XPages, now is the right time to engage with LotusScript and Formula Language developers and re-energise that community around open source.

There are many developers who never made the jump to XPages and may not make the leap to the App Dev Pack. But IBM and HCL's launch of DMA has brought an additional entry point to Notes Client applications. HCL's work on iPhone and Android (tablet and phone) DMA apps with expand that reach across the two main mobile platforms. And with V11 the lightweight client is likely to bring Notes Client applications to any modern browser. Applications built with traditional design elements, LotusScript and Formula Language can have a greater reach than ever before. And OpenNTF is still here ready to embrace those open source samples to wow users and educate developers.

But most client applications on OpenNTF have not had a facelift in a decade. And the facelift given to the core templates is not one that works outside the Eclipse client. The world has moved on, expectations have changed, and it's time for applications to modernise as well. Technology is not a barrier to user experience. Just because it's Notes doesn't mean it can't be fresh, as Theo Heselmans showed with his Wine Tasting App. Paul Withers also delivered a session at Engage earlier this year on modernising applications including adding a DMA interface to the XPages Extension Library database. There is a blog post going into more detail.

So while you're waiting for the template to be selected and the start of the contest, take a look at these and think about innovative approaches.

Once the contest starts, there will be people available to act as mentors for teams. And the template itself will be packaged with the relevant license and notice files, plus starter markdown documentation file, ready for final deployment to OpenNTF. If teams want a GitHub repository setting up under OpenNTF for source control, we can do so. We also advise on issues templates / feature request templates / CLA process integration on GitHub.

Engage-ing With Our Community

Paul Withers | 2:29:46 PM Saturday, May 18, 2019 | Full Story and Comments
Nearly half of the OpenNTF board members were present at Engage - Paul Withers, Oliver Busse, Jesse Gallagher, Graham Acres and Serdar Basegmez. Hopefully everone had a good time at the showcase reception on Tuesday evening we co-sponsored with HADSL. We had a round table on Tuesday morning that was very well attended, with a lively discussion. In the build-up we posted seven poll questions on Twitter. Thanks to all who got involved, though because of technical challenges the questions were only posted during the opening session of Engage.


The results reinforced the theme of the round table, that the developer tools that will be used for development against Domino in the next decade will be different to those for the last decade. First off, we stated Domino Designer - enhancement or replacement - was out of scope of the round table. In terms of the rise of exposure to other development tools, this is already happening with sessions at Engage on Docker and more. But many have yet to be familiar with tools and techniques that are standard outside of the yellowverse. This was reinforced with responses around Maven, Gradle and npm. Although many had some experience (particularly of npm), few considered themselves familiar enough. This isn't surprising considering many confirmed they came from a citizen developer background. There are a lot of educational resources available, but they are not specifically targeted at our community and don't provide a simple single end-to-end tutorial taking you from zero to hero. But there was a strong experience of Java amongst the audience, as well as for XPages - not a surprise. There will be a lot of interest in the future Java domino-db module - hopefully integrating with proton and hopefully available centrally, like other Java SDKs, on places like Maven Central. In terms of proton and gRPC itself, there seemed not great understanding of performance metrics vs HTTP. Maybe this explains why so few have tried the app dev pack and may prefer to stay with more familiar options for REST services like XPages.

In terms of XPages itself, the final question to our audience confirmed that many would feel open sourcing XPages would be something they would welcome, and more than expected said that they would be interested in getting involved, although technical knowledge is of course a key requirement. What the future or best outcome on XPages will be, it's too early to know. PrimeFaces has been raised by some as a preferable framework, though not widely.

Regardless of XPages, Java or Node.js, Notes Client development has had a resurgence. And that option - probably the clearest RADD option - now supports mobile and, potentially in the future, web through the lightweight client. Sametime has a renewed focus as well, and it's worth reiterating that OpenNTF has always supported projects for Sametime as well. Once the deal closes, Connections is also expected to receive increased focus and we support projects for that too. It's best to finish our review of the round table with a tweet from Graham Acres, "We encourage members of the #dominoforever community to join and contribute. It doesn’t have to be your own idea. Join an existing project. Write documentation. There are lots of opportunities to help each other. @openntf at #engageug"

Before we finish, we would like to wish a speedy recovery to our chairman Christian Guedemann.

OpenNTF at Engage

Paul Withers | 3:51:16 AM Friday, May 3, 2019 | Full Story and Comments
It‘s probably fitting thatI’m writing a blog post about Engage sat in a coffee shop, on my iPad, using Domino Mobile Apps. The last year has brought the product a long way and one of the most significant new projects has been Theo Heselmans’ Wine App. Admittedly the OpenNTF Blog database is unchanged from the desktop version, but it’s probably only going to be seen by a handful of people, so investment is less beneficial.

But to get to the reason for this blog post, in a little over a week, OpenNTF will be in attendance at Engage. We’re proud to co-sponsor the Sponsor Showcase event on Tuesday night, but we’ll also be involved heavily throughout the event. Graham Acres, Jesse Gallagher, Oliver Busse, Paul Withers and Serdar Basegmez will be in attendance and happy to speak all things open source.

We have our OpenNTF round table on Tuesday 11.45 in R1 called “Developer Tools for the Next Decade”, hosted by Serdar Basegmez and Paul Withers.

Graham Acres has a session on Wednesday 11.30 in Room D (Minerva) called “What is Cool with Domino V10, Proton and Node.js, and why would I use it in my Domino Apps Anyway?”

Jesse Gallagher has a session on Tuesday at 16.00 in Room E (Mahy) called “Java with Domino after XPages”.

Oliver Busse has a session with Jan Krejcarek on Wednesday in Room E (Mahy) at 14.45 called “The NERD stuff: opening Domino to the modern web developer”.

Paul Withers has three other sessions.
Tuesday at 17.00 in Room D (Minerva) with Fredrik Malmborg called “Introduction to Node-RED”.
Wednesday at 09.00 in Room D (Minerva) called “Modernizing Your Domino and XPages Applications”.
Wednesday at 12.00 in Room E (Mahy) called “AI - What Is It Good For?”

Serdar Basegmez has a session on Wednesday at 13.30 in Room E (Mahy) with Tom van Aken called “Your Data in the Major Leagues: A Practical and Updated Guide to RESTful Domino v10”.

There are more sessions that can be named by contributors and helpers of OpenNTF, and we thank you all for your continuing efforts.

NSF ODP Tooling 2.0

Jesse Gallagher | 10:30:00 AM Friday, April 5, 2019 | Full Story and Comments
The other week, version 2.0 of the NSF ODP Tooling project was released. This project allows for the compilation and generation of on-disk-project representations of NSFs without the use of Designer, and as part of a tree of Maven projects. This release has several important improvements:

- Full round-trip fidelity for NSFs<->ODPs to match Designer's behavior
- Local compilation and export on platforms supported by the Notes client or Domino
- Improvements to the Eclipse tooling to provide Design Element categories and XML editor hooks for DXL files
- Automatic generation of missing .metadata files; for example, for new XPages or resources added to the project outside of Designer
- Maven-side generation of plugin files for cross-IDE compatibility

I've recorded a video going over the example project included in the repository, which is itself available on GitHub.

Request for Action: Project Steering Committee

Paul Withers | 7:59:52 AM Monday, March 25, 2019 | Full Story and Comments
OpenNTF has had a steady stream of contributions over recent years, adding to a large corpus of contributions during this century. There is also renewed focus on Domino, potential for new markets of JavaScript developers with Domino, imminent new releases of Sametime, Connections in the process of being acquired by HCL, and a number of other products already in ownership or being acquired by HCL. The board have appreciated the need for revisiting project approaches and management of key projects, to ensure greater scalability for the future, reach beyond traditional project categories and ensure better consumption of quality projects. After all, OpenNTF pre-dates YouTube (2005) and GitHub (2008), as well as most currently-active ICS-related blogs.

But we want you, our OpenNTF community, to be involved in building this future. We have some ideas, but we want to form a Project Steering Committee to review those ideas and come up with a formal proposal to the board. This will touch all aspects of the contributor process and probably resurrect or modernise existing roles like committers. The Project Steering Committee is expected to evolve into product-specific committees, ensuring review and overseeing of key projects for those products. But this inaugural committee will have a different focus, on recommendations only, and there is no obligation on your time beyond the adoption of the recommendations. However, this is an opportunity to get involved at the earliest stage.

We would like to move quite quickly, formalising the proposals before autumn if possible. As an initial step, the team will be brought together in a private Slack channel. So please reach out to one of the board members in the general channel of OpenNTF's Slack if you wish to be involved.

This is your community, and we can only function if there is a committed community of active participants. So please take this opportunity.

AbstractCompiledPage, Missing Plugins, and MANIFEST.MF in FP10 and V10.x

Jesse Gallagher | 9:31:36 AM Monday, February 25, 2019 | Full Story and Comments
(This entry is cross-posted from frostillic.us)

Since 9.0.1 FP 10, and including V10 because it's largely identical for this purpose, I've encountered and seen others encountering a couple strange problems with compiling XPages projects. This is a perfect opporunity for me to spin a tale about the undergirding frameworks, but I'll start out with the immediate symptoms and their fixes.

The Symptoms

There are three broad categories of problems I've seen:

- "AbstractCompiledPage cannot be resolved to a type"
- Missing third-party XPages libraries, such as ODA, resulting in messages like "The import org.openntf cannot be resolved"
- Complaints about MANIFEST.MF, like "MANIFEST.MF has no main section" and others

The first two are usually directly related and have the same fix, while the second can also be caused by some other sources, and the last one is entirely distinct.

Fix #1: The Target Platform

For the first two are based on problems in the active Target Platform, namely one or both of the standard platform components go missing. The upshot is that you want your Target Platform preferences to look something like this:

Working target platform

There should be a selected platform (the name doesn't matter, but "Running Platform" is the default name) with entries at least for ${eclipse_home} and for a directory inside your Notes data dir, here C:\Notes\Data\workspace\applications\eclipse. If they're missing, modify an existing platform or create a new one and add an "Installation"-type entry for ${eclipse_home} and a "Directory"-type one for the eclipse directory within your data dir.

Fix #2: Broken Plugins, Particularly ODA

Though V10 didn't change much when it comes to XPages, there are a few small differences. One in particular bit ODA: we had a dependency on the com.ibm.domino.commons plugin, which was in the standard Notes environment previously but is not as of V10 (though it's still present on the server). We fixed that one in the V10 release, and so you should update your ODA version if you hit this trouble. I don't think I've seen other plugins with this issue in the V10 transition, but it's a possibility if Fix #1 doesn't do it.


This one barely qualifies as a "fix", but it worked for me: if you see Designer complaining about MANIFEST.MF, you can usually beat it into submission by cleaning/rebuilding the project in question. The trouble is that Designer is, for some reason, skipping a step of the XPages compilation process, and cleaning usually kicks it into gear.

I've also seen others have success by deleting the error entry in the Errors view (which is actually a thing that you can do) and never seeing it again. I suspect that the real fix here is the same as above: during the next build, Designer creates the file properly and it goes away on its own.

The Causes

So what are the sources of these problems? The root reason is that Designer is a sprawling mountain of code, built on ancient frameworks and maintained by a diminished development team, but the immediate causes have to do with OSGi.

The first type of trouble - the target platform - most likely has to do with a change in the way Eclipse manages target platforms (look at the same prefs screen in 9.0.1 stock and you'll see it's quite different), and I suspect that there's a bug in the code that migrates between the two formats, possibly due to the dramatic age difference in the underlying Eclipse versions.

The second type of trouble - the MANIFEST.MF - is due to a behind-the-scenes switch in how Designer (and maybe the server) handles dependencies in XPages projects.

Target Platforms

The mechanism that OSGi projects - such as XPages applications - use for determining their dependencies at build time is the notion of a "Target Platform". The "target" refers to the notion that this is the platform that is expected to be available at runtime for what you're building - loosely equivalent to a basic Java classpath. An OSGi project is checked against this Target Platform to determine which classes are available based on their bundle names and versions.

This is distinct from the related concept of a "Running Platform". Designer, being based on Eclipse, is itself built on and runs using OSGi. Internally, it uses the same mechanisms that an XPages application does to determine what plugins it knows about and what services those plugins provide.

This distinction has historically been hidden from XPages developers due to the way the default Target Platform is set up, pointing at the same Running Platform it's using. So Designer itself has the core XPages plugins running, and it also exposes them to XPages applications as the Target. Similarly, the way we install XPages Libraries like ODA is to install them outright into the Designer Running Platform. This allows Designer to know about the library service provided, which it uses to populate the list of available plugins in the Xsp Properties editors.

However, as our trouble demonstrates, they're not inherently the same thing. In standalone OSGi development in Eclipse, it's often useful to have a Target Platform distinct from the Running Platform - such as the XPages environment for plugins - to ensure that you only depend on plugins that will be available at runtime. But when the two diverge in Designer, you end up with situations like this, where Designer-the-application knows about the XPages runtime and plugins and constructs an XPages project and translates XSP to Java using them, but then the compilation process with its empty Target Platform has no idea how to actually compile the generated code.


I've mentioned that an OSGi project "determines its dependencies" out of the Target Platform, but didn't mention the way it does that. The specific mechanism has changed over time (which is the source of our trouble), but the idea is that, in addition to the Java classes and resources, an OSGi bundle (or plugin) has a file that declares the names of the plugins it needs, including potentially a version range. So, for example, a plugin might say "I need org.apache.httpcomponents.httpclient at least version 4.5, but not 5.0 or higher". The compiler uses the Target Platform to find a matching plugin to compile the code, and the runtime environment (Domino in our case) does the same with its Running Platform when loading.

(Side note: you can also specify Java packages to include from any plugin instead of specific plugin names, but Designer does not do that, so it's not important for this purpose.)

(Other side note: this distinction comes, I believe, from Eclipse's switch from its own mechanism to OSGi in its 3.0 release, but I use "OSGi" to cover the general concept here.)

The old way to do this was in a file called "plugin.xml". If you look inside any XPages application in Package Explorer, you'll see this file and the contents will look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin class="plugin.Activator"
  id="Galatea2dVCC_2fIKSG_dev5csyncagent_nsf" name="Domino Designer"
  provider="TODO" version="1.0.0">
    <!--AUTOGEN-START-BUILDER: Automatically generated by null. Do not modify.-->
    <import plugin="org.eclipse.ui"/>
    <import plugin="org.eclipse.core.runtime"/>
    <import optional="true" plugin="com.ibm.commons"/>
    <import optional="true" plugin="com.ibm.commons.xml"/>
    <import optional="true" plugin="com.ibm.commons.vfs"/>
    <import optional="true" plugin="com.ibm.jscript"/>
    <import optional="true" plugin="com.ibm.designer.runtime.directory"/>
    <import optional="true" plugin="com.ibm.designer.runtime"/>
    <import optional="true" plugin="com.ibm.xsp.core"/>
    <import optional="true" plugin="com.ibm.xsp.extsn"/>
    <import optional="true" plugin="com.ibm.xsp.designer"/>
    <import optional="true" plugin="com.ibm.xsp.domino"/>
    <import optional="true" plugin="com.ibm.notes.java.api"/>
    <import optional="true" plugin="com.ibm.xsp.rcp"/>
    <import optional="true" plugin="org.openntf.domino.xsp"/>
    <!--AUTOGEN-END-BUILDER: End of automatically generated section-->

You can see it here declaring a name for the pseudo-plugin that "is" the XPages application (oddly, "Domino Designer"), a couple other metadata bits, and, most importantly, the list of required plugins. This is the list that Designer historically (and maybe still; it's not clear) uses to populate the "Plug-in Dependencies" section in the Package Explorer view. It trawls through the Target Platform, finds a matching version of each of the named plugins (the latest version, since these have no specified ranges), adds it to the list, and recursively does the same for any re-exported dependencies of those plugins. "Re-exported" isn't exposed here as a concept, but it is a distinction in normal OSGi plugins.

Designer derives its starting points here from implicit required libraries in XPages applications (all those "org.eclipse" and "com.ibm" ones above) as well as through the special mechanism of XspLibrary extension contributions from plugins installed in the Running Platform. This is why a plugin like ODA has to be installed in Designer itself: in the runtime, it asks its plugins if they have any XspLibrary classes and uses those to determine the third-party plugin to load. Here, ODA declares that its library needs org.openntf.domino.xsp, so Designer adds that and its re-exported dependencies to the Plug-in Dependencies group.

With its switch to OSGi in the 3.x series circa 2005, most of the functionality of plugin.xml moved to a file called "META-INF/MANIFEST.MF". This starkly-named file is a standard part of Java, and OSGi extends it to include bundle/plugin metadata and dependency declarations. As of 9.0.1 FP10, Designer also generates one of these (or is supposed to) when assembling the XPages project. For the same project, it looks like this:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Domino Designer
Bundle-SymbolicName: Galatea2dVCC_2fIKSG_dev5csyncagent_nsf;singleton:=true
Bundle-Version: 1.0.0
Bundle-Vendor: TODO
Require-Bundle: org.eclipse.ui,
Eclipse-LazyStart: false

You can see much of the same information (though oddly not the Activator class) here, switched to the new format. This matches what you'll work with in normal OSGi plugins. For Eclipse/Equinox-targeted plugins, like XPages libraries, plugin.xml still exists, but it's reduced to just declaring extension points and contributions, and no longer includes dependency or name information.

Eclipse had moved to full OSGi by the time of Designer's pre-FP10 basis (2008's 3.4 Ganymede), but XPages's history goes back further, so I guess that the old-style Eclipse plugin.xml route is a relic of that. For a good while, Eclipse worked with the older-style plugins without batting an eye. FP10 brought a move to 2016's Eclipse 4.6 Neon, though, and I'm guessing that Eclipse dropped the backwards compatibility somewhere in the intervening eight years, so the XPages build process had to be adapted to generate both the older plugin.xml files for backwards compatibility as well as the newer MANIFEST.MF files.

I can't tell what the cause is, but, sometimes, Designer fails to populate the contents of this file. It might have something to do with the order of the builders in the internal Eclipse project file or some inner exception that manifests as an incomplete build. Regardless, doing a project clean and usually jogs Designer into doing its job.


The mix of layering a virtual Eclipse project over an NSF, the intricacies of OSGi, and IBM's general desire to insulate XPages developers from the black magic behind the scenes leads to any number of opportunities for bugs like these to crop up. Honestly, it's impressive that the whole things holds together as well as it does. Even though it doesn't seem like it to look at the user-visible changes, the framework changes in FP10 were massive, and it's not at all surprising that things like this would crop up. It's just a little unfortunate that the fixes are in no way obvious unless you've been stewing in this stuff for years.

Re-Launching OpenNTF Snippets

Paul Withers | 6:56:56 AM Friday, February 8, 2019 | Full Story and Comments
In time for IBM Think's Community Day, we're relaunching our snippets site.

If you haven't noticed, things have been changing as OpenNTF has more explicitly embraced a wider community. Yes, we've always covered all of what has been IBM Collaboration Solutions / HCL Collaboration Workflow Platforms. But those outside Domino development have been more of a peripheral audience. That has never been a deliberate or conscious decision, but our core output - "projects" - have generally been developer-related (although Easy Admin Tools from Paul Brigden is a welcome and notable exception recently). XSnippets was developed as a replacement for the old code bin, but was again focused on developers. And OpenCode4Connections was also aimed, primarily, at developer-related extensions to Connections.

Well, with the latest update to our snippets site, we're more explicitly addressing that.

Firstly, we're renaming the site OpenNTF Snippets. That's a natural step considering the focus of content is significantly more than XPages and to make the site more notably OpenNTF. And secondly, the list of languages has significantly expanded. These are grouped into specific areas:
- XPages
- Notes Client / generic development
- JavaScript development
- Admin scripts
- Connections Customizer

We've also made a complete overhaul of the UI / UX:
- We've modernised the look and feel to Bootstrap 3
- User interface has also included some styling on the buttons taken from non-ICS development frameworks - primary, friendly and danger button styles
- In terms of user experience, we've changed from views to multi-faceted search based on key criteria - language, author and generic free text search. The aim is that this allows quick filtering down to a handful of results
- The login area has also been updated including the ability to register and reset password from the login screen
- The "Create Snippet" button has been hidden behind the login area
- Some outdated links have been updated
- Social sharing has been added (thanks Serdar for adding this)

Hopefully you'll agree this is more modern, more fit for the future and hopefully it will give developers ideas to give users a better user experience.

Request for CollaborationToday Curators

Paul Withers | 8:06:22 AM Thursday, January 24, 2019 | Full Story and Comments
CollaborationToday has become a key place to stay updated on all ICS platforms. In an exciting year for Domino, Connections and Portal we would like to expand the small team currently curating blog posts. We want to make sure posts are specifically relevant to our community and provide best value to those using the site. The effort required is minimal, reviewing and creating an entry with brief details and publishing. So if you're interested in helping out, please contact Oliver Busse or one of the other board members via social media or via the OpenNTF Slack channels.

Part of the improvements we made last year to minimise the effort required was auto-tweeting of content posted there to the CollaborationToday Twitter Stream. Those stopped running for a while, but have been re-enabled now. These pick up RSS feeds for particular areas of focus, so if you want to stay updated on specific areas via a feed reader, you can use URLs in the format of https://collaborationtoday.info/ct.nsf/feed.xsp?filter=appdevweb. The filter can be found by clicking on one of the categories in the right-hand menu of CollaborationToday.

If there are other HCL products that it would be useful for CollaborationToday to cover blog posts for, and you have a specific expertise in that area, we are open to adding categories for those too.

Watch a short intro to how to moderate articles on CollaborationToday.info here.

New Channels on OpenNTF Slack

Paul Withers | 6:22:22 AM Thursday, January 17, 2019 | Full Story and Comments
Following this week's announcement about the end of Watson Workspace, the various members of the community asked for channels relating to IBM Collaboration Solutions / Collaborative Workflow Platforms technologies to be set up in OpenNTF Slack community. So following consultation we have channels for Connections on premises, Connections Cloud, Sametime, Domino admin, Domino dev and IBM Domino Mobile Apps. If you want to join, you can at https://slackin.openntf.org/ and then access the channels at https://openntf.slack.com.

For XPages there was already a separate community at https://xpages.slack.com/ and there are no plans to bring that thriving area into OpenNTF channels at this time. If you're working on XPages and are not yet in that chat, you can join by going to https://xpages-slack.herokuapp.com/.

If you're a new joiner and new to Slack, click on the word "Channels" and you get a list of channels you can choose from. Once you click on one, you're only browsing the content and will not yet get joined to it. To join the channel, click the link at the bottom of the chat. Clicking on the star under the bold channel name at the top of a chat adds it to your Starred channels. We would recommend everyone to click on their name, go to "Profile & Account" and set a display name. That ensures an understandable name appears when you ask questions.

It's great to see more IBM Champions already joining OpenNTF's slack and I'm sure this will help the breadth of conversation appearing in the general and random channels, as well as improving the excellent feedback members can get.

Become a NERD using Domino V10

Christian Guedemann | 3:01:45 PM Wednesday, October 10, 2018 | Full Story and Comments
Nerds are very cool these days - but, you may ask, what has a NERD to do with Domino V10? Should they not all bleed yellow? Maybe, but behind the acronym NERD is a very compelling technology decision! But first, let us jump into the acronym:

N = Node.js - A nonblocking JavaScript engine based on Chrome's V8 JavaScript engine
E = Express - One of the most popular Node libraries, which turns Node into a REST API / HTML server
R = React (or, as I prefer, R = Really Cool User Interface) - React is a client JavaScript framework to build a brilliant user interface
D = Domino - Yes, Domino: something must be a store for all the data and even more (i.e. business logic)

Node.js, JavaScript... some of you may say "finally!", others not. Either way, Node.js is one of the most sucessful platforms and has with NPM the largest Open Source ecosystem. And, you may ask, why? Let me quote one of the German Node.js influencers, Golo Roden (@goloroden): solutions in JavaScript have to be simple and clean or they will be replaced by simple and clean solutions. Express is one of the best examples. Two lines of code and you have configured a server for static HTML files. Two more lines and a REST API is running.

Another popular framework is Passport. Passport provides integration with a huge variety of different identity and authentication providers. You want to use Facebook? With Passport, no problem: done with just a few lines of code.

Node.js is the glue between your front end and your clever backend services. A lot of integration problems are already solved by the power of this huge Open Source ecosystem. It makes complete sense to leverage this power for Domino application. In addition, with NERD, we have the potential to attract a huge community of JavaScript developers. We are talking about 4.5 million developers according to LinkedIn. And it seems that in the year 2018 JavaScript will be the most popular language!

Dear NERDs let's get ready for domino-db, the integration point for Node.js. Let's explore a whole new universe of possibilities!

What can you do until then:
1. Download an IDE that is good for developing Node.js application. As a Swiss guy, I recommend Visual Studio Code: https://code.visualstudio.com/
2. Do some baby steps to explore Express: https://expressjs.com/
3. Stay tuned for my next blog post

Have fun,

More News