SAMPLE

This is only a book sample! We have included one chapter of the book, Automation, as an example of the content. If you enjoy reading this sample and would like to continue, please support us by purchasing our book.

",{"_155":156,"_43":44,"_47":48,"_45":46,"_70":71,"_157":158,"_176":153},"previewContent","

\n About the Authors\n
- \n Joe Fender\n
- \n Carwin Young\n
\n
\n Introduction\n
- \n Who This Book Is For\n
- \n An Overview of This Book\n
- \n Example Code\n
- \n Contacting the Authors\n
\n
\n SAMPLE\n
\n Automation\n
- \n Task Runners\n
- \n Grunt\n
- \n Gulp\n
- \n CodeKit\n
- \n Yeoman\n
- \n Other Tips\n
- \n Summary\n
\n

About the Authors

\n\n

Joe and Carwin started working together in 2013 at Lullabot, an interactive strategy, design and development company.

\n\n

At Lullabot, they work with decision makers, developers, and designers at all stages of a web project. They have guided the development of sites for clients such as Martha Stewart, The GRAMMYs, MTV UK, Sony Music, Lifetime Television, The George Lucas Educational Foundation, Leo Laporte’s TWiT network, and many others.

\n\n

Joe Fender

\n\n

\n $\"\"$

\n\n

Joe Fender lives in London, UK and splits his focus between front-end and back-end development. Specializing in PHP, AngularJS and Drupal, Joe was the lead architect at Studio Umi, the largest Drupal shop in Japan before joining Lullabot to work on awesome websites such as Drupalize.Me and MSNBC.

\n\n

In his spare time, Joe likes to collect shoes and work on side projects. But never at the same time.

\n\n

Carwin Young

\n\n

\n $\"\"$

\n\n

Carwin Young is an expert front-end developer living in Springfield, Missouri. He has over 8 years experience working on the front-end. He was the second front-end developer to work at Lullabot where he has played a key role on building websites for clients such as MSNBC, BravoTV and the GRAMMYs.

\n\n

Carwin loves to share his expertise. He has spoken on topics such as Rapid Drupal Development at DrupalCamp Chicago, is a co-organizer for the Springfield Drupal meet-up and is a regular contributor to the Front-end Rapport, an online magazine for front-end developers.

\n\n

Introduction

Front-end web development is evolving. Long gone are the days of writing static HTML files with self-contained CSS. As web developers in this modern world, we need to understand and utilize an endless number of frameworks, plugins, techniques and more. Knowing the right tools to use and when to use them is key to building successful solutions.

\n\n

Despite our best efforts, it can be difficult to keep up with the speed of advancing web development. We sure as hell can’t slow it down. And why would we want to? It’s so exciting to not know where technology is headed and what could be around the next corner. We should both prepare for change and embrace it. And that is exactly where front-end developers excel. We build what the consumer sees and because of that, we want to use the most cutting-edge technologies to create the biggest impact.

\n\n

This book came to be from the lessons we, the authors, have learnt through trial and error whilst working on front-end development projects ranging from enormous high-traffic sites such as MSNBC, The GRAMMYs and BravoTV to startups and experiments such as Drupalize.Me and BracketCloud. We want to share with you the tools that we use and the standards that we follow. Our ultimate goal is for you to walk away understanding the core concepts of front-end development so you can confidently go and work on your own projects.

\n\n

This book is somewhat opinionated based on our experience, so you’ll find some of the content heavily geared towards a particular way of doing things. Of course, there are many ways of accomplishing the same task in the world of front-end development; that’s what makes it so accessible and yet so complicated. Learning one way of doing something can make learning the alternatives a much more palatable task, so we encourage you to look into any and all of the technologies presented herein and even go on to see if something else might better fit your needs.

\n\n

Who This Book Is For

The content in this book is aimed at those who are new to front-end web development. Regardless of whether you are a beginner or expert developer, the concepts outlined in this book are essential to embracing the rapidly evolving web. We won’t be covering the general basics of web development so you will most likely want to get up to speed on the fundamentals of web programming such as HTML, CSS and JavaScript. We will also be utilizing the command line, so some basic knowledge of how to use that on your operating system is recommended.

\n\n

If you hear yourself asking any of the following questions, this book will likely be very useful for you!

\n\n

“What actually is front-end development?”
“How can I be a more efficient web developer?”
“What is Grunt/AngularJS/SASS/<insert popular tool name here>?”
“How do I fit all of these front-end tools together into a project?”
“How can I build a front-end application that can scale?”

An Overview of This Book

Every web project that you work on is different and there is no ‘one size fits all’ set of tools. However, throughout the chapters in this book, we’ll introduce you to some of the most popular, useful and powerful tools used in front-end web development so that when you’re done reading you will be able to apply the concepts and techniques to whatever you are working on.

\n\n

1. Getting Started

The aim of the first chapter of this book is to help get you acclimated with front-end development in general. You’ll learn what’s expected from a front-end developer and get a short overview of the types of projects a front-end developer might be tasked with. We’ll even take you through setting up your computer for local development.

\n\n

2. Frameworks

This chapter jumps right into some of the more popular JavaScript frameworks and template languages in use today. We’ll cover the details of what exactly a ‘framework’ is and talk about the MVC pattern before getting into the details of installation and practical usage of 3 popular frameworks: AngularJS, Backbone.js and Ember.js.

\n\n

3. Styling

There’s a lot more to styling than just throwing CSS at your markup; that just leads to a big mess of unreadable spaghetti code sprinkled with !important parmesan. Here we’ll cover CSS preprocessors like Sass, organizational methods for your styles, and the kind of impact your CSS may have on a project’s performance.

\n\n

4. Dependency Management

Getting your whole team on the same page code-wise can be challenging. Heck, even making sure you’re using the same version of that awesome Ruby gem after an update can be a pain. This chapter on dependency management covers a number of really handy front-end package managers like npm, Bower, and Bundler. You’ll learn what a package manager is and how to use it effectively to keep your project on track.

\n\n

5. Automation

Do you like doing the same repetitive tasks over and over? No? Neither do we.

\n\n

The automation chapter is about just that, automation. We’ll go over how you can remove the tedium from front-end development and just get to work. In this chapter you’ll learn how to perform tasks like checking your JavaScript or CSS for errors whenever you save a file, minify your code to shave off some file size, and even how to automatically refresh your browser whenever something changes. Once you get started, you’ll never look back.

\n\n

Example Code

\n\n

This book contains many code snippets for demonstration purposes. Code may appear differently depending on the device you are using to read this book. Here is an example of a code snippet so you know what to expect:

\n\n

1 var gulp = require('gulp'),\n2   uglify = require('gulp-uglify');\n3 \n4 // This task uglifies our JS files.\n5 gulp.task('compress', function() {\n6   gulp.src('src/js/*.js')\n7     .pipe(uglify())\n8     .pipe(gulp.dest('dist'))\n9 });\n

\n\n

You will also notice that we reference code inline like this throughout the book.

\n\n

Contacting the Authors

If you have any feedback or questions, please feel free to contact us via the Front-End Fundamentals Google Group.

\n\n

You can either create a new topic via the web interface or you can send an email to the mailing list address:\nfront-end-fundamentals@googlegroups.com

\n\n

We will do our best to consider each and every new message received. Please understand that depending on the volume of requests, it may be difficult for us to respond immediately.

\n\n\n

SAMPLE

\n\n

Automation

\n\n

Time is a key factor in productivity. This chapter will explore some ways to automate your development workflow so you spend less time working and more time making awesome. You’ll be introduced to ‘task runners’ which help automate repetitive tasks. You’ll also discover ways to speed up the process of laying foundations for new projects, and you’ll pick up a few other tips to help you be a more efficient developer.

\n\n

Task Runners

\n\n

Task runners, also known as ‘task automation frameworks’, help you manage and execute sets of defined tasks. A task can be seen as any repetitive action you have to take when developing for the web. Tasks can include actions such as copying a file between directories or checking your JavaScript for syntax errors.

\n\n

With a task runner, you can build, preview and test your application much more easily than if you did all the work yourself. The strongest attribute of task runners is their flexibility, which means you can configure and run pre-defined tasks exactly how you want. Furthermore, if you can’t find a pre-defined task that meets your needs, you can even write your own.

\n\n

In this chapter you’ll learn a bit about the popular task runners Grunt, Gulp, CodeKit and Yeoman, including how to install them and how to configure them to meet your specific needs.

\n\n

Grunt

\n\n

\n $\"\"$

\n\n

Grunt is one of a front-end developer’s best friends and is the most popular and widely used task runner. It is a framework based on JavaScript and has a thriving ecosystem. In addition, there are a huge number of plugins available for Grunt. If you’re not sure where to start with task runners, then start here.

\n\n

Installing Grunt

\n\n

Let’s work through the installation together. We’ll install Grunt using npm from the command line. (If you haven’t done so already, please read the Dependency Management chapter first to learn more about how to set up and use npm.)

\n\n

The first tool we’re going to install is Grunt’s command line interface, grunt-cli. It’s worth noting that this does not actually install Grunt itself. It only provides us global access to the grunt keyword from the command line which is then used to load and run the version of Grunt that has been installed locally within the project. It is important to remember to install grunt-cli globally but grunt locally. For more information on global vs local installation, check out this article over at the official NodeJS blog.

\n\n

We’ll head over to our command line and run:

\n\n

1 npm install -g grunt-cli\n

\n\n

To verify that Grunt CLI was installed successfully and that we can access the grunt command we’ll run the following:

\n\n

1 grunt --version\n

\n\n

Now let’s install Grunt. We’ll need to navigate to our project’s root directory first:

\n\n

1 npm install grunt --save-dev\n

\n\n

This will install Grunt locally and save a dependency reference to it from within the package.json file.

\n\n

The Gruntfile

\n\n

Now that we’ve installed Grunt, it’s time to introduce Gruntfile.js. Like package.json for npm, the Gruntfile belongs in the root directory of our project. It defines our project and task configurations and tells Grunt which plugins we want to use to run these tasks. We’re not going to define any tasks just yet but let’s create the bare bones of the Gruntfile so that we can add to it later. Create Gruntfile.js in the project’s root directory and add the following:

\n\n

1 module.exports = function(grunt) {\n2   // Project configuration.\n3   grunt.initConfig();\n4 \n5   // Default tasks.\n6   grunt.registerTask('default', []);\n7 };\n

\n\n

You’ll notice that this file, as the file name suggests, is a JavaScript file. All we’ve done here is called initConfig which initializes our Grunt configuration. This is where we will define our tasks later. We’ve also called registerTask to initialize a set of tasks labelled default. There are no actual tasks here yet but Grunt requires us to define this for it to run. After saving Gruntfile.js we can try running grunt in the command line from the project root. We should get a shiny green message stating:

\n\n

1 Done, without errors.\n

\n\n

This means Grunt was able to run all of the tasks defined in default without failure.

\n\n

Yay! We’ve just run Grunt for the first time. The more you use Grunt, the more you’ll love it!

\n\n

Popular Plugins

\n\n

There are thousands of plugins available in the open source community for Grunt. But there are a few that have become staples for the modern front-end developer. Depending on the project, you may not need all of these, but it doesn’t hurt to know about them. Obviously, these are only a select few and may not include everyone’s favorites.

\n\n

Watch, LiveReload and Connect

\n\n

Quite possibly the most popular plugin is Watch. It allows you to run specified tasks whenever a watched file changes. So, for example, you could minimize your CSS files whenever one of them changes or run JavaScript tests whenever you save script changes. The Watch plugin only does the ‘watching’ part. You have to specify exactly which tasks are to be run when a file change is detected.

\n\n

To install Watch, we’ll run the following from the command line:

\n\n

1 npm install grunt-contrib-watch --save-dev\n

\n\n

Edit the Gruntfile.js so that the plugin gets loaded:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig();\n 4 \n 5   // Load our Grunt plugins.\n 6   grunt.loadNpmTasks('grunt-contrib-watch');\n 7 \n 8   // Default tasks.\n 9   grunt.registerTask('default', []);\n10 };\n

\n\n

All we have done here is use the loadNpmTasks callback to tell Grunt to load the Watch plugin.

\n\n

To demonstrate how to use Watch, let’s set up something cool using LiveReload and Connect. We’ll set up a local web server that will automatically refresh any browser viewing our web site when a file change occurs. This is great because it means we don’t have to refresh every time a change is made to one of the files. The official homepage for LiveReload describes the tool as “A happy land where browsers don’t need a refresh button”!.

\n\n

Usually, when setting up a local web server you have to configure software system-wide. You may have used tools such as MAMP or you may have configured a local LAMP stack yourself. But a good alternative is to use a more lightweight approach to testing web applications using a combination of Watch, Connect and LiveReload plugins.

\n\n

Connect is an HTTP web server framework built for NodeJS. It’s a lightweight static web server that provides plugins known as ‘middleware’. Connect comes with a bunch of middleware such as session support, a cookie parser and more.

\n\n

There is a Grunt plugin for Connect which allows us to start a Connect web server so let’s get that installed:

\n\n

1 npm install grunt-contrib-connect —save-dev\n

\n\n

We now need to tell Grunt when and how to use the plugin. Every plugin you install should have a README file available in its root directory (in this case, node_modules/grunt-contrib-connect/README.md) which will outline how to configure the task. Let’s edit our Gruntfile.js again to set up the connect task:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4 \t// Defines our Connect web server.\n 5     connect: {\n 6       server: {\n 7         options: {\n 8           port: 9000,\n 9           hostname: 'localhost',\n10           base: ['dist/']\n11         },\n12       },\n13     },\n14   });\n15 \n16   // Load our Grunt plugins.\n17   grunt.loadNpmTasks('grunt-contrib-watch');\n18   grunt.loadNpmTasks('grunt-contrib-connect');\n19 \n20   // Default tasks.\n21   grunt.registerTask('default', []);\n22 \n23   // Running `grunt server` runs our Connect server until terminated.\n24   grunt.registerTask('server', ['connect:server:keepalive']);\n25 };\n

\n\n

Here, we told Grunt to load the plugin using loadNpmTasks exactly as we did with Watch. Task configurations are added within the initConfig callback. We’ve defined a task called connect that has a sub-task called server containing the settings for the task. We’ve defined our Connect server to run on port 9000 at http://localhost:9000 and to serve the folder dist (short for distribution).

\n\n

As described in the code comment near the bottom, running grunt server from the command line will launch the Connect server until terminated (made possible through the keepalive parameter). You will then be able to access the web application by pointing your browser to http://localhost:9000. However, there is currently no dist folder so let’s move on to creating that and an example index.html:

\n\n

1 mkdir dist\n2 cd dist\n3 touch index.html\n

\n\n

Open up index.html to add some basic HTML such as the following:

\n\n

 1 <!doctype html>\n 2 <html>\n 3   <head>\n 4     <meta charset=“utf-8\">\n 5     <title>My App</title>\n 6   </head>\n 7   <body>\n 8     <p>Hello world! Welcome to my application.</p>\n 9   </body>\n10 </html>\n

\n\n

Now, if you go to the command line, run grunt server and then point your browser to http://localhost:9000 you should see the “Hello world” message.

\n\n

To finish, we need to configure the Watch task so that when any change occurs in index.html, a browser refresh is triggered. Let’s update our Gruntfile.js to look something like this:

\n\n

 1 // Project configuration.\n 2 grunt.initConfig({\n 3   // Defines our Connect web server.\n 4   connect: {\n 5     server: {\n 6       options: {\n 7         port: 9000,\n 8         hostname: 'localhost',\n 9         base: ['dist/'],\n10         livereload: true\n11       },\n12     },\n13   },\n14 \n15   // Watch our files for changes.\n16   watch: {\n17     options: {\n18       livereload: true\n19     },\n20     html: {\n21       files: ['dist/index.html'],\n22       tasks: []\n23     }\n24   },\n25 });\n26 \n27 // Load our Grunt plugins.\n28 grunt.loadNpmTasks('grunt-contrib-watch');\n29 grunt.loadNpmTasks('grunt-contrib-connect');\n30 \n31 // Default tasks.\n32 grunt.registerTask('default', ['watch']);\n33 \n34 // Running `grunt server` runs our Connect server until terminated.\n35 grunt.registerTask('server', ['connect:server:keepalive']);\n

\n\n

The first thing you may notice is we’ve added our watch task configuration. We’ve set up a sub-task called html that watches for changes to index.html. We haven’t actually told Watch to execute any specific tasks once a change is detected. However, we’ve enabled the livereload boolean both in the Connect and Watch options. This basically tells Connect and Watch to use LiveReload in tandem. Connect comes complete with the connect-livereload middleware Node package and, as of recently, Watch now comes with LiveReload server functionality included so all we need to do is set those two booleans. Lastly, we updated our default task so that the watch task is run.

\n\n

To test this, you’re going to need two terminal windows. In the first, run grunt server and in the second run grunt. You should see the following status messages respectively:

\n\n

1 Running \"connect:server:keepalive\" (connect) task\n2 Waiting forever...\n3 Started connect web server on http://localhost:9000\n

\n\n

And:

\n\n

1 Running \"watch\" task\n2 Waiting...\n

\n\n

Make sure your browser is looking at http://localhost:9000 and then make a change to the “Hello world” message in your index.html. Don’t forget to save the file! Once you save the file, switch back over to your browser and you’ll see that the page had refreshed (probably before you even made it back over) and reflects the change you made. Neat huh?

\n\n

The power of Watch really shines when you start to configure it for larger front-end applications. For many, it becomes the center of their automation workflow - the trigger to every task. It really is a great plug-in.

\n\n

Copy and Concat

\n\n

As programmers, we aim to develop our projects to be as modular as possible. This quickly leads to a lot of files and one of the biggest challenges is keeping on top of them all. Copy and Concat are a couple of the handiest file management plugins to know about.

\n\n

Copy

\n\n

Copy simply allows you to copy files and folders from Grunt. Copy has endless uses but for the purposes of demonstration let’s create an example scenario. Let’s say that we want to copy src/index.html to dist/index.html as part of our Grunt build process because the dist folder is the one that is to be served by our web server and src is where we actually edit our code. Obviously with a real application there would likely be more files to copy than just a single file but let’s roll with this anyway.

\n\n

Before getting started, don’t forget to install the plugin:

\n\n

1 npm install grunt-contrib-copy --save-dev\n

\n\n

This is how we might go about setting up our Gruntfile.js to reflect this scenario:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4     copy: {\n 5       html: {\n 6         files: [\n 7           {\n 8             src: ['src/index.html'],\n 9             dest: 'dist/index.html'\n10           }\n11         ]\n12       }\n13     },\n14   });\n15 \n16   // Load our Grunt plugins.\n17   grunt.loadNpmTasks('grunt-contrib-copy');\n18 \n19   // Default tasks.\n20   grunt.registerTask('default', ['copy:html']);\n21 };\n

\n\n

We’ve set up a sub-task within our copy task configuration called html which will copy index.html for us. This allows us to add the copy:html task to our default task list. Simply entering copy as the task name would have also worked as that would trigger Grunt to execute all of its sub-tasks, but it’s preferable to explicitly call the name of the sub-task you wish to execute to prevent any issues in the future when you expand on your configurations.

\n\n

To test, make sure that the src/index.html file exists and then simply run grunt from the command line. You should see the following success message:

\n\n

1 Running \"copy:html\" (copy) task\n2 Copied 1 files\n3 \n4 Done, without errors.\n

\n\n

To specify more advanced file paths, such as using wildcards and matching on file extensions, read the official documentation on Globbing Patterns within Grunt. Copy also has some useful options such as encoding to use a specific file encoding when copying or mode to specify copied file permissions.

\n\n

Concat

\n\n

Concat lets you concatenate files. Concatenation is the act of joining things together. When optimizing your applications for performance, looking at techniques to reduce the number of requests is extremely important. By concatenating files together, you are able to reduce the number of requests required by clients to get at your code.

\n\n

To install Concat, we’ll run the following from our project folder:

\n\n

1 npm install grunt-contrib-concat --save-dev\n

\n\n

Let’s say we want to concatenate all of the JavaScript files that we have within the folder src/js into a single file. This is how we would go about setting up our Gruntfile.js:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4   \t// Concatenate all JavaScript files.\n 5     concat: {\n 6       js: {\n 7         src: ['src/js/*.js'],\n 8         dest: 'dist/scripts.js'\n 9       },\n10     },\n11   });\n12 \n13   // Load our Grunt plugins.\n14   grunt.loadNpmTasks('grunt-contrib-concat');\n15 \n16   // Default tasks.\n17   grunt.registerTask('default', ['concat:js']);\n18 };\n

\n\n

You can test this by adding a bunch of JavaScript files in to the src/js folder and then running grunt. You may notice that Concat could possibly nullify the need for Copy as you can specify the destination of the concatenated file. However, if you wanted to run other tasks on the concatenated file before moving it to the dist folder, you may well still need Copy.

\n\n

One configuration option of Concat that you can use is banner. It allows you to set a string header that will be prepended to the beginning of the concatenated file. It is worth noting that the header string is processed using grunt.template.process.

\n\n

Here is an example of how to set up a banner in Gruntfile.js for a typical application:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4     pkg: grunt.file.readJSON('package.json'),\n 5 \n 6     // The banner is placed at the head of our concatenated JavaScript file.\n 7     banner: '/*! \\n* <%= pkg.title || pkg.name %> - v<%= pkg.version %>' +\n 8             '\\n* Copyright (c) <%= grunt.template.today(\"yyyy\") %> <%= pkg.autho\\\n 9 r %> ' +\n10             '\\n* <%= pkg.homepage ? pkg.homepage : \"\" %> ' +\n11             '\\n*/ \\n\\n',\n12 \n13     // Concatenate all JavaScript files.\n14     concat: {\n15       options: {\n16         banner: '<%= banner %>'\n17       },\n18       js: {\n19         src: ['src/js/*.js'],\n20         dest: 'dist/scripts.js'\n21       },\n22     },\n23   });\n24 \n25   // Load our Grunt plugins.\n26   grunt.loadNpmTasks('grunt-contrib-concat');\n27 \n28   // Default tasks.\n29   grunt.registerTask('default', ['concat:js']);\n30 };\n

\n\n

What this does is load in the package.json JSON file into a variable called pkg which is then used to fill out banner. Depending on how your package.json is set up, you should see something like this at the top of the outputted scripts.js file:

\n\n

1 /*!\n2 * myApp - v0.0.0\n3 * Copyright (c) 2014 Joe Fender\n4 * http://www.myapp.com\n5 */\n

\n\n

Linting with JSHint and CSSLint

\n\n

Linting is the process of analyzing code for potential errors. In traditional methods, you would see JavaScript errors in the console if something went wrong. However, by linting your code, you are able to get feedback on your coding quality directly within your Grunt build process. Most linters will give you more information about syntax errors than your traditional browser console. Linting your code is highly recommended as it can save a lot of time debugging syntax errors.

\n\n

JSHint

\n\n

For JavaScript, we use grunt-contrib-jshint. To install JSHint, we’ll run this from our project folder:

\n\n

1 npm install grunt-contrib-jshint --save-dev\n

\n\n

This Grunt plugin passes through all of the options you set in its configuration task directly to JSHint. That means you will want to be reading the official JSHint documentation for a list of supported options.

\n\n

Here is an example of how we go about setting up our own typical JSHint configuration in Gruntfile.js:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4     pkg: grunt.file.readJSON('package.json'),\n 5 \n 6     // Configures JavaScript linting. See http://www.jshint.com/docs/options/\n 7     // for more on the available options.\n 8     jshint: {\n 9       js: {\n10         files: {\n11           src: ['src/js/*.js']\n12         },\n13         options: {\n14           curly: true,\n15           immed: true,\n16           newcap: true,\n17           noarg: true,\n18           sub: true,\n19           boss: true,\n20           eqnull: true,\n21           strict: false,\n22           globalstrict: true,\n23           globals: {\n24             angular: false\n25           }\n26         }\n27       }\n28     }\n29   });\n30 \n31   // Load our Grunt plugins.\n32   grunt.loadNpmTasks('grunt-contrib-jshint');\n33 \n34   // Default tasks.\n35   grunt.registerTask('default', ['jshint']);\n36 };\n

\n\n

We’ve told JSHint to check all of the JavaScript files in the src/js folder as part of our default task list. To test this, create an example JavaScript file that has a deliberate syntax error. Such as:

\n\n

1 var example = {\n2   bar: 'bar',\n3   foo: 'foo'\n4 }\n

\n\n

Run grunt and you will see the following:

\n\n

 1 Running \"jshint:js\" (jshint) task\n 2 \n 3    src/js/example.js\n 4       4 |}\n 5           ^ Missing semicolon.\n 6 \n 7 >> 1 error in 1 file\n 8 Warning: Task \"jshint:files\" failed. Use --force to continue.\n 9 \n10 Aborted due to warnings.\n

\n\n

JSHint found the missing semicolon and gave us a very clear indication of where the syntax error was. Because there was an error, it aborted the Grunt build process.

\n\n

If you have a build process that takes several seconds to complete, bring your linter task as far towards the front of the list as you can so that you’ll get snappier feedback about possible syntax errors. That way, you’re not wasting Grunt’s or your own time going through a bunch of tasks that you’ll just have to go through again once you fix the syntax error.

\n\n

CSSLint

\n\n

For CSS, grunt-contrib-csslint is recommended. As with JSHint, view the CSSLint documentation for a full list of configuration options. To install CSSLint we’ll run this command:

\n\n

1 npm install grunt-contrib-csslint --save-dev\n

\n\n

Here is an example Gruntfile.js to get CSSLint working with default settings:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4     // Configures CSS linting. See https://github.com/CSSLint/csslint\n 5     // for more on the available options.\n 6     csslint: {\n 7       css: {\n 8         src: ['src/css/*.css']\n 9       }\n10     }\n11   });\n12 \n13   // Load our Grunt plugins.\n14   grunt.loadNpmTasks('grunt-contrib-csslint');\n15 \n16   // Default tasks.\n17   grunt.registerTask('default', ['csslint']);\n18 };\n

\n\n

To test CSSLint create a broken css file in src/css - perhaps something like this:

\n\n

1 .boo {\n2   height: 100px;\n3   widths: 100px;\n4 }\n

\n\n

After running grunt you should be greeted with this lovely warning message:

\n\n

1 Running \"csslint:css\" (csslint) task\n2 Linting src/css/example.css...ERROR\n3 [L3:C3]\n4 WARNING: Unknown property 'widths'. Properties should be known (listed in CSS3\n5 specification) or be a vendor-prefixed property. (known-properties)\n6 Browsers: All\n7 >> 1 file lint free.\n8 \n9 Done, without errors.\n

\n\n

It is worth noting that unlike JSLint, the Grunt build process will not fail when there is a code warning. This seems to be a design decision.

\n\n

Minification with UglifyJS and CSSMin

\n\n

Minification is the process of removing unnecessary characters from code (such as white space and comments) to reduce its file size. There are lots of plugins available that offer different types of minification but a couple of favorites are UglifyJS and CSSMin.

\n\n

UglifyJS

\n\n

UglifyJS is a JavaScript compressor and minifier. To install UglifyJS, we’ll run this command from our project root:

\n\n

1 npm install grunt-contrib-uglify --save-dev\n

\n\n

We can set up the uglify task in our Gruntfile.js with only a few lines:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4     // Minifies our JavaScript files.\n 5     uglify: {\n 6       js: {\n 7         files: {\n 8           'dist/scripts.min.js': ['src/js/*.js']\n 9         }\n10       }\n11     },\n12   });\n13 \n14   // Load our Grunt plugins.\n15   grunt.loadNpmTasks('grunt-contrib-uglify');\n16 \n17   // Default tasks.\n18   grunt.registerTask('default', ['uglify']);\n19 };\n

\n\n

In the above example we’ve configured our uglify task to look for all JavaScript files in src/js and compress them all into the outputted dist/scripts.min.js. By default, UglifyJS will not only remove white space and comments but will also try to simplify the code by grouping together code of similar functionality (such as variable declarations) and by deleting unused functions.

\n\n

Check out all of the task configuration options available in the plugin README, especially mangle. By setting this to true, UglifyJS reduces the names of local variables and functions to single letters. This can greatly minimize the amount of text used in the JavaScript file, thus reducing the outputted file size.

\n\n

CSSMin

\n\n

CSSMin is probably the most popular CSS minifier Grunt plugin. It uses clean-css to perform the actual compression.

\n\n

To install CSSMin, we’ll run this command from our project root:

\n\n

1 npm install grunt-contrib-cssmin --save-dev\n

\n\n

Here is an example cssmin task for our Gruntfile.js that will take all of the CSS files in src/css and minify them into a single file, dist/styles.min.css:

\n\n

 1 module.exports = function(grunt) {\n 2   // Project configuration.\n 3   grunt.initConfig({\n 4     // Minifies our CSS files.\n 5     cssmin: {\n 6       css: {\n 7         files: {\n 8           'dist/styles.min.css': ['src/css/*.css']\n 9         }\n10       }\n11     },\n12   });\n13 \n14   // Load our Grunt plugins.\n15   grunt.loadNpmTasks('grunt-contrib-cssmin');\n16 \n17   // Default tasks.\n18   grunt.registerTask('default', ['cssmin']);\n19 };\n

\n\n

If you look at the UglifyJS example we did previously, you’ll notice that they are very similar. Yay for standardization!

\n\n

Gulp

\n\n

\n $\"\"$

\n\n

At the time of writing this book, gulp.js is the new kid on the block. Just like Grunt, Gulp is a task runner. They basically do the same thing. Some of the key differences are:

\n\n

Gulp calls itself ‘The streaming build system’. It harnesses Node’s streams to greatly increase build times. For more on streams, check out the stream handbook.
Gulp has a simpler API. It has you writing JavaScript code instead of writing configurations in Grunt.
Gulp plugins are written for one specific task only, whereas Grunt plugins can often do multiple things. You can find a searchable list of Gulp plugins here.

Installing Gulp

\n\n

Installing Gulp is fairly simple using npm. Let’s install Gulp globally.

\n\n

1 npm install gulp -g\n

\n\n

Next, navigate to your project root folder (or create one if you haven’t already) and make sure you have a package.json set up. Don’t forget, you can do this by running npm init or by referring to the Dependency Management chapter of this book. Then, run the following command:

\n\n

1 npm install gulp --save-dev\n

\n\n

This will also install Gulp but this time locally. The important part is that we make a reference to it in the devDependencies section of package.json by using the --save-dev parameter.

\n\n

Why did we install Gulp both globally and locally? Well, we first install Gulp globally so that we can access the gulp command anywhere from the command line. However, this can make deployment difficult because there is no local package installed in the project repository. We install Gulp locally to create a dependency on it in our package.json. It also allows you to install different versions of Gulp simultaneously. It’s worth noting that when you run gulp in the project directory, the locally installed version will be used.

\n\n

Example Usage

\n\n

To demonstrate how to use Gulp, let’s set up a task to uglify JavaScript files using the gulp-uglify plugin. We’ll start by installing the pluign:

\n\n

1 npm install gulp-uglify --save-dev\n

\n\n

Just as with Grunt, Gulp also has a single file for defining tasks. We’ll create a file called gulpfile.js in the root of our project and use something like the following snippet to get started:

\n\n

1 var gulp = require('gulp'),\n2 \tuglify = require('gulp-uglify');\n3 \n4 // This task uglifies our JavaScript files.\n5 gulp.task('compress', function() {\n6   gulp.src('src/js/*.js')\n7     .pipe(uglify())\n8     .pipe(gulp.dest('dist'))\n9 });\n

\n\n

You’ll want to create a few dummy JavaScript files in the src/js folder to test with. From the command line, run gulp compress to run the compress task that you defined. You should then see the following status messages:

\n\n

1 [11:36:18] Using gulpfile ~/myApp/gulpfile.js\n2 [11:36:18] Starting 'compress'...\n3 [11:36:18] Finished 'compress' after 8.87 ms\n

\n\n

If you look in the dist folder, you’ll notice that each of the JavaScript files we created have been uglified but unlike the Grunt plugin they have not been concatenated. This is because Gulp maintains the ideal that each plugin should only do one thing. So if we wanted to concatenate first and then uglify we would firstly need to install the gulp-concat plugin:

\n\n

1 npm install gulp-concat --save-dev\n

\n\n

Then, we could update our gulpfile.js to look something like this:

\n\n

 1 var gulp = require('gulp'),\n 2   uglify = require('gulp-uglify'),\n 3   concat = require('gulp-concat');\n 4 \n 5 // This task concatenates and uglifies our JavaScript files.\n 6 gulp.task('compress', function() {\n 7   gulp.src('src/js/*.js')\n 8     .pipe(concat('scripts.js'))\n 9     .pipe(gulp.dest('dist'))\n10     .pipe(uglify())\n11     .pipe(gulp.dest('dist'))\n12 });\n

\n\n

Now, once you run gulp compress, you will end up with a single concatenated and uglified file at dist/scripts.js.

\n\n

Before moving on from Gulp, we need to know how to set up file watching. Grunt required us to download a separate plugin to do this, whereas Gulp includes watch functionality from the get-go. Let’s say we want to watch for any changes to our JavaScript files and run the compress task once that occurs. We would need to alter our gulpfile.js as shown below:

\n\n

 1 var gulp = require('gulp'),\n 2   uglify = require('gulp-uglify'),\n 3   concat = require('gulp-concat');\n 4 \n 5 // This task concatenates and uglifies our JavaScript files.\n 6 gulp.task('compress', function() {\n 7   gulp.src('src/js/*.js')\n 8     .pipe(concat('scripts.js'))\n 9     .pipe(gulp.dest('dist'))\n10     .pipe(uglify())\n11     .pipe(gulp.dest('dist'))\n12 });\n13 \n14 // Watch our files for changes.\n15 gulp.task('watch', function() {\n16   gulp.watch('src/js/*.js', ['compress']);\n17 });\n18 \n19 // The default task is used when `gulp` is called from the command line.\n20 gulp.task('default', ['compress', 'watch']);\n

\n\n

We’ve set up a new task called watch which is fairly self-explanatory. Also, to simplify things further, we have defined another new task called default which runs our other tasks. So all we need to do now is hop over to the command line and run gulp. Now, whenever we make any changes to our JavaScript files, the compress task will run automagically.

\n\n

Gulp is simple and fast. Once you learn its API, the idea of code over config is a very welcome one. We’ve only touched the surface of how powerful Gulp can be. For more information, read the official documentation.

\n\n

So which one should you be using? Probably Grunt. Gulp is still on the bleeding edge. Its ecosystem needs more time before it should be considered as a replacement for Grunt. That being said, Gulp is an excellent tool and hopefully will continue to develop.

\n\n

CodeKit

\n\n

\n $\"\"$

\n\n

CodeKit is a Mac app created by Bryan Jones. It aims to take a lot of the pain out of setting up an automated workflow by providing an array of the most common and useful features for web developers:

\n\n

Has a built in web server which supports live browser refreshing across all of your devices.
Watches for code file changes and compiles them with linting and minification.
Has built in Bower support for installing and managing components.

The most appealing part of CodeKit is that it is very easy to get up and running. All you need to do is install the app and it just works. There is no fumbling through configuration files trying to figure out why your build script isn’t working correctly. On top of that, the app’s UI is cleanly designed and a pleasure to use.

\n\n

Remember though that CodeKit is a Mac only app, so if you are working with other developers you may want to check they can actually run it before diving in.

\n\n

To find out more, watch these demonstration videos on the CodeKit homepage. Although there is a free trial, the app requires you to purchase a one time license for full use.

\n\n

Yeoman

\n\n

\n $\"\"$

\n\n

Yeoman defines a powerful workflow that helps you kickstart new projects by installing and configuring almost everything you could need to start developing your web applications. It greatly reduces the amount of time you need to write boilerplate code so that you can start developing sooner.

\n\n

Yeoman provides an ecosystem of ‘generators’ which can be used for setting up the foundations of different types of applications. The generators are opinionated, meaning that although best standards are followed for the most part, they may not be perfectly configured for your specific needs.

\n\n

There is a reason for leaving Yeoman until last. It can be quite tempting to use a generator to lay the scaffolding for your application without actually knowing everything that it is doing. Ideally, you should learn at least the basics of all the different tools that Yeoman installs and configures before actually using Yeoman. That way, it is much easier for you to configure your application after Yeoman has done its magic.

\n\n

The Yeoman workflow is comprised of three separately maintained tools: Yo, Bower and Grunt. Yo is the name of the actual scaffolding app from Yeoman, Bower is covered in the Dependency Management chapter of this book and Grunt has been covered at the beginning of this chapter.

\n\n

Installing Yo

\n\n

Yo offers web application scaffolding, utilizing scaffolding templates referred to as generators. All we need is npm to install Yo:

\n\n

1 npm install yo -g\n

\n\n

Once Yo is installed, you will need to pick a generator best suited to your requirements. As an example let’s install generator-angular, which utilizes a bunch of features that may be required of a typical AngularJS front-end web application workflow:

\n\n

1 npm install generator-angular -g\n

\n\n

As is the case with Yo, we install generators globally so that they can be accessed from anywhere in the command line. Once the generator is installed, we can create a new directory for our project and from within it run:

\n\n

1 yo angular\n

\n\n

You will be prompted with a few questions which will allow you to configure which tools will be installed. Once answered, sit back and relax as Yo takes care of downloading, installing and configuring everything. There is a lot of text scroll during this process so make sure your terminal window is full screen so that people around you think you’re working in the matrix.

\n\n

Once complete, you’ll want to spend some time looking through all of the files and folders that have now been placed in your project root. In this particular generator, a whole bunch of tasks have been defined in your Gruntfile.js from which you can learn a lot about some of the best practices used in the developer community.

\n\n

There are literally hundreds of generators available, many of which are unofficial and contributed by the community. You can view the list over at the Yeoman official page.

\n\n

Other Tips

\n\n

The goal of this chapter is to help you become the most efficient developer you can be. To help you on your way, here are a few tips and tricks to make your life a little easier.

\n\n

z

\n\n

The more projects you work on, the more frustrating it can be to navigate between all of their directories in the command line. Enter ‘z’, a handy bash script that helps you to jump around directories in the command line. It tracks your most frequently used directories and allows you to navigate them by simply entering part of their name. For example:

\n\n

1 z myApp\n

\n\n

For example, this may take you to /var/www/myApp if that is a directory that you frequently access.

\n\n

To install, grab the z.sh file from https://github.com/rupa/z and write something like this in your $HOME/.bashrc or $HOME/.zshrc:

\n\n

1 . /path/to/z.sh\n

\n\n

Alfred.app

\n\n

Alfred, perhaps named after the famous butler of Batman, is a Mac app that can be used as a replacement for the OS X Spotlight. Among many other useful productivity tasks, Alfred helps you save time by letting you search the web or your computer for files and applications with a few keystrokes. Alfred comes highly recommended to any hardcore Mac user. However, it is worth noting that Apple made some great changes to the OS X Spotlight in Yosemite and you may find that sufficient enough.

\n\n

\n $\"Alfred$

Alfred boosts productivity

\n\n

Chrome DevTools

\n\n

One of the strongest attributes of the Google Chrome browser is its set of Developer Tools - more commonly known as DevTools. They are a set of web debugging tools directly accessible from within your browser. Although other browsers, such as Firefox, do come complete with their own set of tools for developers, Chrome probably provides the best implementation. If you’ve not used DevTools before, go ahead and install Chrome and read the overview documentation.

\n\n

\n $\"Chrome$

Chrome DevTools is the essential web page debugging tool

\n\n

Sublime Text

\n\n

Looking for a new text editor? Something with a super slick interface and huge range of features? Look no further. Sublime Text for Mac is quickly becoming one of the most popular text editors for developers.

\n\n

\n $\"Sublime$

Sublime Text has a super slick interface

\n\n

Its flagship feature, ‘Goto Anything’, has quickly become one of the main reasons for developers falling in love with Sublime Text. By simply pressing Command-P you can quickly navigate to any file in your project. For a full list of its features, and guidelines on how to install, check out the official homepage.

\n\n

Summary

\n\n

In this chapter, we took a fairy detailed look at the task runner Grunt and touched on other options such as Gulp and CodeKit. You’ve seen how important task runners can be, and how they can help you become a more efficient developer. We then looked at a few tips and tricks to speed up your workflow when developing.

\n\n","tocStructure",[159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175],{"_81":82,"_43":83,"_75":-5,"_84":85,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":61,"_75":-5,"_84":91,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":67,"_75":-5,"_84":96,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":82,"_43":98,"_75":-5,"_84":99,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":102,"_75":-5,"_84":103,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":105,"_75":-5,"_84":106,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":108,"_75":-5,"_84":109,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":111,"_75":-5,"_84":112,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":82,"_43":114,"_75":-5,"_84":115,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":82,"_43":118,"_75":-5,"_84":119,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":122,"_75":-5,"_84":123,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":125,"_75":-5,"_84":126,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":128,"_75":-5,"_84":129,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":131,"_75":-5,"_84":132,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":134,"_75":-5,"_84":135,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":137,"_75":-5,"_84":138,"_77":86,"_92":-5,"_93":-5,"_94":-5},{"_81":90,"_43":140,"_75":-5,"_84":141,"_77":86,"_92":-5,"_93":-5,"_94":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

SAMPLE

Table of Contents

About the Authors

Joe Fender

Carwin Young

Introduction

Who This Book Is For

An Overview of This Book

1. Getting Started

2. Frameworks

3. Styling

4. Dependency Management

5. Automation

Example Code

Contacting the Authors

SAMPLE

Automation

Task Runners

Grunt

Installing Grunt

The Gruntfile

Popular Plugins

Watch, LiveReload and Connect

Copy and Concat

Linting with JSHint and CSSLint

Minification with UglifyJS and CSSMin

Gulp

Installing Gulp

Example Usage

CodeKit

Yeoman

Installing Yo

Other Tips

z

Alfred.app

Chrome DevTools

Sublime Text

Summary