The Static Site Paradox

I have whole rants about this, based on bitter experience trying to convince marketing people to stop using WP and just use a static site.

It comes down to ease of editing. A WP site optimises for the editor. Not the hosting, not the tech folk, not the accountants, and definitely not the reader. The people who edit the site get to say how it's implemented.

If you give them the choice (as I have) between a site that renders in <100ms, is completely secure, and costs literally nothing to host, but requires markdown files and a bit of Git to deploy, and a Wordpress site that's as slow as hell, costs a fortune, is insecure, needs constant maintenance, but has a nice editing process, then they go for WP every time.

I'm always confused as to why these particular people get to be the ones who make the choice. But I've repeated this experiment multiple times and it has always come back with the same result.

In 2016, I was working at an agency making brochureware for local businesses. I remember one of our clients wanted us to add a small iframe for a reservation system to their website they had built. They sent us a single word document. Turns out they were just exporting it as HTML (which it seems like Word does still support today!) and throwing it onto some cheap shared web hosting provider. It worked great for them. They could always keep their online menu updated because... it was exported from the word doc they create the print menu from. At the time we sort of made fun of them internally... which I feel bad thinking about now. It's actually a genius idea when you have a million other more important things to do at a restaurant.

It's still easier to make a static site. I think the authoring tools to generate HTML just currently suck, or if they don't suck they have some process that needs to run on the server to serve the site.

We’re dealing with this big time in Asheville now. When cell service came back at all, everyone had shitty intermittent 3G, and none of the websites we needed for basic survival information would load. A bunch of good people created some text only news sites, and today I noticed that the Buncombe county website finally has a low bandwidth site, but even then when I inspected it, it had 130k of bootstrap css and 50k of jQuery blocking rendering. It’s great that people are doing this work, but citizens needed this a week and a half ago. By now, I’ve figured out where to get water, food, non potable water, etc. Seeing tech fail so badly through all this has been eye opening for me, in a depressing way.

> the web doesn't belong just to software engineers. The more we make the web complex, the more we push normal users into the enclosures that we like to call social networks.

Big up this author. Here’s a recent podcast about the recent conference this quote came from (Squiggle Conf), https://changelog.com/jsparty/339

Most people's expectations of what a "basic website" should do have gone way up over time.

Even as a programmer, I've fallen into the static site generator trap a few times.

It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app.

Nowadays, if I want a static site I just start with a folder of html files. It's way less complicated and quicker to go from idea -> execution without bike-shedding or procrastination on tools.

I'm pretty happy writing html and css manually though—I don't recommend it for everyone.

The other cool thing is if I then decide to "abort" to rails.. I can copy the folder of html files into the rails public/ folder.. pretty easy upgrade path.

There is a complicating factor for a Web developer's personal Web site: resumé-driven-development (RDD).

For those professionals who try to use personal side projects for RDD, so that they don't have to sabotage as many employers' projects as they would otherwise.

Which leads me to this morning, for example... For an indie Web site I'm about to launch -- and for which I'm using a popular modern Web framework, mainly for RDD reasons -- I could no longer update my Web site.

Because an NPM package had a Critical security problem, and trying to get the update got NPM stuck with some interdependency conflict that couldn't be resolved automatically. (Which, ironically, prevented pushing the security update to the production site.)

The site could be 5 simple handwritten HTML files, one with a sprinkling of JS inline in it, plus 2 small Perl CGI scripts. And it would work perfectly for 25 years and counting.

Instead, it's 129 NPM packages, frequently needing security updates, and a large tree of cryptic source files (template fragments, TS configurations, handlers), just for the NodeJS part of the site alone.

But doing it the ridiculously complex way is something that professionals can't afford not to do. (For example, having Perl on your resumé would be the kiss of death for employability. The people who didn't throw away your resume for ageism reasons, would still think you must be an idiot for not doing RDD.)

The killer app of WordPress is comments. No SSG, almost by definition, allows comments; WordPress blogs almost always come with them built in.

If you want something like Hugo to really take off in the blogging sphere, all you need to do is create some good looking themes with comments. Figure that out at scale - maybe by using per-blog sharded SQLite, which you can host as a third party for pennies on the dollar - and you have a tiny golden goose on your hands.

I fit into that Paradox -- I rewrote my own personal website in modern PHP without a framework or database. It's mostly a static site but uses PHP to add headers, deal with lists (for blog posts), etc. I found it slightly more convenient to be not completely static. I can just write up an article, commit, push, and it's online. I found most static site generators to be far too complicated.

The code for a single page looks like this:

    <?php

    $this->title = "Blog Article Title";
    $this->shortTitle = "Title";
    $this->date = mktime(0,0,0,1,27,2024);
    if ($this->mode == PageMode::Meta) return;

    ?>
    <p>Raw HTML content here<p>

There is a router that automatically adds the site header and footer, and I can add a "_layout.php" file to a folder to add another level of layout for child pages. For blog list page, it just scans all the individual article files in the folder to create the index. That where that $this->mode == PageMode::Meta comes in -- it executes the code in each file (to get the meta data) and then exits before rendering the rest. It's not going to scale to a lot of content but I'll adjust if it becomes an issue.

The entire PHP code for my "framework" is only 4 PHP files (init.php, functions.php, Layout.php, and Page.php).

The advantage of being a developer is that you can use code instead of configuration or data. And you can use code to write content more efficiently.

The result (still quite incomplete) is this: https://www.codaris.com/

It’s not really a paradox when you consider the UX from the website owner’s perspective. Wordpress makes things stupid simple to do, even if it has way more overhead.

It’s only a paradox if you think the trade off is spending time configuring things. No, the alternative for most people would be to pay someone to set up their website.

If someone set up a WYSIWYG editor for Hugo that goes from domain registration to published site in a few clicks they’d make a fortune.

> When I published SuperHTML, I discovered that it was the first ever language server for HTML that reported diagnostics to the user. I wrote a blog post about it, it got on the frontpage of Hacker News and nobody corrected me, so you know it's true.

Probably because this is something most IDEs have been doing for years, before Microsoft came up with LSP.

> If you didn't know any better, you would expect almost all normal users to have [2] and professional engineers to have something like [1], but it's actually the inverse: only few professional software engineers can "afford" to have the second option as their personal website, and almost all normal users are stuck with overcomplicated solutions.

I am confused, the inverse would be that professional engineers have [2] and normal users have [1]. But then they write that almost no professional engineer can "afford" [2], so everybody seems to have [1]..?

The current state of web development engineering is largely the result of how startup economics have functioned over the past decade.

A startup's market value is often closely tied to its number of employees. From an investor's perspective, a company with 1,000 employees is typically valued much higher than a small team of 37 programmers — regardless of the revenue generated per employee, or even if the company isn’t generating revenue at all. This is largely because interest rates remained very low for a long time, making it reasonable to borrow investment funds for promising companies with large staffs.

However, those employees need to be kept busy with something that appears useful, at least in theory. I believe this is one of the primary reasons we see such complex solutions for relatively simple tasks, which sometimes might not require a large team of advanced web developers or sophisticated technologies at all.

There is no paradox at all: simplicity is beautiful but complexity sells. The author thinks that value come from realized utility. However, in most market segments, value came from perception. With complexity (even useless ones), you can boost perceived value. How do you impress people when all the greatness is under the hood?

I use several SSGs and wrote one myself. I still can't recommend any SSG to people willing to pay.

Even the last few points of their "simple" flow are overly complicated. Before all the CMS stuff, you created the HTML and CSS on files on your desktop using text editors or WYSIWYG editors like Front-page. You can render it just as easily from local files as on a dedicated web server. When you're happy with it, copy the files over SFTP to your server. Frontpage would even take care of that for you. The same flow still works fine today.

Around the dot com boom there were dozens of high quality desktop editors for making websites. All these hosted SaaS systems were just starting to become popular, meant to make it easier for non-programmers to make websites. But did it really? I don't think so. Now those systems are so complex that you need to hire someone to use them. Yet first year students in comp sci who didn't even have any programming background still write HTML and CSS by hand. Templates for WordPress are these complex programs, but a template for HTML and CSS can be as simple as a Hello World example.

I tried the SuperHTML on a hand-coded site of mine and it reported only one problem and that problem is incorrect as far as I can tell. It tells me that the `</html>` tag is never opened on an HTML 5 doc with a `<!DOCTYPE html>` opening tag. The author does say it's not perfect and I probably need to double-check my understanding just to be sure. In any case, it seems like a useful thing and I am also surprised I never thought it was missing.

For those who are like me and don't know the term, "a language server for HTML" is referring to the plugin that evaluates your HTML syntax. That might be a narrow explanation of the tool but that's the basic idea I got from trying it.

It might be useful and fun to setup an open and ongoing competition for the meanest and leanest way of doing web publishing.

Its not trivial to set up because the list of desired features must be agreed and there are legitimate variations per use case. So most likely it must involve several subcategories.

But somewhere between git, markdown, sqlite, python (or maybe go?) a bare bones linux server and the mighty browser lies our optimal set of solutions. With no more that absolutely needed lines of code, no more than absolutely needed user effort and cost, no more than absolutely needed power consumption etc, in other words our true digital publishing future :-)

This is an engineer's view of simplicity.

A normal human being is going to see something like a checkbox to enable comments as being amazingly simple.

This is what drove me away from static sites. It's actually more work because you have to be the one to do all the stuff.

Sure, there are a few options for hosting and generating the build, but when I tried, they were not that good, or had some issues, etc... Meanwhile, wordpress.com never disappointed, and has an app for iOS and Android that you can use to update stuff whenever you are - as long as you have internet, of course.

That's why nowadays I use Obsidian Publish. Of course, I could use Quartz or some other alternative for building a site from my obsidian vault but... none will just work out of the box, from your phone

I would never recommend someone making their first site use a static site generator or anything PHP or dynamic like that. Just make a simple html document in a wysiwyg editor and upload it to the server.

If you like WordPress and want to use it to create a static site, you can.

1. Run a local installation of WordPress on your PC. For one option, see localwp.com (no affiliation).

2. Use WordPress to design whatever website you want, using almost any WordPress plugins you want. Just don't make any calls for time-varying external resources!

3. Use one of the WordPress plugins for exporting a WordPress site as a static site, i.e. as a folder of files that you can upload to GitHub Pages, Netlify, Neocities, or wherever. For one option, see simplystatic.com (no affiliation).

Static sites are great until you need to have a contact form or want to add basic comments. Yes, you can deploy javascript that uses external services to add such functionality to static sites- but with a basic WordPress site, you get everything right out of the box.

> Don't you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself? Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.

I think the better word for this is "straightforward"; see the Mythical Man Month:

> For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice.

> Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.

> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps

Or you could just use publii, an office suite of your choice, or type bad html and css by hand, then pass raw files on very cheap hosting providers, enjoying a clunky, and sometimes ugly, "website".

The industry for this use-case works on looks and discoverability: the dichotomy of the WP big bloated piece of crap vs static clown generators stands upon having a pretty website which is also functional for Google. Any other alternative (like the builders or the directories) works the same but they also forfeit property of the site from client. It's just because these solutions are pretty for cheap, it's fast fashion.

The reason SSGs are primarily interesting to software developers is that the software architecture of the site is primarily interesting to software developers. Other people (both authors and readers) don't care how the pages are produced, they only care that the pages are there.

The author mentions that WordPress charges for everything, but after migrating off WordPress to a static site, I've found most of the features WordPress bundles together are, in total, more expensive when paid for separately. WordPress.com is $300/yr for a business account, which includes domain, newsletters, unlimited bandwidth, etc. The cheapest provider of blog->email newsletter for > 1k subscribers is already as expensive, not to mention the domain, netlify plan (or overages on the free plan!), a hosted comments service.

I'm not complaining, but after a certain threshold, unbundling is much more expensive.

> Find an SSG (or handcraft everything yourself)

I think this came a bit too late? Astro solves this well, there are other solutions too. From startups building webflow-like SSG platforms to frameworks like astro that requires basic markdown and html.

There are a number of sites I wouldn't consider using anything but a static site generator for, including marketing websites, blogs, docs, etc.

You can't beat "free hosting" on GitHub Pages CDNs and the reduced maintenance burden of not needing to monitor uptime of static sites, infrastructure dependencies, OS updates, etc. They can also be maintained by editing .md files from GitHub's UI

We use them everywhere we can and maintain a number for Free SSG project templates which include GitHub Actions to publish them to your GitHub Repo's CDN for free hosting.

All templates use the same markdown format and structure to edit content making them easily to move content across different SSG templates built with different tech stacks.

[1] https://razor-ssg.web-templates.io - C# Razor SSG for Marketing Websites/Blogs/Podcasts

[2] https://razor-press.web-templates.io - C# Razor SSG for docs

[3] https://press-vue.servicestack.net - Vue SSG for Marketing Websites/Blogs/Videos

[4] https://press-react.servicestack.net - React SSG for Marketing Websites/Blogs/Videos

Maybe I misunderstand, but this feels misdirected. As someone who's employed by "greedy clowns" (web development agencies I guess?), I continuously observe that people pay for what saves them time. Our entire profession is built on this premise. If you have a person doing interesting things, does it really matter if they write their own HTML or pay someone else to write it?

The web is turning increasingly monolithic entirely thanks to the modern social network conglomerate. That has nothing to do with the choice of technology.

> Whenever we fail to make simple things easy in software engineering

Mandatory Rich Hickey "Simple Made Easy" link => https://youtu.be/SxdOUGdseq4?si=IY8mWzR3C-ru5Das

"This keynote was given at Strange Loop 2011, and is perhaps the best known and most highly regarded of Rich's many excellent talks, ushering in a new way to think about the problems of software design and the constant fight against complexity."

Absolutely true, I tried to build a static blog, tried quite a few static blog generators, for each of them there was something I didn't like, ended up building my own on expressjs. Practically reinventing the wheel, by creating a website and a simple crawler with a few addons, that puts everything on Cloudflare. I assume the average Joe would go for the Wordpress solution, for very good reasons.

Imho, the big lie regarding static sites is that it's showcasing only part of the solution it fixes. In the end it does not reduce complexity, it pushes it away from your immediate attention span(it's serverless), either to building tools, browser and configuration files.

You still need to build it, pick a layout, maybe some plugins. That requires not only the time to do it but also infrastructure behind, to push changes. If you consider that, from the start till the end, there is the same amount of complexity around it. You still need to persist data, md files look more appealing, but in the end is a disk data store, and if you need to collaborate, edit, etc, you end up realizing why why databases were invented.

To conclude, I really like static sites for the reasons I didn't include here.

I find the WordPress / static duality in this thread amusing.

Various startups built solutions that snapshotted WordPress installs and put the snapshots on static hosting. Best of both worlds. The one I know best got acquired: https://elementor.com/blog/elementor-acquires-strattic/

> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps:

This doesn't explain the difference, why would you have to figure it out yourself is some other company could just as well sell all those services, just with an SSG?

Strongly agree. Wordpress brags as powering whatever % of the internet... but if youve ever taken a look at some of that PHP source code... yikes

Mind boggling to me such an overly complex system has such a large market share.

I'll take my Gatsby TypeScript React components / <<insert your favorite static site generator here>> any day

This opening statement is confusing due to being stated as an axiom. From my experience, the majority of IT engineers considers the opposite true:

> only few professional software engineers can "afford" to have the second option as their personal website

In the quote "second option" refers to SSGs. But likely most of us here, and surely most engineers I interact with, would use the word "affordable" to describe why the first option (complex CMS like WordPress) is generally AVOIDED. The post quotes "professional engineers" or "professional software engineers". And points at SSGs as an "unaffordable" solution over WordPress.

The basis for this blog posts are however, that setting up SSG is time consuming while WP comes with less strings. Scroll to the end of this blabber to see the strings.

WordPress is not really an option for "professional software engineers". Most of us would be ashamed of having our personal websites defaced or allowing an attacked to read our databases and change entries. The "pros" own their swolutions and are careful around what that ownership entails. YOLO-approach CMS foer the personal website is simply not an option...

It's due to man-hours required to secure all the underlying dependencies (PHP, database), problems related to managing multiple system services to make a personal website work (outside of caddy, nginx etc) and how compute-heavy using WP is. And how much more knowledge (and - again - time) one needs, to harden a WP website for heavy load. You know - the "hug" thing which is not a thing with SSG-generated stupid static HTML, CSS and JS files.

Or, maybe I'll just quote the nonsense... According do the author WP is better than SSG because it doesn't require one to:

    Buy a domain
    Find a hosting platform
    Configure DNS
    Find an SSG (or handcraft everything yourself)
    Learn how to setup a deployment pipeline

I haven't spent so much dopamine on decrypting few opening paragraphs of any blog posts in a good few weeks. This blog post was "unaffordable".

GH/CF Pages are only "free" if you have no/minimal traffic. Also, even that free tier will go away if you start popularizing it as a Wordpress alternative or make the barriers to entry lower. Let's keep it free, please

I chose the second option and I am really happy for it. I already had a server for my Nextcloud instance and adding one more Nginx reverse proxy to it was essentially free.

I didn't even use a framework and chose to just use libraries and implement the features only if I need them. Probably it took more than just using a framework but it's pretty minimal and I know all the parts of my toolchain. And I learned much more than I could learn if I used a framework.

A professional software engineer would never think of a static site as a personal website.

On the other hand, normal users don't have an understanding of static/dynamic site and which one to choose. It is entirely up to the non-greedy/greedy clowns to go for a complex CMS written in some programming language initially by themselves or a WordPress or HTML static site initially.

I think the author should have told whether this personal website is a static site or dynamic.

For a friend I made this: https://en.hayovasweets.com/

It’s mostly list of markdowns and images in folders. Everything else generates during deployment on GitHub:actions

It was simpler to show GitHub desktop rather than installing something like Wordpress machinery monster and spent hours to teach how to use it. Now the process is simple:

1. Create a folder

2. Put there markdown and images

3. Commit

There is no such thing as perfect software. Everything comes with tradeoffs. Except, of course, for mkdocs.

I know other people like jekyll or hugo or whatever, but I've never seen anything comparable to the simplicity of mkdocs. It has built in search for the entire site, nice looking nav, everything is markdown.

The best part though? Here's my "build pipeline".

$ mkdocs build

$ scp -r ./build <user>@dangerlibrary.com:/site

I love it.

Yes, static websites are great! I'm using Jekyll with GitHub - it's 100% free. I agree, though, there is a learning curve.

I agree: I've tempted the all-from-scratch way in pure html for my small web corner and well, I give up, it's simply too long to craft a modern website on basic html. I've tried an RSS-only corner but obviously it's not visible, ending up in Hugo/org-mode simply because it's ready made even if needlessly complicated.

This person seems to be suffering from the Curse of Knowledge. It’s unsurprising to me that non-technical users will gravitate towards the tools that look like what they know (packaged software with forms and buttons) instead of something that they’ve never once looked at (except perhaps in anguish).

Time for Joel Spolsky to bring back CityDesk: https://www.joelonsoftware.com/2016/12/09/rip-citydesk/

There is still not a censuses as to the definition of a static website. Is a website without a MYSQL database still static if it has JavaScript or php template include files? A pure static website in which each page has to be manually edited would be a headache.

Or people could find a middle ground and join

https://bearblog.dev

Simple, has text-focused CMS, lightweight and content generated is static. Plus, dev is a nice guy.

The same (pros use less, consumers pay for more) goes for internet connectivity. A techie knows he will never need or saturate more than, say, 200mbps. While a consumer will see the "200/500/1G" offer and opt for the middle.

Before there was WordPress, the most popular blog CMS was Moveable Type. It had a "generate static files" option. (I believe this is how Daring Fireball is still published today.)

Surely this is the "best of both worlds" answer?

If you cache the rendered content then almost all of the advantages of a static site go away, particularly if you are a platform and can amortize the infrastructure cost over all your users.

The Hacker News site is (a) "static" or (b) "complex"?

A case of irony?

Great article.

> Don't you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself?

> Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.

Exactly right.

CMSes like Bludit are a good option for users who want a simpler structure and a small footprint. Themes are still very limited though.

> normal users are stuck with a bunch of greedy clowns that make them pay for every little thing

Huh? You're not confined to Automattic or WP-Engine, there are tons and tons of regular web hosting providers with Wordpress and a bunch of other stuff included in a standard hosting package, you can use the free Wordpress, and you can self-host. That's the whole point of Wordpress being open source, and it's working as intended.

There's absolutely nothing wrong with the status quo around blogging.

Static site generators are used by technologists who want to tinker and check all the boxes in whatever Chrome's latest devtool benchmark tool is called. Which is fine too, good for you if that's what you like to do with your time! For "normies" (or SME's who just want to publish their web content and move on), there are more than enough options around.

Yep, definitely agree. I've started a couple sites recently and quickly found that while I was happy just generating them with an SSG and slapping them up online, as soon as I wanted to collaborate with others the SSG had to go right out the window in favor of WordPress. It's not that SSGs can't be collaborative, mind you, it's that it's far easier to give someone a limited-access login to a WP site and let them contribute articles than it is to try to teach someone who isn't a programmer how to navigate adding things to an SSG.

Consider what's needed for someone non-programmer-y to use an SSG:

* Download a copy of the repository and install the SSG tooling, then fire up the SSG in listening mode so they can see their changes. * Write out the Markdown for their page. Oh, hope you have short-codes in place for things like images-next-to-paragraphs, info callouts, common page structures (cards, hero blocks, buttons), and so forth. If not, either they'll have to pause and get you to work with them to have them implemented, or they'll have to figure out writing the templates required. Regardless, once the bits are implemented in the site the writer has to work in the arcane short-code format markup required to include them. * Now they've got their changes, they need to figure out how to stage them — either they need to zip up the whole working directory and send it to you to sort out, or they get to learn how to commit a pull-request to a Git repository.

I don't mind doing all of that — it's quite enjoyable to figure out, and I get the chance to structure things exactly as I like them. But trying to teach a theatre director accustomed to writing in Google Docs how to do all of that? Nope. Which then turns into, "here, I wrote this out in G-Docs — hope you can figure out how to turn that into a site page!".

I really do wish there were a better competitor to WordPress, something that offered the ability to lift the hood and customize more easily. There are some CMS front-ends to SSGs, but the last I checked they either were more "CMS" in the sense of "put stuff in database and this will render it" or they still weren't particularly user-friendly (or were abandoned).

I thought early web browsers were designed to not only view, but edit websites.

Guess that idea is long gone...

What are good WYSIWYG editors for static sites? Any recommendations?

Yet another attempt to rip up the web into extremes. In the option number 2, author is clearly trying to hide an elephant behind a curtain. Complex CMS written in PHP requires a web server, but for a collection of static HTML files this requirement is cleverly skipped?

Now when a new post added happens what?

#1. You log-in to admin panel and write a post. A row is added to the database, a worker subscribed to the table sends the row via websocket to every active visitor on the site. They download few hundred bytes of data and see the post immediately without needing to refresh their browser. If they refresh, they will get cached version of the app and data instantly, then fill in the missing post from the API.

#2. You either use SSG or you generate a new static HTML page by hand, specifically on a device which has a private key for uploading to the server. If you don't choose an SSG, then since Javascript is complex, scary and prohibited, you also change the main feed HTML to include a new post, you timestamp all the new stuff by hand, etc. You upload it to the server via ftp. Great, now new visitors of the main blog feed will see it. Active visitors will see it only if they reload the whole page (hopefully they don't load the cached version).

Being professional is not to choose an extreme. Being professional is to solve a problem, and to make the best tradeoffs possible when solving it. There are many different configurations which are somewhat in the middle of extremes provided in the post, and using any of them professionally is about using them right and fitting them to solve an issue.

You would expect all normal users, including professionals to distribute normally between your neo-web-luddite static NGINX+HTML+FTP solution and javascriptpunk2033 complex CMS.

Fixing the editor experience of static sites seem to be most important to me, maybe followed by having comparably good themes. Whenever I setup a new site or fix a broken site for friends, I always try to convince them to go to a static site. Nobody really knows what that is and how it’s different, ie. nobody cares - until they realize that they now need to write in markdown. Managing images is most painful. I also learned to not bother anyone with git and just let them copy to production.

> a big frontend component that loads as a Single Page Application and then performs navigation by requesting the content in JSON form, which then gets "rehydrated" client-side.

Huh? <confused-dog.jpg> Either the page gets rendered server-side and (possibly) hydrated client-side, or it gets rendered client-side (i.e. a classic SPA) but then there is no hydration.

Related: Blogging vs. Blog Setups

https://news.ycombinator.com/item?id=25240939

https://rakhim.org/honestly-undefined/19/

> And so, while we software engineers enjoy free hosting & custom domain support with GitHub Pages / Cloudflare Pages / etc

Oh come on! You don't really expect that to last, do you?

Learned back in 2004 that it's better to pay than to rely on free services. I pay for source code repositories, email, web hosting, etc.

Phenomenon acknowledged but

"normal users are stuck with a bunch of greedy clowns that make them pay "

Here we go again, software needs to be free as in beer and anyone that charges for software is the devil

"software engineers enjoy free hosting & custom domain support with GitHub Pages / Cloudflare Pages "

You get what you pay for buddy.

> ...the web used to be more interesting when more of it was made by people different from us

And there it is, beautifully distilled into one sentence.

The fix for this is GitHub Actions and GitHub Pages. That way you don't have to run any software yourself at all - the build process runs entirely on GitHub for you, and it's free as well.

I'm surprised I haven't come across more examples of people using GitHub Actions with static site generators like this. Ideally someone would share a GitHub repository template that comes pre-configured with a good static site generator which people could then use as a one-click starting point for their own sites.

I've considered building one of those myself but I tend not to use static site generators (I like Baked Data instead: https://simonwillison.net/2021/Jul/28/baked-data/) so I'm not a great person to take on that project.