Adopt primary local and remote build tool

[jmatsushita]

We've used https://github.com/mfenner/jekyll-travis which includes a Rakefile for building the site but it creates a dependency on Rake.

There's also a bash script in this post http://eshepelyuk.github.io/2014/10/28/automate-github-pages-travisci.html

Using Rake means some install time (although it is supposed to be a preinstalled gem on travis), and knowing Ruby to add build steps. Since Ruby will be needed for Jekyll it makes use of this though and can be run locally where Jekyll needs to be run. Mimicking Jekyll in Metalsmith would remove the Ruby dependency and only depend on Node

Using a DSL (stored as data in a configuration file) would be more in the philosophy of the project. Making the dependency of this DSL be Node, means part of the code could be reused on the browser side, and means a lower barrier to entry to extend it (in the way metalsmith does).

Bringing in other dependencies (like Jekyll) through containers might be the way to have very good portability and interoperability (wrapping any ssg or build system or validation system into containers) as well as an architecture that prepares for micro-services.

[jmatsushita]

It might make sense to use npm as the build system as described here http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/

Grunt and Gulp. I like the config over code from Grunt, but Gulp's streaming seems like good design.

Broccoli's cache system seems good. https://github.com/broccolijs/broccoli

Sigh looks bleeding edge: https://github.com/sighjs/sigh and is based on FRP principles which apart from drawing on FP means that the API should work well for dealing with orchestration like tasks.

[jmatsushita]

But sigh doesn't make use of this yet for processes and introduces a new dependency. If we go the minimal way then until we need orchestration and better perf we can just use npm and see.

[jmatsushita]

npm also means introducing new dependencies and adds having to deal with merging changes into a package.json but might help to start introducing project level dependency management (docDependencies)?