Problem

Traditionally, the Jenkins GUI is constructed on the server side from Jelly files (Stapler etc). Client-side JavaScript has not played a big part in the Jenkins GUI.

If the Jenkins GUI is to be modernized and improved (from a user experience perspective), client-side JavaScript needs to be able to play a bigger part. If that's so, we need to modernize/improve the development patterns around how JavaScript is currently used in Jenkins. See here for more discussion on the problem.

Ongoing Efforts

The following are links to some ongoing efforts in the space of JavaScript Modularization:

• Jenkins JS Modules. An NPM package for lightweight loading of JavaScript "bundles" in the browser.** Jenkins JS Modules slide deck.** Jenkins JS Modules FAQ.
• Jenkins JS Builder. A build time NPM package for assembling JavaScript "bundles". A Gulp based wrapper around a number of well known JavaScript build tools (Browserify, LESS and others), making them easier to use.
• Jenkins JS Test. A build time NPM package for helping with testing. A wrapper for Jasmine and jsdom, making them easier to use together.
• Jenkins JS Framework Libs. Preassembled "Framework" library JavaScript "bundles" e.g. jQuery, Twitter Bootstrap, MomentJS and others, making them easier to use with other JavaScript "bundles" .

Participants

• Tom Fennelly, Gus Reiber, Keith Zantow

Related Tickets

• Update HTMLUnit in Jenkins Core - JENKINS-31161