Modern Domino: CSJS Workflow

The Problem

I’ve recently been doing a lot of client side javascript development and was getting frustrated with the process of adding libraries like jQuery, Select2, etc to everything. This frustration was caused by having to go download the latest version or copy/paste from a previous project into my current project. While downloading and including the files works, it’s time consuming. Not having a formal process for deployment of the code was also a hassle and usually a very manual process (minifying, linting and ensuring you copy everything). In order to be more productive I decided I need to automate some of or as much of this process as possible.

The Tools

So researching this problem I ended up being very confused. There are several pieces to this puzzle and I had seen reference to all of the tools listed below but nothing told me, a total newbie to this sort of thing, what they were for or how they fit into your day to day processes. To add to my confusion all these depend on node.js to function. My very basic understanding of node.js was that it provided a web server for development purposes and configuration was done by writing plain old javascript. But my conundrum was that I’m using Domino as my server and so what purpose does node play in this scenario? The short answer, the only role it plays is driving the tools we’re going to use.

But I came across a video by Shai Reznik about using Yeoman for creating an Angular.js application. Pretty close to what I’ve been doing except I’ve been developing with Backbone.js. Still, the concept is pretty much the same. In that video, Shai describes using Yeoman in a way that totally put together all the little missing pieces which was causing my confusion on the topic:

Yeoman helps you kickstart new projects, prescribing best practices and tools to help you stay productive.

To do so, we provide a generator ecosystem. A generator is basically a plugin that can be run with the `yo` command to scaffold complete projects or useful parts.

Other than the Yeoman Generators, Yeoman uses a couple of different tools which are pretty standard in the Javascript development world. These tools are:

  • Grunt – A javascript task runner
  • Bower – A client side package manager


This is a cool tool for automating tasks. Some examples of what you can automate include:

  • linting your code
  • concatenating all your css and js files into single files
  • minifying your html, css and javascript
  • running unit tests
  • copying the resulting build to production
  • SCM operations
  • Many more!!

How I’m using Grunt is really a very simplified process from what a lot of the Yeoman generators are using. Since I’m not using node.js for my server I was able to cut out quite a bit of complexity. Since I was working on a project that was already developed for the most part use of a Yeoman Generator really wasn’t needed as I would have to create my own to match the directory structure I had implemented. So this left the process of linting, minifying and copying files. Hopefully I’ll be adding automated unit testing in the coming weeks, I have no idea what tool I will use for this yet.

I’m storing all of the javascript and html files for my backbone site inside a directory structure within the WebContent folder of an NSF to get all the authentication and security goodness from domino. For this NSF I’ve setup an On Disk Project and I do all of my editing there. When I’m ready to test I sync with the NSF and voila I’ve got a backbone site running inside an NSF. Once I’m ready to put into production I use a few grunt tasks to ease the workload a bit. I run everything through jsLint, concat all the css and js files into single files, minify those files and copy them to the root of the WebContent folder. This is all done from a terminal window by just running “grunt deploy”. The deploy task takes about 45 seconds to run. This knocked about 2 hours off my manual build time.


Bower is a tool for ensuring that a team of developers have the same versions of all of a site’s dependencies, like jQuery, Backbone, Underscore, Select2, etc. This is all defined via a JSON file and not stored in the project itself. The only version of all these files stored in the project is the minified version of the concatenated files. So all your jQuery plugins and framework files all get concatenated into a single file (via grunt concat) that is then minified (grunt uglify) and that is stored in the project. I’m still learning the use of Bower, but so far I’ve been happy using it and haven’t run into any issues really.

In Conclusion

Using these tools has been a real eye-opener to what is possible when you start employing modern techniques to your domino development. I would say this process more closely matches a classic domino web application instead of an XPages application. But then again, once you start dipping your toe into this realm the more you start moving away from XPages and classic domino development. The results can be rapid and very performant comparatively speaking. While you do have to setup a custom development environment I assure you it’s worth the time and effort. Not to mention you’re preparing yourself for the future of web development.


  1. After I read your blogpost I start exploring Bower, heard a lot about it.
    It is very easy, but powerful. I managed to get it working on a ODP of NSF, so I can with command line include all my needed frameworks

  2. That’s great Frank, since I’ve found and now understand what these tools are for I really like the process of using them. They make life so much easier.

  3. […] I read the blog post by Keith Strickland about CSJS Workflow, where he mentioned Bower. I heard the name  frequently when I was exploring the modern web […]

Leave a Reply

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.