An Introduction to Static Website Generators

If you're familiar with working on large template driven CMS websites, you might occasionally find yourself looking for some light weight alternatives. Perhaps you have a project that doesn't have budget for backend development but which would benefit from a powerful design template system. Or maybe you have the technical requirement for your site to use static HTML files instead of a dynamic server application. Or for whatever reason you decide you just don't need a web-based CMS admin tool.

Meet the static website generator. This is a set of tools that can compile and publish a fully static website from templates and content files. When you want to make an update, you change the content in a series of simple text files, run a publish script that generates a new version of the full site, and upload the new files to your server.

There's a whole slew of these available for various coding environments and languages. We've reviewed and worked with a few of the ruby-based ones (namely Jekyll & Bonsai). We used Jekyll for the Google for Veterans and Families project as a way to easily apply a few consistent design templates to 50 pages of content for a quick turn around. I also really enjoyed working with Bonsai on my personal site to create a very flexible page hierarchy and navigation that can be altered just by re-arranging or re-naming folders. Jekyll has a lot of community support and is intended to be more of a blogging platform than a free-form page-based website.

There are dozens of other options out there that might be a better fit for your project. A few lists of alternatives are here and here.

Advantages of static websites over server-side CMS sites:

Fast page loads. Static pages are much faster to deliver than dynamic pages because the server doesn't need to fetch data from a database and merge it with the templates. Sure caching goes a long way to speed up a CMS-based site, but static will still be the fastest, most stable option.

Security. There's less opportunity for someone to exploit a security flaw in the program if there isn’t a server application generating the website files.

Speed and ease of development. In many of our projects that involve CMS systems, we don't always have access to the template merging system while developing the page templates. We often go through rounds of revisions and bug fixing after the templates are initially integrated in the CMS. With this type of system, we can preview the whole thing while developing to see the template with a variety of content pages without the need for updating anything on a production server. It also brings all the development to one place instead of having a rift between back-end and front-end developers.

Version control. It's easy to keep all the content and template files under version control so, if needed, the whole site can be rolled back to a previous state,Django and some others do a good job of this to varying degrees however its not always a given with CMS's.

Disadvantages of static site generators:

Content management is complicated. The static generator sites generally rely on editing text files in some relatively clunky markup language that requires a bit of learning and documentation (YAML and Markdown are popular options). The different versions vary greatly in setup and often require a fairly strict folder structure or naming convention to setup the data and asset folders in order to create the site's navigational structure, misplacing or mis-naming files often results in pages not showing up in the nav or being excluded all together.

Content management is not easily accessible. Web-based CMS's provide great tools that are available anywhere you can get a web browser to log in, and are generally much more approachable to a novice editor. Republishing with a static generators requires access to a development environment that is setup to run the build tools (Ruby, etc.) and a copy of the most current site build files.

Republishing can be slow. With a big site, it can take a while to re-publish the whole site. For small changes, this can be a bit annoying as every file must be republished even though only one file needs to be updated.

Handing off files to a 3rd party requires more strategy. Because the publish process is a one way street you need to decide on how to manage editing the generated pages after delivery. If you just deliver the exported HTML, and a 3rd party edits it, you can't easily go back into the static generator files and make more updates yourself, you would either need to reverse migrate the content updates by hand, or switch to editing the HTML directly. The other option is to deliver all the static generator code, templates, content files, and documentation for the 3rd party to continue using the static generator system.

I'm admittedly not as familiar with the CMS side in this regard but one thing I've noticed with these static generators that might be a dis-advantage is the tendency to fall in one of two camps; the overly specific, or the overly general. The overly specific ones tend to be very good at one thing but pushing them outside of their intended use case proves difficult or seems like a bit of a hack. Jekyll for instance is very good for blog posts or dated entries, but seems less well suited for a more complex sites. On the filp side, the overly generalized try to make "anything possible" often come with a much more complicated configuration process and a steeper learning curve.

Some things to consider, or opportunities to innovate:

Consider how often your content is going to be updated and who is going to be updating it. If it's not very frequent and someone with a bit of development skills is available to do the publishing then a static site could be a good fit. If you need lots of people to be able to update content from wherever they are without any development skills a CMS would likely be best.

Cost differences. Generally speaking, a static site would be cheaper to build however it would be more expensive to update. Again, depending on the frequency of updates, one may be better than the other.

It could make sense to just use it as a development tool and not as a long term management tool. Developers like using tools that make managing large projects easier or more automatic. Tools like this come with great opportunity to write once and include everywhere because of the powerful tempting. It might make sense to just use a system like this during development, hand off the generated site, and allow the client to just edit the HTML as needed. Again, it’s a one way street; once that HTML changes, there's no bringing it back into the development environment without a lot of manual work updating the content.

It’s not hard to imagine that a static generator site could easily be migrated into a CMS-based system. Since they are both essentially based on a store of page data being applied against page templates, one could argue that it could be a relatively easy task to migrate into a more robust CMS as the project grows and demands more frequent updating.

It’s interesting to think about how these tools could evolve and combine best of both worlds. There are certainly options out there for exporting CMS sites to static files for the speed benefit, but there are equal opportunities to build up tools that would allow these generation tools to run on the server with some client facing UI that exposes certain files and can run the publish script on the server.

Comments

  • Dan Mall says:
    Posted: 03.19.12

    Loving this idea. This is why I ran Movable Type 2 on my site for so long: all the benefits of the dynamic site mixed with the niceness of static files. Glad to see this idea coming back around.

  • Cameron Rickersey says:
    Posted: 03.19.12

    Is definitely a place for light page generators. Especially for smaller clients who don't have a big budget, and have the perseverance to make there own changes knowing that it will same them on-going costs to make updates.

  • Jarred Bishop says:
    Posted: 03.19.12

    I'm also really liking jekyll at the moment. Paired with pages.github.com it's fantastic for simple site development.

  • Austin Bales says:
    Posted: 03.20.12

    Pairing a static site generator with a well-prepared deployment environment could take this to the next level. Provision your server instances (be it VPS, EC2, etc) with the tools required to compile your site, and have all the compilation run in the production environment as part of the deploy process. If the compilation succeeds, the site is deployed – else it rolls back. You could also go with an environment like Heroku, that offers fine-grain access for deployment, releases, and a flexible asset/compilation process. The opportunity for scale and speed increases greater when you include more advanced tooling like Sprockets in your compiler, giving you that chance to distribute your static assets automatically on CloudFront (or whatever CDN). Glad to see you guys playing with this stuff!

  • Fabien says:
    Posted: 03.24.12

    well ... I'll second Austin Bales on all the Cdn point. If i could add my 2cts, we should keep in mind that html markup generation is not the bottleneck anymore.. Lets face it : webfonts, heavy dom documents, javascript enhancements, social plugins integration, google analytics really mess up the user experience.

  • Michael Ruescher says:
    Posted: 10.01.13

    Definitely check out BitBalloon. http://www.bitballoon.com It's a static site hosting service that automatically optimizes your static assets and serves them via CDN with far future caching headers. It' so much easier to deploy than S3, you just drag & drop a site folder onto bitballoon.com There's also a "site aware" API that does all kinds of cool things like make your forms work. I'm one of the core team members building BitBalloon and would love your feedback!

Want to say something?

Your comment may be reviewed by a moderator for approval.

Senior Developer Lv2

  @peteschirmer

Tags

WANT A REGULAR DOSE?

subscribe

Same Team, New Name

It's been thirteen years since we started Odopod.

We've always wanted one thing: to do the best work of our lives. Along the way, we have been joined by an eclectic and exceptionally talented bunch of people who wanted the same thing. Together, we've built a company we love.

Two years ago, Odopod was acquired by Nurun.

The acquisition was a validation of everything we had built. It was also a catalyst for some big changes we wanted to make. We began to tackle bigger, thornier problems and to work all over the world. With Nurun, we've had a series of huge wins and have been producing our best work yet.

That's why we recently decided to retire the Odopod brand, formally adopt Nurun as our name, and take the reins of Nurun's US operations.

We're all still here—same team with the same appetite for great work, only now with different e-mail addresses and more frequent flyer miles. And we're growing, so send your talented friends our way.

Keep an eye out for new work from Nurun. It will be our best yet.

Tim, Dave, Jacquie, JT & Guthrie


The best way to reach us

For new business, contact Stacy Stevenson
stacy.stevenson@nurun.com

For general inquiries, contact us at
sf@nurun.com

For more about Nurun, visit
www.nurun.com