I address the fact that the site, as it currently exists, doesn't need any of this currently. I tried to be clear in my "criteria list" that I'm designing for power and flexibility; I don't want to limit myself down the road.
I definitely could have verbalized my stance on headless CMSs better. I'm very aware that there are ways to use them without requiring two round trips. But in the very next paragraph I say "I want every page of my site to be pre-rendered to a set of fully static assets". The solution you allude to (a headless CMS with server-side rendering) requires a server and doesn't meet that criteria.
I also know you can do generate a static site with Next/Gatsby + a headless CMS that's integrated into your build step. I didn't do that way because it seemed overkill - I'm happy using my file system as my CMS.
You mention that I reject using "MD along with React". Which bit of the post are you alluding to? I do reject the idea of putting React components inside of `<script>` tags inside of a Markdown file. Based on my criteria, the "React + a sprinkling of Markdown" makes more sense than "Markdown + a sprinkling of React". Otherwise it's an uphill battle (with a fair bit of boilerplate) to use React Hooks, import styling libraries, etc.
I'm not sure I follow your logic w.r.t this being a damning condemnation of React. There a build step (either Babel or TypeScript) required to use cutting-edge React. That additional layer of separation is what makes it so hard to do React+TS inside of these Markdown-centric CMSs. I don't think that impedance mismatch reflects poorly on either React or the SSGs - they each have their uses.
Could you elaborate on the "other, simpler options even within the TS ecosystem"?
I think I misunderstood your comment about markdown and react together, I didn't get that you were referring to nesting them two levels deep like that. It makes more sense that that's a pain - for what it's worth, in my non-web content authoring I do a lot of embedding LaTeX in markdown and it can become a bit of a mess.
The boundary between a 'headless cms' and a 'static site generator' can get somewhat fuzzy. The approach that I usually take here, when it's less of a hobby project, is to use a full-featured-editor-included CMS and then aggressively cache the pages so that behavior is just delivery of static files in the 99% case. This is an extremely common pattern with WordPress, for example---I would never call WordPress a paragon of performance but it is quite fast with the commonly used caching plugin that essentially reverts it to a static site generator for common cases. It's even better to do the caching in a web server or other in-between layer which is generally going to be faster at shuffling files than whatever language your CMS is in.
When it comes to simpler options with TS, I would just write what you need in bare TS. That gets you the advantage of typing without the weight of a framework. It does make it more difficult (though of course not impossible) to rely on framework components but I don't feel that really need them in your use-case.
Finally, totally with you on relying on the file system as a CMS. In my case I actually use the file name verbatim as the post title, one of those things that seemed too simple to work up front but is actually basically fine. The only constraint is that "titles" (e.g. file names) must start with the date because I just sort them to order posts - this is all so that posts can just be plaintext files (or markdown files, but I stick to plaintext as a stylistic decision) without needing to be parsed for any kind of header metadata or something. It is a limitation but I'm pretty happy with it a self-imposed one.
I also, to be fair, have a bit of a negative gut reaction to React in this kind of situation. In my line of works (operations or, to be more fashionable, DevOps), I have had more encounters than I can easily count with "react apps that should be static files" and are significantly more complex to deploy and maintain than they ought to be as a result. There's nothing like fighting with the TypeScript compiler in the build chain for, well, a static file. I'd be less harsh on this if I hadn't also experienced so many cases of developers shrugging when it ends up doing something undesirable, because they don't even understand the React part of it all well.
I'm not really convinced that it can deliver faster development but I'm also not unconvinced. I am pretty convinced that it ends up adding significant complexity that can really bite you when you encounter what ought to be trivial problems, and there's such a large push towards "batteries included" frameworks in JS, combined with the very fast turnover in popular frameworks, that it seems excessively common for developers to be building on top of a framework that they don't really understand well (because they just learned it and it does a lot under the hood) and that just has rough edges to deal with (because it's relatively new). It's enough to make you a little bitter after growing up on Python and, of all things, PHP, where frameworks and libraries tend to stick around for a long time, most developers have longer background with the language and framework, and the build-test-deploy toolchains are generally simpler. Not necessarily easier to use, but simpler---these two do not necessarily come along with each other, see 'create-react-app' and its 'eject'... a solution that is easy to use but so complex that it has a tendency to explode when you look askance at it.
I address the fact that the site, as it currently exists, doesn't need any of this currently. I tried to be clear in my "criteria list" that I'm designing for power and flexibility; I don't want to limit myself down the road.
I definitely could have verbalized my stance on headless CMSs better. I'm very aware that there are ways to use them without requiring two round trips. But in the very next paragraph I say "I want every page of my site to be pre-rendered to a set of fully static assets". The solution you allude to (a headless CMS with server-side rendering) requires a server and doesn't meet that criteria.
I also know you can do generate a static site with Next/Gatsby + a headless CMS that's integrated into your build step. I didn't do that way because it seemed overkill - I'm happy using my file system as my CMS.
You mention that I reject using "MD along with React". Which bit of the post are you alluding to? I do reject the idea of putting React components inside of `<script>` tags inside of a Markdown file. Based on my criteria, the "React + a sprinkling of Markdown" makes more sense than "Markdown + a sprinkling of React". Otherwise it's an uphill battle (with a fair bit of boilerplate) to use React Hooks, import styling libraries, etc.
I'm not sure I follow your logic w.r.t this being a damning condemnation of React. There a build step (either Babel or TypeScript) required to use cutting-edge React. That additional layer of separation is what makes it so hard to do React+TS inside of these Markdown-centric CMSs. I don't think that impedance mismatch reflects poorly on either React or the SSGs - they each have their uses.
Could you elaborate on the "other, simpler options even within the TS ecosystem"?