Toggle Menu

Insights / Digital Service Delivery / Building Scalable and Beautiful AngularJS Apps (Part 2): Web App Packaging and Publishing Best Practices

March 27, 2017

Building Scalable and Beautiful AngularJS Apps (Part 2): Web App Packaging and Publishing Best Practices

4 mins read

Doguhan Uluca was a speaker at ng-conf 2017, where he talked about Do More with Less JavaScript. Check out the full talk. For more about conference-related materials visit TheJavaScriptPromise.com

This post is the second in a multi-part series on building scalable and beautiful Angular apps.

 

First things first: Running code is far more valuable than any blog post. So, launch the demo site here, check out the source code on GitHub and pull the Docker image without delay: docker pull duluca/angular1.5-starter.

Practice Good Code Hygiene with Browserify & Gulp

You expose your front-end code over port 80 to the open web. If this doesn’t scare you, it should. It is not difficult to mistakenly expose private keys, passwords or unintended static assets like images or source code. For this we need to separate the source code from the that is published on the internet. Furthermore, we would like to minify and combine our code to a single file, which is the most efficient way of sending clients data over http. This is something that will eventually change with http 2, but we are far from wide support of the technology at this point. Let’s examine the gulp tasks that we need to achieve these goals.

Gulp Task: Build

Let’s start with combining your dependencies into a single file. If you use npm as your only dependency repository; I recommend using Browserify to combine and minify your code. Browserify will allow you to require properly formed npm modules in the style of Node.js require statements but in your front-end application. This style of coding enables code sharing across modules and projects with eases, but also encourages developers to build unit testable, decoupled components that follow the single responsibility principal. I detail the benefits of Browserify here around the idea of using JavaScript full-stack, but the benefits still apply only when using it with Angular.

All Angular and JavaScript code goes under the parent app folder. Your angular app is bootstrapped in app/component/app/app.js file and all top-level dependencies are required from here. We configure app.js with Browserify as the entry-point with the build task located in the gulpfile.js file.

Gulp Task: Templates

As we discussed earlier, sending one large file down to the client is the most efficient way of sending your code assets down to the client in today’s internet. So, we need a way to bundle our various html templates into one file. For this, I use gulp-ng-templates, which builds all of your Angular templates in just one js file using Angular’s $templateCache provider. The output of this task is the template.js file that we then inject as a dependency in app.js.

Gulp Task: Lint

Linting is a form of static code analysis, where we can configure and enforce coding standards and styles, but also discover unused or misnamed variables during build-time. In Angular Starter, I use the ubiquitous JSHint tool. The .jshintrc file contains a default set of coding standards and styles your team can follow. I’ve modified this configuration to allow for the JavaScript Standard style coding, which I find to result in easier to read, maintain and write JavaScript code.

If you’re using Visual Studio Code, the IDE will enforce your JSHint rules without further configuration.

Gulp Task: Static

To ensure code hygiene index.html should rarely ever be updated, because we only need to reference a single app.js file in html, since all js and html files are combined into a single file from in the build step. A notable exception are css resources, because you may want to use CDN links for these resources. Furthermore, I find it unreliable to compile, combine or minify 3rd party css resources.

All of your static assets should go under the static folder, which this gulp task will copy over to the public folder.

Bringing It Together in Public

We leverage Gulp.js to streamline our build tasks. The pre-built Gulp tasks, we reviewed above minify, combine JS, HTML and publish other static assets to a public folder, which is created from scratch ever time. Don’t check this folder into your code repository and don’t make code changes in this folder. In fact, I have configured Visual Studio code to hide this folder from default view. See .vscode/settings.json file to change the settings to your liking.

Creating the public folder from scratch every time ensures that you maintain a repeatable development pipeline and enforce a clean-room development environment to avoid mistakes and accidental exposure of assets.

Start Today

As German poet Goethe puts it, “what is not started today is never finished tomorrow.” Here’s the code on GitHub. Fork it, create issues with it, otherwise just clone it and use it. Start today.

If you have any questions, ask them on Twitter @duluca.

You Might Also Like

Resources

Simplifying Tech Complexities and Cultivating Tech Talent with Dustin Gaspard

Technical Program Manager, Dustin Gaspard, join host Javier Guerra, of The TechHuman Experience to discuss the transformative...

Resources

How Federal Agencies Can Deliver Better Digital Experiences Using UX and Human-Centered Design

Excella UX/UI Xpert, Thelma Van, join host John Gilroy of Federal Tech Podcast to discuss...