Web Design Blog

7 Reasons NOT to Use a Static Site Generator

7 Reasons NOT to Use a Static Site Generator – SitePointSkip to main contentFree JavaScript Book!Write powerful, clean and maintainable JavaScript.RRP $11.95 Static site generators (SSGs) are popular and offer many benefits, but this article discusses reasons why they may not be a suitable replacement for your content management system (CMS).
In my previous article, we discussed how your site could benefit from using a static site generator:

A static site is a collection of pages contained in basic HTML files. You could hand-write these in a text editor, but managing assets and repeated elements such as navigation can become problematic.
A content management system stores page content in a database and provides facilities to edit and apply themes. Management becomes easier at the expense of flexibility, performance, server requirements, security, and backups.
A static site generator is a compromise between using a hand-coded static site and a full CMS. You generate the full site once using raw data (such as Markdown files) and templates. The resulting set of files is transferred to your live server.
The term “Jamstack” (JavaScript, APIs, and Markup) is used in relation to static sites. It refers to the rise in frameworks, serverless functions, and associated tools which generate static files but allow complex interactivity to be added.

Popular static site generators include Jekyll, Eleventy, Gatsby, Hugo, and Metalsmith. SSGs are available for most languages; see StaticGen for many more.
SSGs appear to offer the benefits of both CMS and static worlds, but they may not be suitable for every project …
1. You’re On Your Own
You won’t get far using a static site generator without some development expertise. The process is more difficult than using a CMS, there are fewer resources, and you could struggle to find pre-built plugins and templates.
Contrast that with WordPress. A non-technical user may require installation assistance but, once that’s complete, they can edit a site and install one of the many thousands of themes and plugins available. They may not have the best bespoke website, but they’re running with minimal intervention.
2. Choice Paralysis
There are many static site generators, but even the most popular tools are used by a tiny proportion of the web community. You’ll need time to research, investigate, and evaluate the options. One of the first SSGs was the Ruby-based Jekyll but, while you don’t necessarily require Ruby expertise, it will help if you’ve used the language before.
There are many CMSs, but there’s one obvious choice: WordPress. It powers more than 40% of the Web, so help is abundant. Again, it will help if you have some PHP experience, but even a non-developer can create a reasonable website using off-the-shelf themes and plugins.
3. The Initial Setup Time
Creating your first static site will take time. You’ll need to learn the build process, and much of the template code will need to be developed. Deployment scripts may also be necessary.
Developing a custom CMS theme can also be complicated, but pre-built templates are available and assistance is easier to find. Further development may not be required following the initial installation.
4. No Administration Interface
Clients may be cautious when faced with a complex CMS interface. Asking them to create and edit a set of Markdown files may terrify many. You can make the process easier by perhaps:

using their existing CMS as an SSG data source, or
providing simpler workflows, such as editing Git-based files in StackEdit or Hackmd.io.

But this will further impact your initial development time.
5. Website Consistency
Static sites are flexible: anything contained within source content can be rendered on a web page. Users may be able to include scripts, widgets, or numerous undesired items.
A CMS can be configured to constrain the user. Content is normally bound to a database with specific fields, so administration panels prompt the user to enter a title, body content, excerpts, featured images, and so on. Even if the user enters something in an unexpected field, it won’t appear on the website unless it’s implemented within the theme template.
6. Managing Large Sites
Consider a website with thousands of pages, daily content publications, real-time breaking news, and dozens of authors in multiple locations. It’s possible to manage content using a static site generator, but:

Content editing and publishing can be more awkward. Editors may require access to the Git repository or shared folders rather than a simple web or app interface.
Real-time updates are delayed because the site must be rebuilt, tested, and deployed.
Build times can increase rapidly and deployment could become cumbersome.

Static site generators are perhaps best suited to sites containing no more than a few hundred pages with a couple of new posts every week. Automated build and deploy processes will be required, and you may reach a point where a CMS becomes a more practical option.
7. Server-side Functionality
Static sites are perfect for content pages, but the situation becomes more challenging when you require user logins, form filling, search facilities, discussion forums, or other server and database interactivity. Options include:

Adding a third-party, client-side component such as Angolia search or Disqus comments.
Creating your own server (or serverless) APIs which can be consumed by client-side JavaScript to add required features.
Generating pages containing