Build speeds: Middleman just doesn't make a cut anymore (looking for a better solution)

#1

I am slowly concluding that Middleman is pretty slow compared to other solutions and static generators out there. It’s just doesn’t make sense to wait that long and re-generate every single file in /source just because I’ve removed a single character in one file.

Also, even if there was an option to skip files that weren’t modified, the pretty slow build a website that has less than 200 pages is laughably slow on a decent machine (1.7GHz Intel Core i7 with 8GB of 1600MHz DDR3 RAM).

It’s scary to think about what will happen once the site grows to 1000+ pages.

Having said that, I am looking for a static file generator that:
a) can skip re-generation of files that weren’t modified
b) has faster build times

Suggestions?

#2

I dropped Middleman earlier this year for similar reasons. Apart from poor performance, it’s aimed at Rails people (which I’m not). I couldn’t grok the documentation or find much help online

So I jumped to Hugo which absolutely flies. It’s not smart enough to do partial rebuilds. But the executable is so fast, that doesn’t matter. I’ve generated 1k+ page sites in less than three seconds.

#3

I like Middleman, and I’m immensely admiring of all the hard work (including optimization work) that the Middleman developers have put into it. That said, what you say is true – it’s not fast, and large sites take a significant amount of time to regenerate.

I’ve started building new sites using Hugo, which is based on Go and is extremely fast. I find it a little less friendly than Middleman, and not as easy to extend, but in terms of speed it blows Middleman out of the water. And if Hugo’s not fast enough for you, there’s always Nift. I haven’t tried Nift, but reportedly it’s about three times as fast as Hugo.

#4

I’m maintaining a Middleman 3.4-based blog with ~350 articles and ~450 additional pages (tag-pages, category-pages). It builds approx. 4 minutes both on my older i7 2.9 GHz and newer i5 2.7 GHz MacbookPro. That is not a problem for me, since all the changes are made in development mode, only sometimes I spot some error after a build. Sure, Middleman 4 is considerably slower. I use MM4 for most of other websites, but they are not big blogs with many pages, so performance is not such an issue.

I took a look at Hugo some time ago, but I’ve had a strong impression that Hugo is less elastic and customizable than Middleman. And I really appreciate Ruby as a programming language, so that was an additional bias for me, I guess.

Didn’t switched, so far. :slight_smile:

1 Like
#5

Well said and I agree. In my experience, Hugo needs a task runner like Gulp to fill its gaps; but MM solves most of those straight out of the box. If I were better with Ruby and could look past its slow performance, MM would be my go-to site generator.

Hugo just made more sense in the moment and now I’m embedded.

#6

The fact I am Ruby person myself is the only thing that keeps me hooked to MM.

And I believe, some of these speed issues in MM could be easily addressed: as I mentioned in my original message, I just don’t get it why do we want to regenerate every single page if I make the change to only one file.

When we build our sites, we don’t introduce the changes to ALL the files, usually we only add new or modify few of the existing files (add new or modify existing articles). The issue lies in modifications to few files that still forces us to regenerate entire site.

IDEA: Upon executing the build, Middleman would look up which files were modified since the last build (snapshot) and only regenerate those which were changed.

This alone would be a HUGE improvement and it seems fairly easy to implement without a need of rewriting the entire core from the ground up, maybe even as a gem before it gets merged with the core project.

1 Like
#7

Jekyll does it (also written in Ruby), so I would presume MM could do the same.

#8

Yup! I am not sure how the Jekyll handles changes that are introduced to css/js files though. If you have an asset hash enabled on MM, the hash will change but this could be also solved with an injecting and rewriting updated link in the place where asset link is, without regenerating whole file from the scratch.

#9

Because you never know what this change would do to other pages. Consider a sidebar with “Latest posts” list, or a list of tags with counters, etc. Each new page or change of date or tag-list on a single page means all the sidebar content needs to be rebuild on all pages.

This would only work for the simplest cases. If you don’t use sidebar-type content think about menu partial, as another example of the need to potentially re-generate the whole site because of a small change or new page creation.

Language modules and Tilt don’t work this way. There is no information “here is a css-link in this line” stored anywhere. The source-file is just passsed to Tilt, processed through a template-language-module and returned as a string (more or less precisely). Higher lever functions such as asset-hashes are just plugged to methods serving urls or link-tag, etc.

1 Like