Running your own blog in 2023 is still needlessly complicated, especially if you have any kind of taste. Social apps and networks are obviously the easiest options, but they’re geared toward vastly different things, and I just don’t trust their longevity. There are many options out there, ranging from WordPress and Ghost to static blogs to managed online platforms and Micro.blog. In fact, none of the options out there seem ideal to me – they range from mediocre to acceptable.
Totally agree on the seemingly unnecessary overhead. Just recently I was looking into platforms for starting a blog and was overwhelmed with the choices of which none really had a complete set of offerings. Having a feature comparison table or a guide for choosing the best service/platform for individual use cases would be nice.
In the end, I chose Ghost's lowest tier. While it is limited regarding the theme choices, I've found that you can customize the free standard themes via their code injection feature[1].
Ghost is also what I always recommend. With WordPress and Jekyll/Hugo, you'll fuck around with site setup way more than actually writing. Ghost is basically only good for actually writing. Pick a theme (plenty of them for ~$50, write. That's it.
Customizing themes is also super simple in my opinion, though I've never tried their shared hosting and am unfamiliar with limitations that come from that.
I think the problem with customizing Ghost themes is that you actually have to tinker with their code, most don't really have settings at the scale WordPress themes used to have.
But yeah, that's why I said that if you're OK with the workflow Ghost provides and at least one theme you should probably use it.
> Running your own blog in 2023 is still needlessly complicated, especially if you have any kind of taste.
Aside from taste being subjective, most of the tools mentioned are customizable. That is, you can tweak the markup and CSS to your own taste.
The post starts being concerned about aesthetics but then finishes with:
"Having the right tool certainly helps, but at the end of the day, what matters is what you write there. Focus more on the content and just ensure the process of writing and posting is simple enough."
Finally, time is money. Spending an added hour (or two) with a build process (or whatever) isn't savings at all. If Goal #1 is to publish then anything that gets in the way should be avoided.
There are some solid points made, but the argument is inconsistent.
Many people (including me) use static generation with a fancy build process because we find it fun, not to save time or money.
I honestly find it more fun to setup my blog than writing content for it... Which might be a problem. (And also explain all the blog posts describing a complex setup).
But fine-tuning these blogs or themes is actually the complicated part. That's what I had to do. But I know a bit of coding and wanted to try. Not a great option for regular people.
And it'd foolish not to say that at the end of the day writing is more important than having a blog that's just beautiful.
There's one niche option I haven't covered there called [Aegea](https://blogengine.me/), which looks good out of the box, but I can't really recommend it based on the way the author develops it: no roadmap, no community feedback, basically no support, yet has paid features.
I started my website and blog in 2021. I used Jekyll + github pages with custom domain. I didn't want to setup everything by myself, so I bought a Jekyll theme that I liked and customized it. I did it lazily, so it took me around 1 month to complete the whole process, including copying my old blogposts from Medium.
I just publish via blogger. In the past I have checked other options but I always spend more time looking for interesting ways to deploy content than writing content
I honestly think starting a blog in 2023 is exactly as easy as it was 2004 (the year he references), if you take the easiest route:
1. You pick a cheap shared hoster
2. You buy a domain and connect it
3. You download a PHP blog system, like Wordpress
4. You unpack the files into the webroot, configure the database (or use a blog system that supports sqlite, like Serendipity [which I develop for])
5. Pick a theme, install a minimal amount of plugins. Optionally customize the theme a bit.
6. Done.
Sure, going with a hosted offering looks easier, but you still have to manage things like your domain, interoperability and backups, so hosting it on your own gets easier very fast.
I do this, but without the database. I chose Grav[0] because of its flat-fileness, but at the same time I did not want a build process (I mean, why? why do I need to rebuild my blog every time I post?)
Put it behind a CloudFlare free tier. Been happy forever after.
I'm inclined to agree that Grav is a good choice, but it still has the exact same fault as other software out there, notably updates sometimes randomly breaking things in odd ways: https://blog.kronis.dev/everything%20is%20broken/grav-is-bro... (note: typically you shouldn't run software updates inside of containers due to their immutable nature and instead just run a newer version of the container, but if you're working with persistent volumes then there's also really nothing preventing you from doing so)
Of course, if you don't update it, you'll eventually run into security related issues, which is more or less inevitable whenever you expose anything with write access (even when it is technically protected by an username and password; our industry still keeps getting basic things wrong all the time), as opposed to fully static assets: https://blog.kronis.dev/everything%20is%20broken/grav-securi...
Personally, I will probably keep using Grav for the foreseeable future, maybe even some day carry over the theme customizations that I use as well as all of my content to a more recent version, but for now I'm stuck on a comparatively old version that's thankfully a bit locked down at the web server level. Don't get me the wrong way, WordPress will be even worse in regards to both updates and security, I've seen entire sites be brought down because of a single plugin needing an update that's no longer compatible with something else.
None of that is necessary. Nowadays common consumer web hosts allow you to install Wordpress with a click. Actually most of them provide specialized WordPress hosting that comes with WP preinstalled and with a lot of optimization. (most of them are managed).
Hm - Okay, you have a point there. My preferred hoster does not offer this, but many do, and if you don't want to go with a lesser known option that really is even easier. So the old way of hosting it with a shared hoster did improve, nice :)
Twitter is no blog. And with both you then later have to fight with the login/paywall. That's exactly what I meant: Looks easier in the beginning, but isn't after the very start.
I don’t know if you can still do this, but you used to be able to create public folders on Dropbox. Dave Winer ran a bunch of experiments serving a blog from a public Dropbox folder and IIRC, it worked great.
If you are already paying for cloud storage somewhere, you might be able to start by saving your writing to a public folder. Instant blog.
No, sadly Dropbox shut that down many years ago. First the ability to host from there, then the concept of public folders in general (they are behind an UI now).
1. What you use or wherever you host, make sure that you can export your content in either plain text or a universal format that can be used by another tool or host it yourself. In short, own the content and use whatever tool it fits your current situations and limitations.
2. Possibly, try to get a domain of your own, and preferably a `.com`. Point that to whichever server you use (if they don't allow you to point, that is a net negative). Keep pointing to the services that you keep moving as they keep dying. One day, you might just end up writing in plain HTML and (s)FTP into a folder.
3. If you are going to use images/audio/video quite a tad more than usual -- start using a CDN (pretty cheap and some are free these days). If those are hosted on https://cdn.mydomain.com, you can move your content wherever you want and those images, audio, video just works. I was able to change WordPress hosting providers in minutes because I don't have to move the static assets.
The one thing that drew me to micro blog was that it was a paid service.
But honestly, my blog there is not about “engagement”. I don’t really care if anyone reads it. It’s more of a personal journal to blog about the multi year, “hybrid digital nomad” life we started last year.
Lots of good options, but what in your opinion would make .net or .org a better choice than .com ?
While perhaps not as pervasive as during the 1990s, I still feel like most people are more familiar with / assume / default to ".com" than any of the others.
.systems wasn't one of the most affordable new gTLDs used for spamming but a lot of mail sites blocked or at least increased "SPAM score" for most if not all new gTLDs.
With .systems I would expect somewhat reduced inbox deliverability but with .icu, .xyz, .top, .live and similar, you can forget about egress email.
There's a problem with a national domain: people move. My .me domain is registered in 2009 (well, I know that it's a national domain) and I lived in three different countries since then with a permanent status in the current one and without plans to come back to my homeland.
CIRA's privacy policy is one of the reasons why I've stayed with .ca for my digital presence:
> The registrant name and administrative and technical contact information of non-individual registrants, such as corporations, is displayed by default. The registrant name and administrative and technical contact information of individuals, such as Canadian citizens or permanent residents is not displayed in WHOIS per the CIRA Privacy Policy. Generally non-individuals are public and individuals are private.
"Free domain privacy, forever", in GoDaddy's wording, seems fairly standard now. But really it's a spin: Since 2018, domain privacy is required by EU's GDPR in many instances. But pre-GDPR it was frequently an add-on, demanding additional payment. IIRC, there are some domains for which it is not available.
CA domains have had a privacy default for individuals since 2008. As someone who's received personal threats as a result of WHOIS info, I'd rather stick with the more certain option.
Seems like the biggest limiting factor for Hugo, Jekyll, and other SSGs is the need for a CDN for most images. Are there any free CDN services that are worthwhile?
There’s also the option to ask someone with skills and expertise to set something up for you.
Which is almost never taken into consideration as an option in this kind of posts.
I don’t think it’s hard to start a blog in 2023. It’s hard to start a blog if you have very strict requirements AND you want to do everything on your own without being a developer/designer.
There’s also the option to ask someone with skills and expertise to set something up for you.
It's an option, but it's a bad option. Setting up and running a blog is not a one off process. For things like Wordpress there are literally security patches. For most other platforms there are updates. Wordpress has auto-update but it can be flaky, especially if the site owner tinkers with things.
If you get someone else to set something up for you it'll either rot, or you'll be pestering them to update it for you.
If you don't have the technical ability to run something just pay for a service instead.
Well yes and there's also countless other options that are not wordpress that require very little maintenance.
And you can also simply ask someone every year or so to perform some basic maintenance on your site like we already do for countless other things in our lives.
> you'll be pestering them to update it for you.
Am I pestering my mechanic to perform maintenance on my car every year? No it's called work. It's his job.
I've been running a blog since '99. Started on phpslash, then slashcode, then Drupal for a loonnnnng time. I just recently moved everything to WordPress and I'm finding it mostly ok. It's not designed to do small, simple, easy, plain, but it gets the job done. I agree with this
"The most popular CMS in the world, and yet I just can’t stand its admin page."
There are some things in there I can't stand, but I said the same thing about Drupal and I used that for 15 years or so.
Shameless plug but I built a tiny unopinionated static site generator that is great for blogs. No toolchain or anything fancy, I just added RSS support too :) It would be my pleasure if someone wants to try it https://github.com/donuts-are-good/bearclaw
> a static site is a site with no fancy clicky things, signups, comments, just plain html
Technically I think you can have comments via some embedded widget. Each page is still static, but there's a script tag in there that embeds a widget into the page that gives you commenting, usually via some SaaS
I think Disqus was the big one for a while. There was one I saw recently that uses github as the auth provider, which was interesting
I have been thinking about the comments feature. It's like peas and carrots having comments on a blog. I have almost added them before, but didn't for fear it would sacrifice any of the simplicity - which led me to think about modules/plugins. I like the idea of plopping down a folder or zip that the Bearclaw binary then reads and incorporates. Maybe that's feasible, maybe it's not.
I'm going on a walk in a little bit and will give thought to a plugin system. Any ideas you have in mind?
I have now added plugin support. This week I will write some sample plugins and then make a gallery for people to see them. Thanks for the inspiration!
This looks fantastic! I was going to mess about with Picocms but going to try this instead in conjunction with either Caddy or a spare shared hosting I’ve got laying around. And for the composing I will either tack on staticcms, or spin up a fly.io instance of stackedit (which I will push my md’s/edits from there to GitHub and bearclaw). You were trying to keep things simple and here I go trying to complexify it lol..
I’ll try to remember to let you know how it turns out after I get it all going..
oops Sorry about that. I just purchased the domain and stuck it there then promptly fell asleep. I'll remove it for now and then route it to a bearclaw page when I get done working tonight.
Figured something like that. And also for the md files. Just straight up content in there and no frontmatter or anything right? (May not even be a thing for md files, not sure)
Essentially what's happening is it takes your markdown content then converts it to HTML, then it puts the header above and the footer below. Those are held in `./templates` if you want to modify them. You don't have to include anything in your markdown other than the content, if I'm understanding your question correctly.
Also, one thing I'd like to sort out is making the page titles on the pages.html page that it generates not be based on the filename, but on the title of the article so-you-dont-see-stuff-like-this on pages.html.
As of yesterday since I added config variables, I'd like to relocate those to an external file to avoid recompile, and then use those to populate the header so that people don't take time to fill in the config and then still get "Bearclaw Blog" when they fire it up.
I really appreciate the time you're taking to talk this out with me, it's very inspiring and I'm getting lots of ideas. I can't wait to get done with Job 2 today so I can hammer out some of these things :) Thank you
Thanks! I ask myself often when I have ideas if it will maintain the simplicity or make it less out of reach for regular people. Please do let me know if you end up making a blog with it. It'd be cool if I could put a list of examples in the readme so that people can see what others have done with their bearclaw blogs
For the combination of Hugo and GitHub Pages, images are pretty effortless as well. For example, for a post with a path of `content/posts/post-title.md`:
1. Add the image at `content/posts/post-title/image-name.png`
2. Add markdown that references it, like ``
Part of the reason I use Hugo is because it's so low friction — the hard part is the writing (and writing consistently), and keeping everything else easy is key.
I'm not familiar with Jekyll, but if I recall correctly it's very, very similar. I just happened to pick Hugo at the start and haven't revisited the decision since, as it's tangential to the actual writing.
Hugo is much faster thanks to the fact it's written in Go. The approach by itself is the same. Also, seems to have one of the most active communities among blog-focused static generators.
I found that Hugo requires a shift in asset organization in the sense that assets are collocated with posts. If your post has three images, those images are in the same directory as the post markdown.
Jekyll keeps assets separated. Your posts live in _posts. Your static assets live together in a different directory.
I briefly experimented with switching from Jekyll to Hugo, but had too much invested—custom plugins and reliance on existing Jekyll plugins—in the Jekyll ecosystem to make the switch worthwhile.
From its repo: "Pagefind runs after any static site generator and automatically indexes the built static files. Pagefind then outputs a static search bundle to your website, and exposes a JavaScript search API that can be used anywhere on your site."
I don’t want to force JavaScript onto my users and wrote my own full-text search for Hugo that is skinned with your Hugo theme for a seamless look (only the URL changes):
Well, true, but:
1. You might want to resize image if it's a photo
2. You might prefer a CMS to a plain code editor and then you need to use its uploader (both Forestry and NetlifyCMS aren't very seamless)
3. Try doing that on mobile
Netlify CMS is dead[1] after the core dev left the company, Forestry is also officially dead as of April this year. Netlify CMS got forked into StaticCMS and the team behind Forestry have created TinaCMS. After experimenting with both last week, I recommend the latter if you're building a blog with Astro and want a Git based CMS.
TIL. There's a bug with the text editor where cursor will jump towards the last line. Really annoying and I think it's still not being fixed yet. Had to scour through Github issue to find the fix.
A lot of expected pessimistic HN comments that seem to miss the point here. I think SSG's are pretty damn good, I use Astro. People seem to think that SSG's forces you to use markdown or something, they don't. It's literally a mechanism where content from somewhere is turned into static pages. You can even use Wordpress and it's API as the source of the content for a SSG.
In my case I use MDX, which is Markdown that allows components (eg React) to be embedded. This is great for interactive content, articles with charts, visualisations, etc.
With something like Astro you can use React (or others, even vanilla) components that can either be fully server rendered, or sent to the client. With that you can allow people to post comments. As for how to render them, depends a bit on what you decide. You can either have comments displayed the next time the site is built, or you could have a posted comment trigger a build, or some other similar idea.
Thanks for posting! I update that blog post regularly to keep up with all the possibilities. Ironically, I decided to remove the comments from my own blog a few years ago. Comments still reach me, though, mostly via email.
I want to start my own blog but the vast number of choices overwhelms me. Deciding between Astro/Hugo/Jekyll right now. Can anyone share their experiences if they have built their blogs using these tools?
Yeah, seems like the way to go here. To get something up and running first and then deciding if a different and shiny tool really would make much of a difference.
I haven't tried Astro, but I moved my blog from Jekyll to Hugo.
I did it because I remember having issues with jekyll installation from time to time, like it suddenly broke out of nowhere, and trying to fix it became a pain.
Then I looked for alternatives and found Hugo, changed the template and installed in all my systems (Windows, Linux, macOS) and it has worked like a charm. Also, the speed boost was super noticeable, like, several times faster.
So if I were to choose again between Jekyll and Hugo, I'd go with Hugo.
I want to do the same and integrate it with my existing hobby e-com website. I was thinking of finding something that just turns markdown into HTML and using that. On the other-hand, a wysiwyg editor would be nice. I have no desire to use something heavy like wordpress or anything that requires a database. My little e-com website has no database backend which i'm kind of proud of :)
edit: on the third hand... i need a place to practice and stay in shape with full stack dev as i'm more of a manager/therapist these days. So maybe something from the ground up is in my future
Exactly my problem. With what you've described, I think Astro + some headless CMS would be the way to go here. I say Astro because having JS is a nice thing and it will let you do things that would require more effort with Jekyll/Hugo. (since you say want to integrate with your existing hobby e-com website)
Plus, it has the added benefit of keeping your front-end skills upto date.
I've been using Jekyll for a nuclear education site for many years, after doing it for even more in just manual text-edited HTML. It's great, and I'm impressed with all the little things I can do with it, such as highlighting the current page in the menu and having little back/forth buttons from page to page. No complaints.
I also use self-hosted WordPress for a hobby blog and like the graphical editor and easy drag drop of images.
Honestly, the overwhelming number of tool choices and themes is the biggest hurdle these days.
I will shamelessly plug my solution: md2blog. You just plop Markdown files into folders and it does the rest, without letting you get distracted by themes.
Edit: addressing the article, md2blog does not support email subscriptions, but it does generate an Atom feed. It also requires using a command line (but the tool is a single binary, so no installation or dependencies to deal with).
Jekyll is more oldschool. For me, Hugo seems to have a more active community and gets a lot of points for being a static binary (basically never fails and compiles very quickly). Haven't used Astro.
I moved from jekyll (to hakyll) to hugo years ago since I found working with Ruby and its libraries slightly annoying and Hugo (packaged as a simple binary) more straightforward to use.
That said, I haven't updated my blog in years, and at this point I'm not sure I still know how to! But the good thing about a static site generator, is it just sits there in S3, costing me just $0.14/month.
I migrated from Jekyll to Astro a few weeks ago. It only took me a few hours to replicate the site, more or less. Here's the website and the post about the experience.
One thing I value the most is the combination of markdown and latex support, plus mermaid diagrams. It’s very hard to find something that works super well on everything. Right now a customized Hugo with KaTeX is the best solution, but I’m still sad I cannot use MathJAX :((
256 comments
[ 2.6 ms ] story [ 328 ms ] threadIn the end, I chose Ghost's lowest tier. While it is limited regarding the theme choices, I've found that you can customize the free standard themes via their code injection feature[1].
[1]: https://www.shmostert.com/customize-standard-ghost-themes/ (disclaimer: the guide is from my blog)
Customizing themes is also super simple in my opinion, though I've never tried their shared hosting and am unfamiliar with limitations that come from that.
But yeah, that's why I said that if you're OK with the workflow Ghost provides and at least one theme you should probably use it.
Aside from taste being subjective, most of the tools mentioned are customizable. That is, you can tweak the markup and CSS to your own taste.
The post starts being concerned about aesthetics but then finishes with:
"Having the right tool certainly helps, but at the end of the day, what matters is what you write there. Focus more on the content and just ensure the process of writing and posting is simple enough."
Finally, time is money. Spending an added hour (or two) with a build process (or whatever) isn't savings at all. If Goal #1 is to publish then anything that gets in the way should be avoided.
There are some solid points made, but the argument is inconsistent.
I honestly find it more fun to setup my blog than writing content for it... Which might be a problem. (And also explain all the blog posts describing a complex setup).
Some people do this and won't admit it!
And it'd foolish not to say that at the end of the day writing is more important than having a blog that's just beautiful.
There's one niche option I haven't covered there called [Aegea](https://blogengine.me/), which looks good out of the box, but I can't really recommend it based on the way the author develops it: no roadmap, no community feedback, basically no support, yet has paid features.
1. You pick a cheap shared hoster
2. You buy a domain and connect it
3. You download a PHP blog system, like Wordpress
4. You unpack the files into the webroot, configure the database (or use a blog system that supports sqlite, like Serendipity [which I develop for])
5. Pick a theme, install a minimal amount of plugins. Optionally customize the theme a bit.
6. Done.
Sure, going with a hosted offering looks easier, but you still have to manage things like your domain, interoperability and backups, so hosting it on your own gets easier very fast.
No need to worry about points 3 and 4, and very little to do for 5.
Backups can be a simple git push.
Put it behind a CloudFlare free tier. Been happy forever after.
--
[0]: https://getgrav.org/
I'm inclined to agree that Grav is a good choice, but it still has the exact same fault as other software out there, notably updates sometimes randomly breaking things in odd ways: https://blog.kronis.dev/everything%20is%20broken/grav-is-bro... (note: typically you shouldn't run software updates inside of containers due to their immutable nature and instead just run a newer version of the container, but if you're working with persistent volumes then there's also really nothing preventing you from doing so)
Of course, if you don't update it, you'll eventually run into security related issues, which is more or less inevitable whenever you expose anything with write access (even when it is technically protected by an username and password; our industry still keeps getting basic things wrong all the time), as opposed to fully static assets: https://blog.kronis.dev/everything%20is%20broken/grav-securi...
Personally, I will probably keep using Grav for the foreseeable future, maybe even some day carry over the theme customizations that I use as well as all of my content to a more recent version, but for now I'm stuck on a comparatively old version that's thankfully a bit locked down at the web server level. Don't get me the wrong way, WordPress will be even worse in regards to both updates and security, I've seen entire sites be brought down because of a single plugin needing an update that's no longer compatible with something else.
If you are already paying for cloud storage somewhere, you might be able to start by saving your writing to a public folder. Instant blog.
2. Possibly, try to get a domain of your own, and preferably a `.com`. Point that to whichever server you use (if they don't allow you to point, that is a net negative). Keep pointing to the services that you keep moving as they keep dying. One day, you might just end up writing in plain HTML and (s)FTP into a folder.
3. If you are going to use images/audio/video quite a tad more than usual -- start using a CDN (pretty cheap and some are free these days). If those are hosted on https://cdn.mydomain.com, you can move your content wherever you want and those images, audio, video just works. I was able to change WordPress hosting providers in minutes because I don't have to move the static assets.
edit: added the 3rd point.
https://kevquirk.com/micro-blog-is-still-confusing/
But honestly, my blog there is not about “engagement”. I don’t really care if anyone reads it. It’s more of a personal journal to blog about the multi year, “hybrid digital nomad” life we started last year.
.net .org .me .io .blog .info
You can make it topical too .expert .engineer .doctor .camera .software
Or have fun with it .lol .wtf .foo
While perhaps not as pervasive as during the 1990s, I still feel like most people are more familiar with / assume / default to ".com" than any of the others.
With .systems I would expect somewhat reduced inbox deliverability but with .icu, .xyz, .top, .live and similar, you can forget about egress email.
> The registrant name and administrative and technical contact information of non-individual registrants, such as corporations, is displayed by default. The registrant name and administrative and technical contact information of individuals, such as Canadian citizens or permanent residents is not displayed in WHOIS per the CIRA Privacy Policy. Generally non-individuals are public and individuals are private.
https://www.cira.ca/ca-domains/whois
CA domains have had a privacy default for individuals since 2008. As someone who's received personal threats as a result of WHOIS info, I'd rather stick with the more certain option.
Which is almost never taken into consideration as an option in this kind of posts.
I don’t think it’s hard to start a blog in 2023. It’s hard to start a blog if you have very strict requirements AND you want to do everything on your own without being a developer/designer.
It's an option, but it's a bad option. Setting up and running a blog is not a one off process. For things like Wordpress there are literally security patches. For most other platforms there are updates. Wordpress has auto-update but it can be flaky, especially if the site owner tinkers with things.
If you get someone else to set something up for you it'll either rot, or you'll be pestering them to update it for you.
If you don't have the technical ability to run something just pay for a service instead.
And you can also simply ask someone every year or so to perform some basic maintenance on your site like we already do for countless other things in our lives.
> you'll be pestering them to update it for you.
Am I pestering my mechanic to perform maintenance on my car every year? No it's called work. It's his job.
> a static site is a site with no fancy clicky things, signups, comments, just plain html
Technically I think you can have comments via some embedded widget. Each page is still static, but there's a script tag in there that embeds a widget into the page that gives you commenting, usually via some SaaS
I think Disqus was the big one for a while. There was one I saw recently that uses github as the auth provider, which was interesting
[1] https://cactus.chat/
I have been thinking about the comments feature. It's like peas and carrots having comments on a blog. I have almost added them before, but didn't for fear it would sacrifice any of the simplicity - which led me to think about modules/plugins. I like the idea of plopping down a folder or zip that the Bearclaw binary then reads and incorporates. Maybe that's feasible, maybe it's not.
I'm going on a walk in a little bit and will give thought to a plugin system. Any ideas you have in mind?
I’ll try to remember to let you know how it turns out after I get it all going..
Also, one thing I'd like to sort out is making the page titles on the pages.html page that it generates not be based on the filename, but on the title of the article so-you-dont-see-stuff-like-this on pages.html.
As of yesterday since I added config variables, I'd like to relocate those to an external file to avoid recompile, and then use those to populate the header so that people don't take time to fill in the config and then still get "Bearclaw Blog" when they fire it up.
I really appreciate the time you're taking to talk this out with me, it's very inspiring and I'm getting lots of ideas. I can't wait to get done with Job 2 today so I can hammer out some of these things :) Thank you
What is it that people are trying to automate?
1. Add the image at `content/posts/post-title/image-name.png`
2. Add markdown that references it, like ``
3. Build and push to main, and then the image is available in minutes at `https://<host>/posts/post-title/image-name.png`
Part of the reason I use Hugo is because it's so low friction — the hard part is the writing (and writing consistently), and keeping everything else easy is key.
Jekyll keeps assets separated. Your posts live in _posts. Your static assets live together in a different directory.
I briefly experimented with switching from Jekyll to Hugo, but had too much invested—custom plugins and reliance on existing Jekyll plugins—in the Jekyll ecosystem to make the switch worthwhile.
From its repo: "Pagefind runs after any static site generator and automatically indexes the built static files. Pagefind then outputs a static search bundle to your website, and exposes a JavaScript search API that can be used anywhere on your site."
Pagefind is cool!
https://GitHub.com/fazalmajid/fts5index
Demo: use the search sidebar on blog.majid.info.
But yes, what you describe is how search works on Sphinx-generated documentation sites and is quite impressive technology even before WASM.
And don't get me wrong, I use Hugo as well.
[1]https://answers.netlify.com/t/is-this-project-dead/70988
At least don't upload any pics you've taken at home without stripping out the GPS info
In my case I use MDX, which is Markdown that allows components (eg React) to be embedded. This is great for interactive content, articles with charts, visualisations, etc.
Too much tracking, too many paywalls, and not easy to relocate your posts to another platform.
just write
stop using tools, just an HTML document is fine.
Seriously, just pick one and set it up. People blog on manually edited HTML files, it really doesn't matter.
I did it because I remember having issues with jekyll installation from time to time, like it suddenly broke out of nowhere, and trying to fix it became a pain.
Then I looked for alternatives and found Hugo, changed the template and installed in all my systems (Windows, Linux, macOS) and it has worked like a charm. Also, the speed boost was super noticeable, like, several times faster.
So if I were to choose again between Jekyll and Hugo, I'd go with Hugo.
edit: on the third hand... i need a place to practice and stay in shape with full stack dev as i'm more of a manager/therapist these days. So maybe something from the ground up is in my future
Plus, it has the added benefit of keeping your front-end skills upto date.
I also use self-hosted WordPress for a hobby blog and like the graphical editor and easy drag drop of images.
I will shamelessly plug my solution: md2blog. You just plop Markdown files into folders and it does the rest, without letting you get distracted by themes.
Edit: addressing the article, md2blog does not support email subscriptions, but it does generate an Atom feed. It also requires using a command line (but the tool is a single binary, so no installation or dependencies to deal with).
Link: https://jaredkrinke.github.io/md2blog/
That said, I haven't updated my blog in years, and at this point I'm not sure I still know how to! But the good thing about a static site generator, is it just sits there in S3, costing me just $0.14/month.
https://sethcalebweeks.com/til-astro-2/
I know there are ways around it, but does HN have filters for headlines ending in "in <year>"?
I take notes in md anyway so hoping that’ll be reasonably ergonomic