4 ms·

The tech stack for my personal blog is a <100 line Python script that reads a directory of plaintext files and drops them into Jinja2 templates. It's longer tha

The tech stack for my personal blog is a <100 line Python script that reads a directory of plaintext files and drops them into Jinja2 templates. It's longer than it needs to be because I wasn't feeling like being clever when I wrote it, so to produce the RSS feed it just starts the whole thing over again with some copypasta from the first time around. I know that with some smarter use of Jinja I could eliminate that whole step and be <50 lines. It's really just a (bad) static site generator, it's just that every static site generator I've run into so far was way more complicated than I need and so it was faster to write my own with only the three features I want than to learn a big complicated tool. I guess I have mixed feelings here. It makes sense to invest time in a complicated setup for a personal website as a hobby project, and I am quite clear that I am not a software person so that's just not something that really interests me as a way to spend my time. Spending a ton of time "developing a blog" feels to me like it's just a big roadblock in the way of actually, you know, blogging. I acknowledge that a good part of that is personal preference. On the other hand... much of the post really concerns me. The author talks about React and TS like they're the only alternative to writing bare JS. Well, for one, there are other, simpler options even within the TS ecosystem. For another, the website doesn't really seem to have any behavior that requires JS, so I'm not sure why JS needs to be involved in the first place. The rejection of using MD along with React seems like... a damning condemnation of React? Is it really that hard? People tolerate that? The assertion that most CMSs require two round-trips to deliver the content speaks of someone who has not really seen the world outside of modern JS front-end... It would be very uncommon for a CMS in another language to require more than one round-trip, as the content is prepared server-side before delivery of any kind of front-end. I guess, if I am to be opinionated (which I certainly will be), my feeling is that the author should have spent their hobby time exploring the world outside of React rather than hammering what seems like a rather round peg into a rather square hole, and then presenting it as "ideal."

colinmcd 6y ago
Thanks for the measured response here. 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"?
- jcrawfordor 6y ago
  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.

colinmcd 6y ago

Thanks for the measured response here. 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"?

jcrawfordor 6y ago
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.