If I’m building a static site for a blog, I think the number one requirement will be stability of dependencies over time. I should be able to come back five years later and get it up and running without spending a day fixing all the broken things.
Given my experience with NodeJS, I do not think it meets that standard. I’d probably give Ruby a pass too.
Maybe something built on Rust or Go would be my first choice, since they build a single executable and don’t depend on a packaging environment to run.
I’m pretty happy with hugo and Netlify. I seem to be averaging a post a year lately, but my handful of shell aliases and locally installed static binary for hugo are working fine.
The only trouble I’ve had was that I used a theme as a git submodule and the author removed the upstream repo. Which just convinces me to remove even more dependencies.
I built a blog with Hugo back when it was new, then came back to it a few years later and Hugo wouldn’t run (some incompatibility between Go and macOS), updated Hugo, and everything broke because they’d changed so many things with e.g. theming. I did get it working again, but it took a while.
I tend to agree. I wrote up a really nice SSG setup I put together with Flask, Jinja2, and Markdown, and a super simple Flask plugin called Frozen-Flask (for generating static HTML from Flask routes), which one can easily vendorize.
The nice thing about Flask and Jinja2 is that they are completely ubiquitous as a web app and template framework in the Python community, and its maintainers have essentially declared the projects “done” (+/- the odd security fix). Thus, coming back to a repo built with this setup years later, stuff Just Worked.
Sometimes it’s best not to let perfect be the enemy of the good.
I have some projects on Vercel / Zeit that are 3-4 years old, no problems with them whatsoever. It does lock you in a bit but it’s not a big deal since you can always next export.
You’ve probably moved computers a few times since then. How much effort does it take to get the project up and running without the original dev environment? That’s my biggest concern regarding continuity.
Well, you need a UNIX-like machine, a server with bunch of headers and footers of indexes and atoms (which I have for my blog) then just have some processor (I did not have this setup since the 80s as I wasn’t back there nor Atom/HTTP was :), I said 80s for hyperbole’s sake and the fact that most of the setup is through basic ed commands and Bourne shell (not bash) syntax).
Ed sadly is less and less preinstalled in modern UNIX-like machines, but ed syntax has not changed for longer than majority of solutions here exist.
I believe that Lindy effect is a good guide for designing such projects (continuous). Would it work right when the internet began - in my case, except for rsync and markdown, which are both just variables for generating html, which could be replaced with something else.
I’ll be honest, I get the idea, but personally I am way more conservative (is that a right word for this) in building my blog. I do not get reasons why would this need to be so convoluted with dependencies on node, etc. but again, I am a UNIX madman. Anything can be easy on the eyes with your own choice of 10 or so lines of CSS.
On my blog everything is done by a shell script, again static, and also I manage to have a gopher site and a gopher atom feed.
I would hate on your page if it did not render in glinks, but as it does… whatever, it’s a blog - if it works and is readable on ereaders then its fine by me.
On my blog everything is done by a shell script, again static, and also I manage to have a gopher site and a gopher atom feed.
I had a look at the script – it seems awfully like it would drive on and potentially upload a partial or corrupt version of the blog in the face of the failure of any the commands that it runs?
Pipefail does not exist in dash(1). I take responsibility for my choices, and all the problems I’ve had with this setups resulted from my own laziness of not reading the specifications of the standards. Other than that, over past 2 years it has been a trusty and reliable setup that works both on http and on gopher.
Sure! I would venture, though, that this is one possible answer to why people might prefer a more complex body of software; e.g., if that software checks for and handles errors in all of the operations it performs which can fail, is structured to ensure the system only moves from one well-defined state to another, etc.
So why hamstring yourself to dash? To guarantee compatibility with a random /bin/sh should you ever port to a long dead platform? (Except Solaris of course, where /bin/sh wasn’t posix compatible anyway). Bash has been a de facto standard and available almost everywhere for decades.
It’s like we are from different planets. I run a little static blog myself, and I understood barely half of this. I’m from a completely different culture.
The original post gave me the same feeling. To me, that site looks like it’s written in very simple, plain HTML, without any interactivity or complex styling that would make it difficult or even onerous to write by hand.
It is, in fact, an artifact of an alien culture, produced by intricate machinery that I’ve never heard of.
I would do the same if it wasn’t for the math I want rendered statically. I use KaTeX for this (and remark to parse the markdown). I’m not a fan of node.js and javascript in general, but it’s fine for this purpose, I guess.
Wouldn’t it be better to use HLatex which would then have some sign character and just connect the output of two preprocessors into one nice single solution (I have no experience with HLatex though, just was looking of how it would be done).
I’m not familiar with HLatex and the only things I can find are packages to generate LaTeX files in Haskell, and to use Hangul (the Korean alphabet) in LaTeX. Neither are what I want.
(Not the most easy-to-read code, but the idea is that I use a regex to extract inline and display math to a separate array, and replace them by a signal character in the text. Then I process the array and the text seperately and replace the signal character by the entries of the array)
Yeah I understand, nothing wrong with a shell script if it does its job. I did think about doing something similar, not that barebones though, a generator like Zola maybe. That would produce an even smaller site but I’d still need to figure out where and how to deploy it. ci/cd, etc. This was basically the easiest thing I could do considering I do React for a living.
I just finished rebuilding my own blog. It was previously a Jekyll site, but I wanted something that required no tools (at the cost of some duplication) and would happily sit there for the next 5 years without needing my attention. It’s now just boring old HTML5/CSS with a sprinkle of JS, and it feels much better.
Huh this looks like a really convenient setup. My blog (if you can call it so, heh) is generated by ugly shell+awk combo I wrote. Everything is handwritten. It even uses a custom flavour of markdown. Basically I have directory with some 2020-06-06.md files, and a simple shell scripts load the markdown and build everything - the blog pages itself (which is just simple html file), index file (just a list of aforementioned blog pages), and very basic kind of javascript search (user can search via tags, without the need to have any backend).
I don’t need any setup, it’s just literally git clone away form working on any linux box, without the need to configure anything at all. And while the way the scripts are written, new features can be added easily (someone emailed me about lack of RSS, and I got it working from scratch, in awk, in under an hour), they get messy quick. And while I love the simplicity and that getting it work is possible under a minute (I use it for more things, for example for rendering my journal to html), I think like it’s slowly getting out of my control. I’ve thought of either rebuilding it in real programming language or switching to some static page generator. So thanks for this post!
Btw, consider using CSS prefers-color-scheme. It allows user to specify the preferred theme (light/dark), and lets websites adapt to the settings. It’s really convenient, not that hard to set up if you have sane CSS, and it boosts user experience a lot. All of my websites use this, and I am pushing pretty heavily when some site doesn’t use it. It is just great when you setup your OS to dark theme, and running applications as well as running websites instantly change their appearance to match the OS (and daytime).
I used Pelican for this website, and it works well. Generates HTML fast enough, and has automatic reloading through inotify. I edit/create posts in VIM or a markdown editor.
Using Node + CMS +
SEO stuff seems rather elaborate if you just want a simple blog - however I’m quite the minimalist.
Thanks for letting me know the link was wrong on the previous submission 👍🏻 Btw when you click “Fetch title” in the “Submit Story” form it deletes everything after the root /. Can I report that anywhere?
If I’m building a static site for a blog, I think the number one requirement will be stability of dependencies over time. I should be able to come back five years later and get it up and running without spending a day fixing all the broken things.
Given my experience with NodeJS, I do not think it meets that standard. I’d probably give Ruby a pass too.
Maybe something built on Rust or Go would be my first choice, since they build a single executable and don’t depend on a packaging environment to run.
I’m pretty happy with hugo and Netlify. I seem to be averaging a post a year lately, but my handful of shell aliases and locally installed static binary for hugo are working fine.
The only trouble I’ve had was that I used a theme as a git submodule and the author removed the upstream repo. Which just convinces me to remove even more dependencies.
I built a blog with Hugo back when it was new, then came back to it a few years later and Hugo wouldn’t run (some incompatibility between Go and macOS), updated Hugo, and everything broke because they’d changed so many things with e.g. theming. I did get it working again, but it took a while.
Ah, well, there you see my secret. I’ll just never update Hugo!
I tend to agree. I wrote up a really nice SSG setup I put together with Flask, Jinja2, and Markdown, and a super simple Flask plugin called Frozen-Flask (for generating static HTML from Flask routes), which one can easily vendorize.
https://lobste.rs/s/s91ry0/most_dynamic_static_site_you_ll_ever_see#c_jrzsib
The nice thing about Flask and Jinja2 is that they are completely ubiquitous as a web app and template framework in the Python community, and its maintainers have essentially declared the projects “done” (+/- the odd security fix). Thus, coming back to a repo built with this setup years later, stuff Just Worked.
Sometimes it’s best not to let perfect be the enemy of the good.
I have some projects on Vercel / Zeit that are 3-4 years old, no problems with them whatsoever. It does lock you in a bit but it’s not a big deal since you can always
next export.I mean my setup also fits the bill as it would have worked fine (except for markdown processor and rsync) in the 1980s.
You’ve probably moved computers a few times since then. How much effort does it take to get the project up and running without the original dev environment? That’s my biggest concern regarding continuity.
Well, you need a UNIX-like machine, a server with bunch of headers and footers of indexes and atoms (which I have for my blog) then just have some processor (I did not have this setup since the 80s as I wasn’t back there nor Atom/HTTP was :), I said 80s for hyperbole’s sake and the fact that most of the setup is through basic ed commands and Bourne shell (not bash) syntax).
Ed sadly is less and less preinstalled in modern UNIX-like machines, but ed syntax has not changed for longer than majority of solutions here exist.
I believe that Lindy effect is a good guide for designing such projects (continuous). Would it work right when the internet began - in my case, except for rsync and markdown, which are both just variables for generating html, which could be replaced with something else.
That sounds like an extremely boring solution that will probably outlive me ;-)
I’ll be honest, I get the idea, but personally I am way more conservative (is that a right word for this) in building my blog. I do not get reasons why would this need to be so convoluted with dependencies on node, etc. but again, I am a UNIX madman. Anything can be easy on the eyes with your own choice of 10 or so lines of CSS.
On my blog everything is done by a shell script, again static, and also I manage to have a gopher site and a gopher atom feed.
I would hate on your page if it did not render in glinks, but as it does… whatever, it’s a blog - if it works and is readable on ereaders then its fine by me.
I had a look at the script – it seems awfully like it would drive on and potentially upload a partial or corrupt version of the blog in the face of the failure of any the commands that it runs?
That could apply to any code and that is something you accept and suppose. That is why you have backups.
I guess? You might want to investigate the
errexitandpipefailshell options, is all.Pipefail does not exist in
dash(1). I take responsibility for my choices, and all the problems I’ve had with this setups resulted from my own laziness of not reading the specifications of the standards. Other than that, over past 2 years it has been a trusty and reliable setup that works both on http and on gopher.Anyways, I’ll
set -eas that does not hurt :).Sure! I would venture, though, that this is one possible answer to why people might prefer a more complex body of software; e.g., if that software checks for and handles errors in all of the operations it performs which can fail, is structured to ensure the system only moves from one well-defined state to another, etc.
So why hamstring yourself to dash? To guarantee compatibility with a random /bin/sh should you ever port to a long dead platform? (Except Solaris of course, where /bin/sh wasn’t posix compatible anyway). Bash has been a de facto standard and available almost everywhere for decades.
It allows for most compatibility in terms of code. It would run on ksh (and I use openBSD a lot in my setups) and on zsh and on bash.
It sounds like your answer is “because I like the challenge” which is perfectly fine, just be aware to yourself that it’s why you’re doing it.
It’s like we are from different planets. I run a little static blog myself, and I understood barely half of this. I’m from a completely different culture.
The original post gave me the same feeling. To me, that site looks like it’s written in very simple, plain HTML, without any interactivity or complex styling that would make it difficult or even onerous to write by hand.
It is, in fact, an artifact of an alien culture, produced by intricate machinery that I’ve never heard of.
What do you mean, in reference to what?
I would do the same if it wasn’t for the math I want rendered statically. I use KaTeX for this (and remark to parse the markdown). I’m not a fan of node.js and javascript in general, but it’s fine for this purpose, I guess.
Wouldn’t it be better to use HLatex which would then have some sign character and just connect the output of two preprocessors into one nice single solution (I have no experience with HLatex though, just was looking of how it would be done).
I’m not familiar with HLatex and the only things I can find are packages to generate LaTeX files in Haskell, and to use Hangul (the Korean alphabet) in LaTeX. Neither are what I want.
What you’re describing (using a sign character and merge the output of two tools) is basically what I’m doing: https://github.com/rubenvannieuwpoort/static-site-generator/blob/master/scripts/format-blogpost.js#L71
(Not the most easy-to-read code, but the idea is that I use a regex to extract inline and display math to a separate array, and replace them by a signal character in the text. Then I process the array and the text seperately and replace the signal character by the entries of the array)
Yeah I understand, nothing wrong with a shell script if it does its job. I did think about doing something similar, not that barebones though, a generator like Zola maybe. That would produce an even smaller site but I’d still need to figure out where and how to deploy it. ci/cd, etc. This was basically the easiest thing I could do considering I do React for a living.
I just finished rebuilding my own blog. It was previously a Jekyll site, but I wanted something that required no tools (at the cost of some duplication) and would happily sit there for the next 5 years without needing my attention. It’s now just boring old HTML5/CSS with a sprinkle of JS, and it feels much better.
That screenshot with the performance / acessibility / … score at the end, what tool is it from?
Lighthouse
Just wondering: What happened to putting some HTML pages on a web server?
Huh this looks like a really convenient setup. My blog (if you can call it so, heh) is generated by ugly shell+awk combo I wrote. Everything is handwritten. It even uses a custom flavour of markdown. Basically I have directory with some
2020-06-06.mdfiles, and a simple shell scripts load the markdown and build everything - the blog pages itself (which is just simple html file), index file (just a list of aforementioned blog pages), and very basic kind of javascript search (user can search via tags, without the need to have any backend).I don’t need any setup, it’s just literally
git cloneaway form working on any linux box, without the need to configure anything at all. And while the way the scripts are written, new features can be added easily (someone emailed me about lack of RSS, and I got it working from scratch, in awk, in under an hour), they get messy quick. And while I love the simplicity and that getting it work is possible under a minute (I use it for more things, for example for rendering my journal to html), I think like it’s slowly getting out of my control. I’ve thought of either rebuilding it in real programming language or switching to some static page generator. So thanks for this post!Btw, consider using CSS prefers-color-scheme. It allows user to specify the preferred theme (light/dark), and lets websites adapt to the settings. It’s really convenient, not that hard to set up if you have sane CSS, and it boosts user experience a lot. All of my websites use this, and I am pushing pretty heavily when some site doesn’t use it. It is just great when you setup your OS to dark theme, and running applications as well as running websites instantly change their appearance to match the OS (and daytime).
Dark mode is on my list, among other things, so I’m definitely adding that! Thanks for the tip 👍🏼
I used Pelican for this website, and it works well. Generates HTML fast enough, and has automatic reloading through inotify. I edit/create posts in VIM or a markdown editor.
Using Node + CMS + SEO stuff seems rather elaborate if you just want a simple blog - however I’m quite the minimalist.
Thanks for letting me know the link was wrong on the previous submission 👍🏻 Btw when you click “Fetch title” in the “Submit Story” form it deletes everything after the root /. Can I report that anywhere?
Fix your metadata. Or just remove the canonical line entirely; you usually don’t need it.
Oh I’d never remember to check that. Thank you!
I really like it. I might have a go at making a Jekyll theme based off your CSS.
Please do! It’s very similar to rauchg.com, I like minimal blogs and that one was the main inspiration for me. This one is also good yoshuawuyts.com .