Build tools and task runners were invented to prevent human error and make your life easier. They can bring you workflow nirvana, or cost you countless hours of aggravation and misery. There are quite a few options getting love from developers these days, so choosing your side can certainly be overwhelming — especially when new options seem to be popping up every day!

Everyone’s Got Choices

Which tool is the best fit for you and your project? The short answer is any of them. If you’re at the point where you’re trying to automate your process then you’re already doing something right, so good on you! The long answer, however, brings us to the battle between Brunch and Gulp.

Meet Brunch

Brunch entered the game in 2011 with two core principles in mind: keep it simple and make it speedy. It makes a few assumptions (see also: limitations) about your project, but in return it gives you an extremely simple project setup that runs incredibly quick.

Meet Gulp

Gulp is the “code over configuration” tool that won our hearts in the last showdown. It’s a super customizable tool with a pretty impressive plugin library that’s gained a lot of popularity in recent years.

Ready? Fight!

Both of these tools are great, but there’s definitely pros and cons for each. We’re going judge these on five areas of importance — documentation, configuration, community, customization, and speed. Best three out of five takes the cake! (The cake is a lie.)

Tell me something good (documentation)

Brunch has a detailed set of documentation on its site that will get you up and running quickly. The detailed explanations behind core concepts cover getting started, installing plugins, installing JS modules, testing, and deploying. It’s organized, the information is well explained, and there are little brunch puns littered throughout (bonus!).

Gulp’s documentation is it a little bit harder to navigate. Visiting the “Docs” section of their website brings you to some documentation that resides in their GitHub repo, but there’s also an entire readme.io version of the information that’s somewhat overlapping but different. Overall, it’s pretty extensive, albeit a little less organized than Brunch’s. Much like the other, you’ll find a section on getting started with Gulp, and some information on using the API and CLI. There’s also a great jumpstart guide for writing your own Gulp plugin.

Winner: Brunch (barely)

Start me up (configuration)

This is where Brunch really shines. It makes a few assumptions about your project (outlined here), but also makes setting up your project a breeze. A typical config for Brunch might look something like this:

module.exports = {
  files: {
    javascripts: {
      joinTo: {
        'vendor.js': /^(?!app)/,
        'app.js': /^app/
      }
    },
    stylesheets: {joinTo: 'app.css'}
  },

  plugins: {
    babel: {presets: ['es2015', 'react']}
  }
};

Conversely, Gulp makes no assumptions. You’ll need to tell Gulp everything about how it should run, but it’ll also be a lot more customizable this way. A typical Gulp set up might look something like this:

var gulp = require('gulp');
var coffee = require('gulp-coffee');
var concat = require('gulp-concat');
var uglify = require('gulp-uglify');
var imagemin = require('gulp-imagemin');
var del = require('del');

var paths = {
  scripts: ['client/js/**/*.coffee', '!client/external/**/*.coffee'],
  images: 'client/img/**/*'
};

/* Register some tasks to expose to the cli */
gulp.task('build', gulp.series(
  clean,
  gulp.parallel(scripts, images)
));
gulp.task(clean);
gulp.task(watch);

// The default task (called when you run `gulp` from cli)
gulp.task('default', gulp.series('build'));


/* Define our tasks using plain functions */

// Not all tasks need to use streams
// A gulpfile is just another node program and you can use all packages available on npm
function clean(done) {
  // You can use multiple globbing patterns as you would with `gulp.src`
  del(['build'], done);
}

// Copy all static images
function images() {
  return gulp.src(paths.images)
    // Pass in options to the task
    .pipe(imagemin({optimizationLevel: 5}))
    .pipe(gulp.dest('build/img'));
}

// Minify and copy all JavaScript (except vendor scripts)
// with sourcemaps all the way down
function scripts() {
  return gulp.src(paths.scripts, {sourcemaps: true})
    .pipe(coffee())
    .pipe(uglify())
    .pipe(concat('all.min.js'))
    .pipe(gulp.dest('build/js'));
}

// Rerun the task when a file changes
function watch() {
  gulp.watch(paths.scripts, scripts);
  gulp.watch(paths.images, images);
}

Winner: Brunch, if brevity is your thing

I get by with a little help from my friends (community)

Brunch currently has just under 100 plugins to its name, while Gulp has upwards of 2,800. The wide difference here may be due, in part, to the fact that Brunch gained NPM support somewhat recently. Gulp also went out of their way to make plugin documentation easily accessible for developers, which may have also been a factor.

For any questions or issues you might have, Brunch has an active online forum you can post to and Gulp has a similarly active IRC channel. Both tools have active participants in Stack Overflow as well.

Winner: Gulp

You can have any color you want, as long as it’s black (customization)

Brunch is relatively limited in this category. As we mentioned earlier, it simplifies the setup process tremendously by making some basic assumptions about the setup of your project. Unfortunately, if you’re project is exceptionally unique it might be quite a headache trying to customize Brunch to work with what you’ve got.

Conversely, Gulp really shines here. The configuration file is definitely more demanding than Brunch’s, but it offers pretty much unlimited flexibility. You can control just about every aspect of the task runner through the many options made available to you in the Gulp API and CLI documentation. And, of course, those 2,800+ plugins don’t hurt either.

Winner: Gulp

If you’re not first, you’re last (speed)

Both of these tools are impressively speedy. Brunch makes speed one of its top priorities, and it uses incremental builds by default to filter out unchanged files in concurrent build processes, which makes it hands down one of the quickest processes we’ve worked with. Gulp also has the option of running incremental builds, but it requires you to set it up that way. (You can see how to do that here.) Even without that setup, Gulp runs a pretty efficient process overall by using node streams to prevent the potential bog down from writing intermediary files.

Winner: Brunch

And the winner is…

Our favorite meal, Brunch! But not by much. Your choice here will really depend on what you’re looking for in your build tool. Brunch is definitely the simpler option to get set up quickly, and it works well for us here at Oomph. If you’re the type of person who likes to control every aspect of your build or you have a really complicated and customized project setup, Gulp is probably the better choice for you. At the end of the day, what really matters is that you’re automating your process. The tool you use can certainly have an effect, but doesn’t make too much of a difference — go do it!

If you’re working in an industry that handles information relating to health care, there’s a good chance your organization has strict security practices and your next website refresh won’t be as simple as discovery-design-build-ship. There are going to be a lot of checkpoints along the way relating to security and governance—all designed to protect patients and customers and ensure control and privacy of sensitive data.

Factor in security while planning the project timeline

As you work to map out the project timeline, you must be aware of critical, albeit time-consuming, tasks that are not tied directly to the development of a website project.

When budgeting for the new project, be sure to factor in the time it will take to collaborate with vendors providing services to secure your site. It’s likely that your technical team, responsible for the build, will have their hands tied when it comes to configuring things like firewall settings, access whitelisting, and DDoS protection, and it isn’t always easy to predict how much time vendors will need to process your team’s requests.

Prioritize Security Testing

There are typically multiple rounds of security and penetration testing that need to happen before your organization will sign off on launching a new project. The testing window needs to be planned in advance, and it’s always a good idea to notify your hosting vendor to make sure they’re aware the testing is taking place. That way, they can disable monitoring and avoid false alarms. Once your site passes security testing, it’s recommended that there be a code freeze—meaning no new changes should be introduced, unless another round of security testing is planned.

Build on a Safe Platform

The easiest way to launch a successful and secure site is to start with a framework that offers considerable security benefits out of the box. Drupal is an open source CMS that can easily support a high traffic site with complex features, and it has one of the largest communities of open source contributors maintaining it. Not only that, but there’s a <a href=”//security.drupal.org/team-members”target=”_blank” rel=”noopener noreferrer” title=”Opens in a new window”>dedicated security team that provides security oversight, announcements, and patches to keep the platform secure.

Secure Your Application

With your new project on a widely supported and secure CMS, you might want to consider further restricting access to administrative functions like content creation and editing. There are a few ways to accomplish this, and they can be layered together to ensure the CMS is protected from being defaced or otherwise breached.

Multi-factor authentication

The first and arguably simpler form of protection is to enable multi-factor (MFA) or two-factor (2FA) authentication. Many popular services you already use offer this level of security, and it usually works like this:

Multi-factor authentication works because just having a username and password is not enough to gain access to an application.

Content editing over VPN

Another way to protect your application is to prevent visitors from being able to access your site’s login screen to begin with. Normally, anyone can access your login screen if they know the path to it, which opens up your site to brute force login attempts. While it means your editors will need to jump through a few extra hoops to do their work, blocking requests to these pages will make your site more secure.

This configuration is more complicated than a multi-factor approach, as it requires you to have separate servers accessible only to users who have already logged in to a VPN. On the publicly accessible servers, the paths to login screens are blocked and inaccessible by visitors. This provides a great level of security, especially when coupled with multi-factor authentication.

Put a limit on login attempts

Out of the box, many systems don’t limit the number of login attempts a user is allowed to make. Preventing users from trying to login after a certain number of attempts, or limiting the number of attempts within a span of time is a good way to thwart attackers. Drupal’s Login Security module provides some configurable settings for how to handle failed login attempts.

DDoS Protection

Any site can be the target of a Distributed Denial of Service (DDoS) attacks, but often the bigger the site, the more likely it will be targeted with an attack. DDoS attacks overwhelm a site’s resources with requests from many locations at once, making it difficult to just block a single IP to stop the attack. Successful DDoS attacks will cause a site to stop responding to legitimate visitor requests and can quickly impact your business.

The simplest solution to prevent and monitor for DDoS attacks is to route traffic through a service that provides DDoS protection as a service. Often, these service providers offer additional benefits like static page caching to speed up your site, or rate limiting rules for specific pages.

Avoid server strain with rate limiting

Rate limiting allows you to throttle the number of requests to certain pages of your site, which can be especially useful for features like web forms that require more overhead than serving static content, and are often abused by spam bots.

A lot of vendors offering broad DDoS protection services can configure complex rate limiting rules to limit how many requests can be received by specific paths on your site. If your application offers an API, or if you have forms on the site that could be abused by an attacker trying to overload your site with malicious traffic, it could be worthwhile to consider rate limiting.

Wow, that was a lot to digest

There’s a lot to consider and plan for with large digital projects, and a lot of decisions need to be made along the way. The best way to be prepared is to consider security and other critical aspects of a successful launch early on and to work with a team you can trust to help with vendor selection and communication.

To work with a team that understands how to manage all of these solutions, please feel free to speak with us anytime.