You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
Flashback
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.
Bad Habits stick to you
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.
What do I need to write content?
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.
I want a Textbox inside a Browser. Creating or updating content should be simple and fast.
I want a simple "Save" button to publish or update content, without going through Git.
When I want to write a 2-sentence Post, it should be published in no time.
I like writing Markdown, so that's okay. I just shouldn't need my Editor.
I want a Preview. When I proofread a Post, I just like to do it in a Preview of the Post.
I want to drag an Image from my Desktop into the Browser, it gets uploaded and pasted into the Post, and just works.
I don't want to deal with a database.
It should be possible to extend in the future, when needed.
I still want to build the UI myself, but no unnecessary features until I really need them.
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.
Making decisions
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 hosting1, don't need to make any backups2, the content stays available even if I create a completely new site3, and GitHub is totally never down.4 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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
How to Build a Blog
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!
Flashback
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.
Bad Habits stick to you
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.
What do I need to write content?
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.
Making decisions
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 hosting1, don't need to make any backups2, the content stays available even if I create a completely new site3, and GitHub is totally never down.4 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.
Footnotes
Except for worrying about API Rate Limits. ↩
Maybe I will have a GitHub Action to regularly download images. ↩
Given I don't decide to delete the repository. ↩
Ignoring the 11 Incidents last month. Maybe I need to implement a "GitHub is down, Content may not be up-to-date" banner. ↩
Beta Was this translation helpful? Give feedback.
All reactions