In the blog post "Yes We Kanban" by Katie Wilkes, she talked about using a Kanban method to handle the day-to-day ticket management process. In order to facilitate this approach, we needed to create a custom online application that supported the requirements or “rules” we set for this process.
It was Katie’s job to dream up the idea. It was my job to bring the idea to life. Below I will unpack the build steps taken to create The C2 Group Kanban tool.
Build Tools
The landscape of front-end development has shifted over the years. Even though standards have limited browser rendering discrepancies, developing has never been more complex. This is mostly due to websites being consumed by all kinds of new devices with new capabilities. In an effort to make our code less complex and more maintainable, we've attempted to shift some of the responsibility to the computer. In front-end development, we've added a build step to our process.
The Kanban UI uses a build process powered by NPM and Ruby to keep the code clean and organized. These build steps add complexity to the project but simplicity to the code. Let's take a look at some of the tools that are used.
Gulp
Similar to Grunt, Broccoli, and other JavaScript task runners, Gulp makes it easy to perform automated tasks on your code. What sets Gulp apart is its ability to run multiple tasks on the same set of files. In the example below, Gulp is able to concatenate two files then "uglify" them in one streamlined process.
<p> CODE: https://gist.github.com/thec2group-blog/f298577a5192aecd35f76abb6990b084.js</p>
We use Gulp on the Kanban UI to automatically add vendor prefixes to our CSS, convert 'PX' units in font declarations to 'REM' units in our CSS, and to lint our CSS and JavaScript. We love Gulp for its intuitive API. Files go in, get "piped" through the Gulp plugins that make edits to the files, then the files are piped to a new destination.
PostCSS
PostCSS is what makes our automatic vendor prefixes and unit conversions possible. PostCSS is a CSS parser that gives you a JavaScript API to read and write to these files. There are many plugins that have been built on PostCSS, but for the Kanban UI we are only using Autoprefixer and Pxtorem.
Autoprefixer
Adding specific vendor prefixes in CSS is time consuming and difficult to maintain. Autoprefixer adds only the vendor prefixes that are necessary by using data from caniuse.com.
Unprefixed CSS:
<p> CODE: https://gist.github.com/thec2group-blog/94db424815e2c3e22258782982737c9a.js</p>
The same CSS converted with Autoprefixer to support various browsers:
<p> CODE: https://gist.github.com/thec2group-blog/0bfed3490941e0eb6c36203719412a08.js</p>
Pxtorem
REM units allow that value to be manipulated by the browsers root font size. By changing the font size preference in the browser settings, any REM unit will be calculated off that font size choice. However, REM units are less readable in the code because the value usually requires a decimal. For simplicity, it is easier to write the code using PX units, then converting the code to REM with Pxtorem.
This is an example of CSS that has been converted by Pxtorem. The original PX declaration are left in as a fallback for browsers that do not support REM:
<p> CODE: https://gist.github.com/thec2group-blog/59ec2ee50f6edde38c018fe01b23b216.js</p>
This CSS build step has allowed our source files to not get bloated by code that only browsers need to see (not humans).
Sass
A CSS pre-processor that offers imports, mixins, nesting and variables. Sass is a must have for any of our projects.
Sass runs on Ruby which can be a bummer. First, Ruby is an additional thing to install. Secondly, we keep this separate from our Gulp file which only runs our NodeJS code. In the future, we may involve LibSass in an attempt to consolidate our build steps.
Browserify
When you are building a large JavaScript web app you'll need to figure out how to not over pollute the global namespace, how to load dependencies in the correct order, and how to prevent the files from becoming massive and difficult to manage. Browserify handles all of this for you with the CommonJS syntax. CommonJS gives you "require" and "export" ability to any module.
Here is a quick example of what a Browserify JavaScript file might look like:
<p> CODE: https://gist.github.com/thec2group-blog/f302800b5f57abd34faabcf17c2066f2.js</p>
This file has one dependency, jQuery, which is "required" at the top. The variable "cache" is not added to the global namespace but is contained to the scope of this file and is persistent no matter how many times this file is "required". When this file is "required" in another file, the value that is saved asmodule.exports will be imported into that file through the required statement. In this case, a function.
The feature that we enjoy the most about Browserify is sanity (that's not really a feature, I'm being facetious). The style of importing and exporting encourages you to write many small reusable modules that can be shared throughout the project. Smaller also means more readable and maintainable, which provides sanity.
Build Complete
HTML, CSS and JavaScript aren't languages that need to be compiled. But, that doesn't mean you can't benefit from compilation. Before I owned a smart phone, carrying a computer in my pocket would have been overkill, unnecessary, and the cost would outweigh the benefits. Now I can't live without all the capabilities my phone provides. My experience with the build steps discussed above have been very similar. I'm not sure I could code without them.
As you can see, a lot of thought and time has went into creating this Kanban tool. It vastly improved The C2 Group workflow in a matter of months. If you'd like to learn more about the Kanban tool and how it can be adapted to your process, contact us below.