Save yourself some time: Automating tasks in Frontend Development

Working on a frontend project you probably have dealt with CSS and JavaScript files. How do you handle those? Do you minimize them? Do you combine them?

I’m sure you’re aware of the benefits of minifying assets. You can save a lot of Kb’s from your CSS and JavaScript files. Nowadays performance matters, it really does. With more and more mobile users every day, your site should be lightweight.

How do we minify and/or combine assets before moving your site to production?

First of all, here’s a thought about folder structure for your project:

/dist
/dist/css
/dist/javascript
/source
/source/css
/source/javascript

I’d recommend using a folder structure similar to this one. Grunt does not force you to any specific folder structure, you’ll have the freedom to set the output folders on each task.

You’ll be doing all your work in the source folder. Your files will be commented, uncompressed and separated into components. It’s a good practice to breakdown your CSS into different files, it will help you and your team keep the code organized. Great for collaboration.

What’s with the dist folder?

The dist folder will eventually have all the processed files, perhaps a single CSS file (merged from 10 separate CSS components).

Bear in mind though:

Combining all CSS/JavaScript into 1 file is not a synonym for optimal performance.

Grunt-JavaScript

Grunt.js to the rescue

Let me quote what’s on the Grunt website:

In one word: automation. The less work you have to do when performing repetitive tasks like minification, compilation, unit testing, linting, etc, the easier your job becomes.

Doing everything I’ve been chattering about is possible with Grunt. Why’s so great?

  • Speed: all the tasks will be done for you, either every time you edit a file or whenever you run the terminal command.
  • Working with a team: the whole team will have the same file structure, you’ll share the configuration file so everybody will generate the same production files.
  • It’s what the cool kids are using.

How does it work? I think it’s best for you to take a few minutes and jump to the Get Started tutorial from their site.

Done reading? Cool, let’s continue.

Remember the dist folder I mentioned earlier? On most of the Grunt tasks you’ll set up is an output folder.

/* Grunt Config File */

concat: {
 css_main: {
 src: ['source/css/components/*.css'],
 dest: 'dist/css/project-main.css'
 },
}

NOTE: the concat task is part of the Concat Grunt Plugin. You must install it and configure it before using the concat task.

You’ll set it to this new dist folder so all your processed, compressed code will be located there (in the case above we’re merging all our files into one and saving it as project-main.css ).
When it comes to production we don’t want to upload our source CSS/JS files.

Watch for file changes.

That’s probably my favourite feature of all. By using the Grunt Watch Plugin you can simply run the grunt task on your terminal and watch over the changed files (please notice you’ll need some extra configuration in your Grunt config file before actually making this work, refer to the plugin’s site):

grunt

This will keep an open task in your terminal that will wait for any file change. Every Time you edit a SCSS or JavaScript file, Grunt will re-run. What’s great is that it will not run the whole thing.
Say all tasks (merge, compress, minify, move…) take up to 30 seconds. With the grunt watch it will just compile the affected files. Meaning it might only take 5 seconds.

I don’t like the Grunt logo, are there any alternatives?

Yes, check out Gulp.js

There’s plenty of blog posts out there breaking down a comparison side by side. It’s your job to decide what’s best for you and your team.

From what I’ve read both are more than capable of delivering your needs.

gulp grunt

Final thoughts

I know what you think, do I have to learn yet another tool?

I felt the same way the first time I read about Grunt.js At that time I was using a desktop application for compiling SASS, running JSLint, minifying… and that’s great, until there’s two developers working on the same project.

It can get complicated, some Grunt configuration files can easily have 300 lines. However, once you start reading and looking into it you’ll see it’s less painful than how it looks.

In my previous article I was trying to convince you to start coding your CSS using a CSS Preprocessor (SASS). With Grunt you can process all that files, merge them and move them to the dist folder without even thinking about it.

Did you know about Grunt? Are you already using it?

Share

Published by

Ricard Torres

Ricard is a Senior UI/UX Developer @ TBSCG. Based in Barcelona he also plays guitar, takes photographs and teaches Haidong Gumdo.

11 thoughts on “Save yourself some time: Automating tasks in Frontend Development”

  1. Great article Ricard! I didn’t know about grunt. The more you can automate , the better 🙂

    1. Thanks for the article Ricardo 🙂

      A quick question: what are Grunt’s advantages over Ant? I know most people here in the office use the latter, so how would you convince them to switch to Grunt?

      Thanks,

      Radek

      1. I think that there are many pros for Grunt over ant, several:

        1. ant is old 😀
        2: ant is builder more like bash scripts, not front-end focused (as grunt/gulp are designed for designs – this is most advantage)
        3: afaik Ant has no default plugins (unless you build your own ie. in Java) and Grunt has a lot plugins doing exactly what you need
        4: Grunt config is easy to read as is object oriented and don’t have this sh**ty, unnecessary xml structure. Moreover everything what can be done with JS can be used in Grunt so it makes it very flexible and powerful…

        But you need to remember that Ant is build maker for whole envs and Grunt/gulp were specially designed for front-end devs (have everything what we need to build good design easly and fast). So Grunt has it’s own limitations and cannot replace Ant everywhere…

  2. Great Article. And now that i know that ‘all the cool kids’ are using it, i think i will look into it too!!

    1. Thanks Dan, you definitely should. Do some research and see if it can save you some developing time.

  3. This is pretty neat. You cool kids have it easy! 😉
    I wish we had all the tools in the dark gloomy days of Netscape!

Comments are closed.