Gulp has been part of our front-end build process as it is useful in processing and packaging front-end design and script assets to optimize them for deployment.

Jobs to be done
As a small digital products company we are discerning about our work toolkit. When it comes to adopting a new tool, the question, we always ask ourselves; what job are we hiring this tool to do and will it help us scale?

Finding a scalable technical model for our projects is key to providing value to our clients in a timely and repeatable manner, and especially as there is a proliferation of tools today, it therefore makes sense to be discerning.

Gulp's job in our build process is to automate and transform files^*; streaming, compiling, processing, merging, removing unused components, compressing, testing, and so on; these are otherwise time-consuming tasks if done manually in any development workflow.

Recently as javascript drives more of our software, we are adopting the concept of js module systems and dependecies in our client-side applications, as opposed to the concept of files ^{see * 👆}.

The job we hired Gulp to do was changing and we started looking for an alternative which is better suited for the js module system and code-on-demand approach rather than just one single project optimized package.

Webpack offers packaging and processing assets just like Gulp, but it also supports javascript's module systems in bundling such that it can split code bundles to be loaded on demand, depending on an entry point's dependencies.

The first step in hiring Webpack would be to make sure it replaces Gulp seamlessly, so let's take stock of what Gulp does and replicate it using Webpack.

Taking stock
Our gulp file on github for a typical small project has the following tasks:

	Gulp tasks	Job description
1	js	1. stream and concatenate source javacript files 2. transpile and minify ES6 code for use in browsers 3. generate file hash and rename file for cache bursting 4. copy the renamed file to the js build directory 5. update the project manifest with a reference to the new file
2	sass	1. stream and compile css and scss style sheets to css 2. purify the CSS file by removing ununsed components i.e components not referenced in the view or the js file 3. generate file hash and rename file for cache bursting 4. copy the renamed file to the css build directory 5. update the project manifest with a reference to the new file
3	images	1. move images to the images build directory
4	html	1. stream the manifest file and all the view html files 2. replace the assets (css and js) reference in the view files with the corresponding hashed file name from the manifest file. 3. move the html files to the build directory

You can clone the repo and run ``yarn && gulp`` in the ``gulp-build`` directory to use the gulp build. Gulp will package the js and css files according to the task description in the table above and we'll have one single concatenated and compressed js and css file respectively.

Packaging your js and css files into one compressed file helps to optimize your web application by reducing the number and size of http requests that the app makes.

However the problem with this build is that regardless of the code and style requirement of a view in this project, some of the views will be straddled with a css and js package that contains code they don't require.This is one benefit of moving to a module builder that supports splitting like Webpack.

In part two of this post, we'll replace the Gulp build with a Webpack build in order to achieve the same result before working on splitting the bundles and loading them depending on a view's requirement.