Moving my blog to Hashnode
5 min read
I've previously blogged about:
- moving from WordPress to Hugo
- working with Netlify CLI on Windows Subsystem for Linux 2 for local development
- switching to Eleventy.js
What I hadn't realised until the last week was that the Eleventy theme I was using was mangling my code snippets. I found a good theme, and was mid-way through the conversion when I saw that Catalin Pit had joined Hashnode as a Developer Advocate. This tweet was enough of a reminder to prompt me to search out his blog entry on the reasons for moving his blog to Hashnode.
Why move to Hashnode?
I decided to have a look at Hashnode, and was sufficiently reassured that I've moved my own blog too. My reasons for choosing it:
- I plan to write more (blog articles, tweets, an eBook and a video-based course) particularly over the next couple of months as I consider my next project. Being able to point people to my articles will hopefully help.
- I like the writing experience. I can:
- continue to write in Markdown
- copy and paste screenshots, which get hosted on Hashnode's CDN
- write on and off through the day, knowing that post drafts are saved automatically.
- The theme:
- has a dark mode, which is easily toggled.
- has a
Click to copy code blockbutton
- I still publish on my own custom domain, but there's a Network Effect of being on the Hashnode platform, and what I write might be more easily found by other developers.
- The lack of lock-in means:
- I can export posts in
.mdformat as a backup and if ever I need to move.
- Any SEO is against my own custom domain, rather than the Hashnode platform
- I can export posts in
Domains and DNS
I really like the content at Learn Enough and am impressed that they've written a free eBook Learn enough Custom Domains to be dangerous which includes a guide on working with DNS in Cloudflare.
www or naked domain?
Increasingly, modern browsers hide
https:// and even
www. To change this behaviour in Chrome right-click the address bar. In Brave browser, go to brave://settings/appearance and toggle
Always show full URLs
Cloudfront have supported CNAME flattening, since 2014, but I'll stay old school and use
www., and handle traffic hitting the naked domain with a redirection rule.
Change nameservers to point to Cloudfront, and enable MFA to avoid unwanted changes to DNS.
Check in the Google Admin Toolbox Dig tool that the change has been made.
Handle what happens when a visitor goes to the root of the domain.
Follow the instructions in redirecting example.com to www.example.com when using Cloudflare.
Use a CNAME to point
www.to the Hashnode network. We set the DNS record to
DNS onlyto allow Hashnode rather than Cloudfront to work as the CDN.
Use an A record for the
- Use the bulk import functionality to import the 36 posts I already had in Markdown format.
- Update tags on imported content.
- Start writing!