Edit: Some of the material in the Assembling a Frontend Stack posts is outdated. Specifically, I no longer use Bower in any of my projects.

This is not as easy as it used to be

Gone are the days of just a little HTML, CSS, and Javascript. Well, that's what you end up with, but getting there is so much more complex than it was just five years ago. What Javascript framework or toolset will you use? What module system? What css precomiler? Should you transpile in ES6 features? What testing framework is best?

To those accustomed to developing in other ecosystems, this diversity of choice can be maddening. But if you're going to be building the web, you better get used to it. The Javascript world is a wild one. People are reinventing new and better wheels here everyday.

The wider Javascript world has also been heavily influenced by the Node community and its philosophy to keep libraries small and single-purpose (of course, they didn't invent that idea). This often multiplies the number of libraries you need to accomplish stuff in Javascript land.

And that's ok. IF you have a good build system. Without one, you will resort to manually running command line tools (or forgetting to manually run command line tools) and will generally lose track of all the different tasks needed to build your frontend project. In the end, you will probably give up, complaining that the Javascript community is crazy.

But with a good build system, the quickly evolving Javascript landscape can be downright fun. The reason people use all these tools and frameworks is that they can help you write better code, often much more quickly than without them.

gulp.js

gulp is a great build tool (lowercase "g" seems to be correct, except in their logo, which is confusing).

What about Grunt?

Grunt is great too. Setting up Grunt is like writing a configuration file. Sort of. It's mostly like a configuration file, but Gruntfile.js is actually a Javascript file and you typically end up writing some code in there too.

gulp's configuration file is unapologetically code. gulpfile.js is a script that utilizes gulp's simple API to string plugins together. You would think that configuring with code would mean more complexity, but in my experience it's just the opposite. For a developer, it's more clear, more concise. It's usually faster too, because files are streamed in memory between plugins, not written to disk to be read by the next plugin.

gulp seems more flexible as well. In the end, I switched from Grunt to gulp because I wanted to do something simple with Handlebars templates (just wrap the compiled template in module.exports = ... ;). The available Grunt plugins wouldn't do it right (IMO), but it was simple to write a gulpfile that did exactly what I wanted.

Gimme some config

In the posts that follow, we will assemble a full frontend stack using gulp.js. The frameworks and libraries used were chosen because they are commonly used, not necessarily because I think they are the perfect choice among competing options.

We will use:

• Javscript modules in separate files using CommonJS; Browserify to assemble them
• Backbone.js for our frontend "framework"
• Handlebars for templating
• JSHint for code linting
• Bower for frontend dependency management
• Less for our css precomiler
• Bootstrap for our design framework
• gulp to pull it all together

See the finished files in my github repo for these posts.

• In part 2 we will address incoporating 3rd part dependencies like jQuery and Bootstrap with our own Javascript modules. (spoiler: yes CommonJS/Browserify. yes Bower. no RequireJS)

• In part 3 we will add Handlebars and JSHint to our gulp build

• In part 4 we will incorporate Less, Bootstrap, and automatic rebuilding with gulp.watch and livereload

Read on.