I abandoned the blog I had been running with Jekyll and rebuilt it from scratch using React-based Next.js.

When I first encountered GitHub Pages, I mistakenly believed that hosting had to be based on Jekyll. In hindsight, that wasn't actually the case at all.

I recently picked up React, and it turned out to be a surprisingly attractive framework, so I wanted to build something small with it.
A blog seemed like a fitting project. After all, as a self-proclaimed developer, it felt like I should build at least one blog myself...

I hadn't touched it in a while, but up until now I had been running a Jekyll blog. I had applied the Moon Theme, and it came with a number of small and large inconveniences.

1. The unfamiliar Jekyll environment

   GitHub's development language is Ruby. Perhaps that's why GitHub Pages' default deployment follows Jekyll, a Ruby-based framework.
   The problem is that in Korea, demand for both Jekyll and the Ruby language itself is quite low. Having to pick up a completely unfamiliar language just to run a simple blog is a downside that can't be ignored.

   Of course, I wasn't directly developing in Ruby, but the Jekyll ecosystem itself also wasn't particularly familiar territory.

2. Understanding someone else's source code

   Due to the same issue as point 1, I couldn't develop Jekyll from scratch.
   When a need for a specific feature arose, it was important to design it "well" so that it matched the current theme. But from a user's perspective, understanding the theme developer's design philosophy is a different problem entirely from simple design — grasping the structure was an added burden on top of that.
   On top of that, I have my own lacking skills combined with a strange obsessiveness, so I struggle to read code that isn't written in my own style. I also dislike black boxes within a project. Despite not being particularly skilled myself, I really dislike having chunks of code within a project that I don't understand. And since my design sense isn't great either, the end result ends up looking out of place next to the existing theme.

3. Convenient extensibility for users, inconvenient extensibility for developers

   Why do people use themes in environments like blogs, web pages, or PPTs? It's to boldly skip the tedious but important investment in design while still achieving decent design results. That's a fine intention in itself. But it only holds true as long as you're simply working within the direction the theme was intended for.

   Most people have probably had a similar experience — needing to customize a theme or template as required.
   Most themes shine when the end result aligns with the design philosophy the theme is pursuing. In other words, once that intent is compromised, the quality of the result plummets sharply.
   On top of that, if you need to remove existing elements (source code, plugins, etc.) as needed, it's hard to grasp their dependencies, which carries significant risk.

   For example, the Moon Theme mentioned above has a dependency on jQuery.
   Given the generally pessimistic view of jQuery in modern web development, this comes across as a significant downside. And the effort required to remove it can't be ignored either.
   Of course, you can't ignore the development trends of the time, and development in particular is a field where trends cycle extremely fast. Looking back, this is somewhat of a retrospective judgment. Even so, the fact remains that it's a flaw the user never intended.

4. The urge to build

   I judged that static blogs are relatively low in development difficulty, since there's almost no backend involved and no complex business logic required. In other words, if I wanted to, using a blog I built myself wouldn't be too difficult.
   As mentioned above, using a blog I developed myself feels more fitting for a developer. The difficulty level was also a good match for applying the React I was studying.

When building a blog with React, people generally use either Next.js or Gatsby.js. For this blog, I used Next.js.

Next.js shares a similar spirit with Ruby's Jekyll framework. Jekyll defines a structural schema within the framework itself, causing it to behave similarly to React's Component model. Back then, before I had even touched React, I had been building my blog in a way structurally similar to React's Component approach — without even realizing it, ironically enough.

Next.js likewise has a built-in environment within the library itself for building and constructing static sites, making it easy to use. And there's a bonus: numerous plugins developed by various users.
Thanks to that, I was able to build a static blog from the ground up. I did try to put some thought into the design, but design remains difficult, as always.
I plan to cover Next.js and Gatsby.js in more depth separately later on.

There's still work left to do. I need to add a sitemap generator, and a related-posts feature is also needed. There are also a number of small, unpolished details remaining. No matter the scale, publishing anything really does seem to be genuinely hard.
At the very least, this blog is something I built through my own effort, so I hope I can keep it running consistently.