Frontend Builds 1: Getting started

Frontend Builds 1: Getting started

See all articles from the series


As described during the introduction, here the link to the sample frontend application. x-note is a small note-taking application which I’ll use for this series of posts. I’ve build the app using AngularJS and angular-material.

Go and clone the repo now, all dependencies are managed using bower and npm. In order to install all development- and runtime-dependencies execute the following commands within the project folder

$ npm install
$ bower install

I highly recommend using a small http server for development time. During one of the upcoming posts in this series I’ll explain how to integrate such a http-server within our gulpfile. But for now it’s fine to use a second terminal instance and start the http server manually. I’m using the npm module live-server which is able to reload websites in chrome once any source file has been changed.

You can install live-server using npm

npm install live-server --g  

At this point you can just use the default build task by executing gulp build from within the project folder. This task will build the entire web application to the dist sub-folder. Use the second terminal instance to start the live-server by invoking the live-server dist command. Chrome will fire up and show x-note. Make yourself comfortable with our small demo app.

When browsing the project directory, you’ll find the gulpfile, which I’ll use as starting point for this series.

During the series well make continuous improvements to the gulpfile to make it more flexible, readable and maintainable. A few things are already part of the base gulpfile

  • internal tasks are marked with the private: prefix
  • well-known tasks such as default and watch are available
  • run-sequence is used to keep things in correct order and make gulpfile more readable

AngularJS related build steps

For AngularJS applications a few tasks are explicitly required. First let’s talk about templates, templates can either be consumed by requesting them on demand. Every time a template is required your SPA will issue a HTTP call and load the template from the configured URL. This is okay during development time, but for production environments you can utilise Angular’s template cache ($templateCache) for minimising http calls. You can use gulp-angular-templatecache in order to configure Angular’s template cache easily from within the gulpfile. See the following gulp task which takes care about filling the $templateCache.

gulp.task('private:app:templates', function(){  
    return gulp.src('src/app/**/*.html')
            module: "xnote",
            filename: 'templates.js'

As you can see the templates.js file will contain all .html files from the src/app folder and will be placed within a .temp folder (relative to the project root folder). The generated file will move into our app.js which we'll examine now.

Second important thing for Angular code is to be minfication-safe. In order to make your Angular Apps minification-safe, you can either invest more time when developing each and every Angular building block or you can use gulp-ng-annotate to automate this step. Compared to the template-cache related task, gulp-ng-annotate is much easier to use, it’s just a middleware that can be plugged into the gulp chain. See the following snippet which takes care about all angular-related build tasks.

gulp.task('private:app:js', function(){  
    return gulp.src([

gulp-ng-annotate can of course be configured depending on your requirements, but for our sample app default settings will work fine.

These are the only angular-related special tasks you need to remember when building frontend apps. But checkout the entire file there are several other cool things to explore like gulp-inject or concatinating all those vendor-scripts and -styles.

Many of you may ask why I'm not using things like bower-mainfiles or other modules to query all those third party files that need to be concatinated. The answer is short: simplicity. Adding app related html, js or css files is the most common scenario during my every day work. Adding vendor related stuff is not that common and may have a huge impact on your entire app.

That's why I mostly decide to keep those tasks manually. The downside of modules like bower-mainfiles is that there are too many exceptions in the huge npm eco-system. Many modules are exposing minified scripts wherease others are exposing regular scripts, once you realise that, it's again your task to take care about all those exceptions. That's why I keep those steps more manually and specify all minified 3rd party files in the order I like (or in the order my app needs them).

What's next?

Within the upcoming article we'll split the gulpfile and automate both things, loading and documenting all tasks. Which will make the entire build more readable and maintainable.


comments powered by Disqus