Skip header to navigation
When I was a teen, I learned how to build WordPress themes. During holidays or when school was out, I vividly remember how I sometimes sat in front of my computer for a few days and nights, and created new themes for my blog. Of course I had no blog, but having one was a cool thought. But this stuck to me, and I was really never happy with how my blogs work. Until now!
When I was a teen, I learned how to build WordPress themes. During holidays or when school was out, I vividly remember how I sometimes sat in front of my computer for a few days and nights, and created new themes for my blog. Of course I had no blog, but having one was a cool thought. From designing in Photoshop, to programming it in Notepad++ and learning new things about WordPress, to finally dragging everything into FileZilla, and seeing how FTP slowly published my work to the world. It was a glorious feeling.
My themes always supported nested comments and pingbacks, but I hardly had any traffic on my site.
I must’ve created a dozen themes during this time, from simple designs to art-directed content. But I maybe used half of them to actually publish a few posts. The other half never got used, because I created a new theme before actually writing posts. And I always deleted the old content, because I thought it didn’t match the concept, or just because I found it cringe.
During this time, I enjoyed the process of programming and learning, more than I cared about the content.
Fast forward into my time after university. When I finally wanted to publish some actual content, I continued doing the same mistake. It was no longer WordPress, but I still implemented solutions for problems I didn’t have.
Yes, it would be cool to build support for interactive code examples and a sticky Table of Contents, displaying the section you’re currently reading, and all just generated from simple Markdown files. But when I wanted to write something, everything I built was useless, and nothing I really wanted and needed was there.
I don’t like to write content in my Code Editor. It’s cool to have Posts and Images tracked in Git, but I hated the process of dragging Images into directories, writing , committing, pushing, waiting for it to rebuild. Ugh.
And most importantly: that’s all I need. I don’t need a setup to write long and complex tech articles with a fancy UI.
My immediate thought was to (ab)use GitHub Issues as CMS. It ticks all my boxes. It’s free real estate. I don’t need to worry about database and hosting (except for worrying about API Rate limits), don’t need to make any backups (maybe I will have a GitHub Action to regularly download images), the content stays available even if I create a completely new site (given I don’t decide to delete the repository), and GitHub is totally never down (Ignoring the 11 Incidents last month. Maybe I need to implement a “GitHub is down, Content may not be up-to-date” banner). And it even has a comment section built in!
The idea of using GitHub Issues as Blog isn’t new. Some research, trying out things, finding some difficulties with it, looking at other implementations, overthinking it again and telling myself not to overthink it, and a few days later: a Blog inside GitHub Discussions was born.
Now I can even use the GitHub App to post from my phone! How futuristic.
Read more about the technical details in Part 2.
When I was a teen, I learned how to build WordPress themes. During holidays or when school was out, I vividly remember how I sometimes sat in front of my computer for a few days and nights, and created new themes for my blog. Of course I had no blog, but having one was a cool thought. But this stuck to me, and I was really never happy with how my blogs work. Until now!
When I was a teen, I learned how to build WordPress themes. During holidays or when school was out, I vividly remember how I sometimes sat in front of my computer for a few days and nights, and created new themes for my blog. Of course I had no blog, but having one was a cool thought. From designing in Photoshop, to programming it in Notepad++ and learning new things about WordPress, to finally dragging everything into FileZilla, and seeing how FTP slowly published my work to the world. It was a glorious feeling.
My themes always supported nested comments and pingbacks, but I hardly had any traffic on my site.
I must’ve created a dozen themes during this time, from simple designs to art-directed content. But I maybe used half of them to actually publish a few posts. The other half never got used, because I created a new theme before actually writing posts. And I always deleted the old content, because I thought it didn’t match the concept, or just because I found it cringe.
During this time, I enjoyed the process of programming and learning, more than I cared about the content.
Fast forward into my time after university. When I finally wanted to publish some actual content, I continued doing the same mistake. It was no longer WordPress, but I still implemented solutions for problems I didn’t have.
Yes, it would be cool to build support for interactive code examples and a sticky Table of Contents, displaying the section you’re currently reading, and all just generated from simple Markdown files. But when I wanted to write something, everything I built was useless, and nothing I really wanted and needed was there.
I don’t like to write content in my Code Editor. It’s cool to have Posts and Images tracked in Git, but I hated the process of dragging Images into directories, writing , committing, pushing, waiting for it to rebuild. Ugh.
And most importantly: that’s all I need. I don’t need a setup to write long and complex tech articles with a fancy UI.
My immediate thought was to (ab)use GitHub Issues as CMS. It ticks all my boxes. It’s free real estate. I don’t need to worry about database and hosting (except for worrying about API Rate limits), don’t need to make any backups (maybe I will have a GitHub Action to regularly download images), the content stays available even if I create a completely new site (given I don’t decide to delete the repository), and GitHub is totally never down (Ignoring the 11 Incidents last month. Maybe I need to implement a “GitHub is down, Content may not be up-to-date” banner). And it even has a comment section built in!
The idea of using GitHub Issues as Blog isn’t new. Some research, trying out things, finding some difficulties with it, looking at other implementations, overthinking it again and telling myself not to overthink it, and a few days later: a Blog inside GitHub Discussions was born.
Now I can even use the GitHub App to post from my phone! How futuristic.
Read more about the technical details in Part 2.
