MakeStaticSite

Alternatives

MakeStaticSite is built around well-established tools for website archival, primarily Wget, and tailored for existing sites. Its approach might be described as classical; it is by no means the first Bash script to generate static versions of WordPress sites using Wget. See, for instance, WP-Static, though that repository was last updated in 2015 and is now archived. Similarly, for Plone there is Static Plone, which includes support for Plone authentication.

However, MakeStaticSite extends the classical approach by repurposing archives for live delivery within a broader web publication workflow. In this scenario, there isn’t a direct alternative to MakeStaticSite, though Wget2 and HTTrack should both be considered as perhaps more capable mirroring engines, to be incorporated in future development work.

On the other hand, modern approaches are generally more forward looking, pushing ahead with new ways to create websites. They are strongly driven by the goal of separation of data from presentation, characterised by data sources and templates, controlled by markdown, utilising components and functions, and APIs. This is commonly termed the Jamstack architectural approach to site development, which we’ll discuss in its more accepted sense in the next section.

Going headless

As a bridge between existing and future systems (a kind of halfway house), ‘headless’ solutions are offered, particularly for WordPress. This means that authors can continue to prepare and maintain content using the familiar CMS user interface. However, the delivery of web pages to site visitors is no longer carried out by the CMS, but by a separate mechanism, which is essentially what makes this arrangement headless. (Another term for this separation is decoupling.) In this sense, MakeStaticSite can be viewed as a headless solution for WordPress or indeed any other CMS; and where the CMS provides a command-line interface (CLI), optimisation of the static output could be developed as with MakeStaticSite library, mod-wp.sh.

However, instead of using Wget to generate the mirror, for a CMS, it may make more sense to use a native tool, which in the case of WordPress is in the form of a plugin. This grants proper access to the site’s architecture and can also offer hooks that refine the output during and after site generation. Examples include Simply Static and WP2Static (repo on GitHub; introductory talk), which supports the entire lifecycle from content authoring to publication (see, e.g., its deployment options). A hosting platform, including CDN, can then be selected, as described for WP2Static and Netlify.

The downside to the native CMS solution is that continued usage depends on ongoing maintenance to ensure it works with system upgrades. In the case of WordPress, that means new PHP versions, WordPress Core, etc. Unlike Wget binaries, the tool is typically the work of an individual or a small team, and these tools often fall by the wayside, as happened with StaticPress.

More robust support is available through paid services, usually hosted services, where you log on to manage content as well as publish the static versions. For example, HardyPress, which explains the distinction of their offering. Strattic is another service based on WordPress, which now employs Leon Stafford, the creator of WP2Static. As are Shifter and FLATsite.

These solutions also generally provide integration with third party services to incorporate additional dynamic components, such as search engines, contact forms, discussion comments and shopping carts. The coding involved is generally lightweight, typically embedding a chunk of JavaScript in web pages to make API calls. For some indication, see the code snippet for manually embedding Disqus comments. MakeStaticSite can actually be set up in a similar vein with WordPress sites managed behind a firewall configured with appropriate access restrictions, but this is only experimental, little tested.

For a developer perspective on WordPress and static sites, read the survey of Patrick Posner, the author of Simply Static.

More Flexible Templates and CMS Independence

Notwithstanding the above, Jamstack developers have been seeking to go beyond the perceived constraints of CMS themes. Whereas MakeStaticSite and static site generators largely echo the presentation choices in the original site, most headless CMS solutions provide a templating system in various languages such as React , Go and Vue as alternative, more flexible means to render views. To accommodate the headless case, they use the APIs provided by the CMS, which in the case of WordPress is a REST API, but the supported use cases are far more general. This perspective is promoted by Netlify (see the section ‘A seamless integration’), emphasizing how it is platform-agnostic, allowing leverage of frameworks according to developer preferences.

Indeed, the above-mentioned frameworks are numerous and it is standard practice to use them independent of any particular CMS, replacing the data source (typically SQL database) with static files hosted on, for example, AWS S3 buckets. This not only grants the developer far greater control over the templating design, but generally improves performance for building sites. However, with this leap, to continue working on an existing website requires carrying out a migration and subsequently – in most cases – different practices in content authoring. The standard means of writing posts is markdown, which is popular with developers. However, without an accessible GUI, this is probably an obstacle to greater mainstream adoption among non-technical writers.

What we’re describing is essentially the assumed Jamstack architectural approach to site development. In the original styling of JAMStack, the ‘J’ stands for JavaScript, ‘A’ for API, and ‘M’ for markup, where the process of building the site typically uses APIs such as REST, JSON, and React, to retrieve data to help assemble the markup, not only HTML files.

A few of the more popular systems include

Furthermore, there are continuous deployment tools, notably Netlify, that cover the entire lifecycle, from building and optimising static content to CDN deployment. These systems are designed to assist software developers in building static sites from scratch and help manage the entire process, allowing packages to be easily integrated and so on. They are a good fit for new sites, though this sophistication does come with a learning curve.

Conclusion

The landscape for the creation and maintenance of static web sites is very broad, though most attention is given to the latest trends, often leaving behind existing sites and associated authoring practices. This is reflected in indexes to static generators. As at 2013, there were a couple in particular, one hosted at staticsitegenerators.net and the other at staticgen.com, both merely referring to “static site generation” without giving a further explanation, which seems sensible given the diversity. Ten years later, the former reports a server timeout and the latter redirects to https://jamstack.org/generators/ . But, strictly speaking, that list is broader than Jamstack, so, again, Jamstack is being conflated with the more general area of static website creation.

As we have seen, there are bridges from the old database-driven CMS to modern static sites, in the form of headless solutions. Support for the full lifecycle is available, usually involving chargeable commercial services, where content is hosted remotely and at least some of the software used is not freely available. This means a loss of independence and control over the data. Although only a prototype, MakeStaticSite provides the means to work with many existing sites, whilst retaining individual control over the data and the build and deployment processes. In its support for workflow, a core component of modern continuous deployment approaches, it is somewhat forward-looking. At the same time, using Bash, a ubiquitous shell script, avails the website builder of a universe of tried and tested applications that the host operating system provides.

As this page indicates, there are many possible choices involved in determining a viable and effective workflow. Each content maintainer’s context is unique and will likely evolve, so it’s worth exploring a range of approaches and viewpoints — as offered in Tim Nash’s blog.

This page was published on 16 February 2023 and last updated on 21 February 2023.