Spike vs. X

There are tons of fantastic projects out there for generating static sites, so you may be asking yourself why would I choose spike over X? Let's make some comparisons to get a better idea:

Gulp / Grunt

There are a couple great open source projects that describe themselves as build systems, and are commonly used to generate static sites. Let's be clear that you can use gulp or grunt to accomplish the same thing as Spike does. But that would mean wiring up a bunch of configuration yourself for every project. If you are building a static site, there's no reason not to use Spike over a generic build system because Spike is built specifically for static sites. Unless you simply enjoy the process of spending bunches of hours writing and maintaining huge configuration files manually, Spike is a flat out superior option, because we have already done this for you, for free.

For comparison, you can also use an Excel spreadsheet to manage your finances, as Excel is a good general purpose tool for managing data. But a tool built specifically for managing finances is going to be a better solution for finances specifically, which is why companies like Mint have done so well.

Middleman, Jekyll, etc.

Middleman and Jekyll are great projects, but suffer from one fatal flaw -- they are written in Ruby. Tools built for the front-end tend to be written in Javascript, since you must know Javascript if you are making websites, it's the only language you can use in a browser. As such, all of the large popular and stable front-end tools emerging from the community (grunt, gulp, webpack, postcss, yeoman, react, etc) are written in Javascript. A project written in Ruby is simply not able to smoothly interoperate with these tools because they are written in different languages. In addition, if you are asking your front-end developers to use Spike, you can feel comfortable that you are not asking them to learn a second programming language every time they interact with it -- it's just Javascript, which they already know.

Additionally, you can exactly replicate all of Jekyll's functionality using spike through the Spike Collections plugin. If you are looking to switch over to a faster, more modern, more flexible, and node-based SSG and are familiar with Jekyll, get started with spike's Jekyll Template.

Hexo, Octopress, Wheat, etc.

There are a number of static site generators built specifically for blogs. If you are trying to make a blog, these are probably a great choice. Spike is not built specifically for blogs though. You can make any sort of static site with Spike, including a blog. As such you get a lot more flexibility, but you won't get the fine-tuned blog-specific feature set as you will with a blog-specific framework (unless someone makes a plugin that introduces this).

Phenomic, Gatsby, etc.

More recently, there has been a class of static site generators built specifically around React, integrating jekyll-style frontmatter on every page. While these are great especially for their ability to reload quickly due to hot loading, their absolute dependance on React means that if React eventually declines in popularity or utility, as all programming frameworks have done in the past, you are stuck with existing sites operating on a legacy system. You are welcome to use any framework, including react, with spike, and they all work well, but none of them are integrally tied into the core code, giving you the freedom to use the front-end tooling that you want and that best fits your team's needs, both now and indefinitely into the future.

Additionally, these types of tools tend to be built to be more similar to jekyll in that they are centered around building your data from collections of static files, rather than piping in data from APIs. For small sites, this is ok, but as you start to range into the medium/large range, or if you have nontechnical content editors that require a CMS, you will run into trouble with this model.