2022-11-14

Migrating from Medium and Squarespace

Before I had my site where it is now, hosted on Gitlab and archived there as well as GitHub, my domain was a Squarespace site. For tutorials, and a few articles, I used Medium which wasn’t tied to my domain but was just an account you set up on the site and people can find your content based on a quick search. When I was starting as a developer, Medium was used a lot more by developers to post technical content, so I followed. I even published a couple of articles for FreeCodeCamp there until they later moved and created their self-hosted blog. So I had two ways of sharing content, Squarespace for more personal stuff and Medium for more technical. It was pretty easy and for the most part a pretty seamless experience. But I yearned for something that I built and not some CMS that allows you to drag ‘n drop blocks however you like, although this is what makes Squarespace and Medium so appealing. But each had its issues that pushed me to move.

For Squarespace, the issue was with how to customize it. The way it works on the server is everything is encoded in JSON. And so when you create a block it gets encoded in JSON and returned to the browser but from that point, there is only so much one can do to customize the internals. Squarespace leans heavily on themes and a pre-built aesthetic that act like training wheels for building a site. This is probably for good reason when you look at sites created in the early days. But this always felt limiting to me and I never did figure out how to customize the site further without digging into the documentation and learning more about how to wrangle what gets turned into JSON on the server.

For Medium, the issue was the prebuilt blocks they provide for code weren’t ideal. They didn’t, and maybe still don’t, have basic support for syntax highlighting for code blocks. I suppose that’s why others started to migrate to dev.to since it seems to have a lot more of the features needed to write more technical content. But I didn’t want to migrate content from Medium to dev.to. Seemed like too much work for little gain. Also, I liked Medium’s aesthetic more even with no support for syntax highlighting. But what annoyed me was when they started to introduce paywalls and memberships. Then it became something I didn’t want to be a part of anymore but the migration away from Medium, and Squarespace, would not be easy.

First, you have to export your content from each site. Both Medium and Squarespace do this but with Medium, it was a lot easier but only because there was a nice tool that did a lot of the dirty work of converting your posts from Medium’s markup to markdown. With Squarespace, they exported an XML file with all kinds of cruft but it was intended to be imported to a word press site. So anyhow, I wrote a program to iterate over the XML and create files for each article. Both of these processes were very tedious and were the most time-consuming aspect of the migration, mostly because the conversions were error-prone and so it took work to fix up each article and remove HTML tags and whatever else was left over during the conversion. Creating the site was the easy part.

When I was looking into creating a new blog, I thought about what I wanted: fast to develop, easy to understand, markdown-centric, and performant. I had used NextJS in the past for a few other projects but it seemed a bit too much for what is essentially a website, not a web app. Astro was just coming up around that time and it had a nice appeal. It was HTML-centric, worked well with markdown, was performant and fast, and if you needed a bit of interaction then you could create islands that were heavily stripped of all the bloat that comes with using NextJS and JavaScript frameworks in general. It’s what I was going for and so I began porting all of my content to it. At that point, I hadn’t shut down my main site yet on Squarespace but I soon did to force me to make the full migration.

Getting off Squarespace wasn’t just about migrating content, it was also migrating a domain and a host. I wanted to use something that had good services built in but wasn’t too big like GitHub. I had used Gitlab a bit in the past and I knew it had what I needed, such as CI/CD, out of the box which is nice when you don’t want to break your site accidentally. It could also house my domain so it was an easy choice. But in addition to hosting it on Gitlab, I did want to achieve something else at the same time: an archive of my site. The point here is, if my site ever goes down sometime in the future, such as when I stop paying for my domain, you can still get to my site via https://arecvlohe.gitlab.io/. For extra redundancy, I did the same thing on GitHub in addition to having it archived there as well. So that seemed pretty nice, not only do I get to build a site for myself, I can keep multiple backups of it too.

So the thought I had the other day about my sites being archived on Gitlab and GitHub, was that I think sometime in the future people will be excavating hard drives just as they do now with archeological sites. They will open and download the data and be able to read the content from the past. I suppose this assumes some catastrophic end to the world and I am okay with that idea. But it also seems pretty neat that in however many years in the future someone might look back and read this writing and talk about how strange we spoke and what things we said.