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.
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.
We're still in San Francisco, still under the same leadership, still doing great work (here are some case studies). But now we're a lot larger. We've joined a host of Nurun offices around the globe, all part of Publicis Worldwide.
Our focus remains on helping clients succeed in a connected world with products and services that transform the consumer experience.
We continue to work with forward-thinking, longstanding clients including Tesla, Google, Sony and Audemars Piguet. More recently, we've established new relationships with Dolby, the San Francisco 49ers, GoPro, and Blu Homes.
We welcome the opportunity to work with you too.
Tim, Dave, & JT
For new business, contact Allison McCarthy
For general inquiries, contact us at
For more about Nurun, visit