The theory versus the practice of “static websites”

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern API for authentication & user identity.
  • - Learn 300+ open source libraries for free using AI.
  • Next.js

    The React Framework

    The link you posted from Gaeron uses the (now deprecated) pages router, directly supporting my argument.

    I did a migration from pages router to app router for my static-export project. Btw both are still present in v13, you can pick whichever you want, but long-term the pages router will be gone.

    With static redirect/rewrites I mean the feature in pages router where you put in the "redirect"/"rewrite" statement in your next.config.js. These will be respected and work in a static export environment. If you try to perform a static export using app router, it will error and tell you that you have to remove "redirect"/"rewrite" from next.config.js and it is no longer supported.

    Yes, you could use a middleware for redirects, but that is exactly my point: Middlewares do not work with static exports, they are middlewares for the server-side next server. Which is not present in a static export (and requires running your own server again, or use vercel's offering).

    The same holds true for shallow routing for static exports, it is a feature still present in pages router, but not in app router. There is a GH issue of a lot of users complaining about this, but no feedback from the maintainers whether this is planned to bring back:

  • incbin

    Include binary files in C/C++

    So here's the interesting part - we decided to build executables in a way that data in those executables could not be changed (makes sense since it's compiled and the compiled code runs on the machine, and for security reasosns).

    That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem.

    So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except it can change.

    Now, in a container, any changes made to data at runtime inside rhe container won't persist unless the container is given persistent storage.

    What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file.

    Just a musing but tangentially related to your "baked data" - basically, embedded resources in executables just embeds the encoded data right into an executable.

    For scripting languages, of course, we can just make a script file that contains a variable with the encoded data as base64 directly.

    For the latter 2, it's only good for relatively small static data of course, but it would be interesting to build tech that somehow lifted that constraint of executables.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • decap-cms

    A Git-based CMS for Static Site Generators

    Products like [decap CMS]( try to bridge that gap, but I agree that this space needs to be further developed. In fact I think there needs to be a bunch more work to allow mere mortals to use version control and branch workflows in day to day work.

  • isomorphic-git

    A pure JavaScript implementation of git for node and browsers!

    I think one big missing part still with static sites is how you host the CMS to edit it.

    Correct me if I'm wrong but Decap CMS (previously Netlify CMS) runs in the browser and makes reads/edits via GitHub which can then trigger rebuilds and deploys, but it still needs a small server/proxy I think because CORS stops your browser communicating directly with the GitHub API. Netlify hosts a GitHub backend that proxies requests for you but now you're tied to Netlify.

    GitLab and BitBucket will have the same issue I think:

    Is there a simple solution here with minimal configuration?

  • Lektor

    The lektor static file content management system

    Lektor CMS is sort of a prototype-ish thing doing this:

    It has (used to have? Can't find them on the site now) pre-packaged binaries that you would drop into a folder structure generated by the technically-minded person, and the content editor can simply click on that binary, which opens the backend of the CMS in the web browser, make changes and click deploy.

  • Publii

    The most intuitive Static Site CMS designed for SEO-optimized and privacy-focused websites.

    I haven't used it, but Publii[0] might be along the lines of what you're thinking of. I ran across it in a previous HN discussion, and it seems to be static site generator with a pretty user-friendly graphical interface.


  • vike

    🔨 Like Next.js / Nuxt but as do-one-thing-do-it-well Vite plugin.

    I agree and, as the author of vite-plugin-ssr[1], that's what I recommend to my users: go for static whenever you can.

    I think it's something every web developer should be aware of. Static is indeed a lot simpler than dynamic.

    I've wrote more about it over here[2] (SSG = static, SSR = dynamic).


  • WorkOS

    The modern API for authentication & user identity. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • sitepress

    Sitepress ruby gems

    I’ve been down this path enough times that I built, which lets you embed content in a rails app with features that are present in Jekyll, Middleman, etc. like Frontmatter, site hierarchy traversal, etc. It keeps content as files in the app/content directory, but when it’s time to pull data in from the Rails app for SEO, it’s all right there in the Rails app. There’s no “Headless CMS” crap to jump through.

    For me, this is another way of keeping everything in a monolith, and which requires a lot less context switching. If I’m building a feature and I want to create marketing or support content for it, it’s all right there in the same repo. I just create the markdown files I need, commit them to the repo, and I’m don.

    The thought of switching between a static content site or something like Webflow just seems silly. I think they only makes sense for huge teams.

  • rose

    a template for putting together super simple webpages (by usmanity)

    Recently, while talking to a friend who hosts her website on Wix, I noticed that she was using it as a portfolio website and I asked what wix-specific features she was using and her answer was "domain management" and this got me thinking...what if the steps were pretty straight-forward, could someone who is not a web dev or technical get a website up on github? So I started putting together a template that looks very similar to her website and also includes instructions on how to host it on Github Pages for $0/year versus what she is currently paying Wix at around $100/year. The template is here:

  • shite

    simple static html page generator in posix shell. (by henriqueleng)

  • ursus

    Static site generator for All About Berlin

    It's on A slightly older version is on pypi. It's been running for a few months now, but only for two websites.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts