So in the midst of waiting to see if I’ll ever get a response on this site-breaking middleman bug, I thought that maybe what I should do is to document what I actually really need in a static site generator to make it easier to judge the tools I’m considering. Basically, why did I care about middleman in the first place.

then vs. now

It’s been ages since I made the switch to middleman, but I’d say the huge thing that’s changed since then is that I’m ready to embrace the so-called Single-page application architecture. Before, I was very much concerned about the SEO implications of doing something in JS only. But times have changed, and google supports scraping fully JS driven sites. Granted, that leaves things like Bing out for now, but I know from looking at my own analytics that non-google search engine traffic is a tiny tiny percentage in most cases. Frankly, for most of my sites, it’s not enough of a percentage to care about.

I won’t lie though. For my sites that already exist, that rely heavily on search engine based traffic, I’ll definitely be hesitant to make the switch to something heavily JS centric, given that you never know.. just because google can scrape your site doesn’t mean they’re not futzing with their algorithm and secretly penalizing you for the site being JS only.

For all brand new sites though, I’m definitely ready to throw caution to the wind, if it means I can find a toolset that makes my life easier.

things I cared about then, but probably not now

  • individual static HTML page generation (though there are still reasons to prefer it, see below)
  • haml support - the more I move towards doing things in reactrb, the less I have a need for something like haml/slim/erb
  • similarly, partials and layout files. Reactrb components will be handling all of these types of things going forward
  • seamless integration with sass/coffeescript/etc. This will likely be handled by webpack going forward, so I no longer need the generator itself to support it. And as a side note, a huge pull of middleman back in the day was its support for sprockets, and now sprockets is not even officially supported

generate individual html pages - nice to have, maybe

So along those lines, one of the tools I’ve been looking at is gatsby and I actually have mixed feelings about the fact that it will generate actual individual html pages for each of your site’s pages. So basically, you’d enter at X page and X page would have all of the HTML (and CSS even apparently) needed to render that page. It would also include JS files that would allow the rest of the site to be loaded dynamically through reactjs instead of having to generate full page loads.

the good

  • don’t have to worry about SEO since static HTML is still being generated
  • faster rendering than having the user have to download the entire site before that particular page is generated
  • don’t have to worry about figuring out wildcard routing (where /any/path/on/the/site all points back to a main index.html file somewhere). On that note, I tried getting wildcard routing set up with cloudflare but it looks like they only support traditional page redirects. I’m assuming that I’d have to put nginx in front of any static site where I want to do wildcard routing.

the bad

In general, the bad can be summed up as: an html page is getting generated for every single page (hence why I have mixed feelings on a tool supporting this).

Like with cyclocane, there’s somewhere in the neighborhood of 100 pages that have to be generated on every build. Combine that with the cache buster method I’m using and that means that anytime an asset (JSS/CSS) is updated, all of those HTML files will also need to be re-uploaded as well.

has to support opal/reactrb

I’m just getting started on using things like webpack, so maybe ultimately, any static site generator that can be integrated with webpack, is something where I can use Reactrb and Opal. I don’t really know yet.

internationalization

cyclocane makes extensive use of internationalization (and google translate, but that’s another story). I’m kinda undecided on how I need this to be supported. Like, I never liked how middleman did internationalization, but that might just be the problem of internationalization in general: it makes a webpage’s source damn near impossible to read.

And then for cyclocane, if I add some new content, I need to update 5 files:

  • the html source
  • the english keys
  • the spanish keys
  • the french keys
  • the german keys

And I’d actually like to add more supported languages. Ugh.

And cyclocane has never supported anything other than english in the javascript added content. This is something I’ve always wanted to fix.

So going forward, FormatJS is what I have my eye on for translating reactrb pages. But here would be one problem with something like gatsby where it’s generating a file for every single page… that means I need for gatsby itself to be internationalization aware right? I’m assuming so.

should be fast

There’s only one or two projects where this is super important. tornadohq is definitely one.

Basically, I’m updating warning data something like every 15 seconds. Since middleman takes far too long to build, I basically update only the json files after grabbing new warning data. Then every X minutes or so (I actually forget how long), I rebuild the entire site. One thing that would greatly speed things up is if I could figure out how to not rebuild the JS files everytime.

shouldn’t be too difficult to integrate a blog, while not being the focus

Jekyll is a decent static site generator, but its origins are as a blog engine. It’s been awhile since I took a serious look at it, but the problem I always had with it was that, though you could use it for non blog content, it was always obvious that you were using an unplanned-for type of content in a system designed for blogs. Granted, it’s been awhile, so maybe that’s no longer the case.

And I haven’t had enough of a chance to dig into gatsby to see if their “starter blog” project might have the same problem of being too blog centric. Or alternately, that their non blog starters would make it too difficult to integrate a blog.

a list of what I’m considering so far

Mind you, some of these may not actually be options for what I’m wanting to do. I don’t know yet.

  • building my own
  • staying with middleman (better the devil you know?)
  • gatsby - reactjs static site builder, has helpful “starter” repos that you can build off of
  • metalsmith - looks to be a pretty flexible static site builder, but might require too much configuration for my tastes to make it how I want it
  • phenomic - looks to be similar in spirit to gatsby in that it sounds like it will generate static html while changing over to straight reactjs if the user has javascript enabled
  • hugo - apparently it’s super fast, that’s basically why it’s on my radar

Will I find the successor to middleman or will I end up just going back? That is the question.