May 17, 2024

I wrote a new blog using Next.js App router

ReactNext.js3.1 min to read

Before I dive into the development journey of my new blog, you might want to check it out first at my blog.

Back in 2020, React introduced Server Components. I was amazed by the possibility of writing asynchronous components.

Writing async components isn't groundbreaking per se; there was a short-lived framework before that used JSX syntax and allowed async components even on the client side.

What was novel, however, was React's support for async components, even though they could only run on the server. At that time, there wasn't a stable framework to leverage this feature. By coincidence, a new project last year required using Next.js. On my recommendation, we adopted the official App Router, seamlessly integrating React Server Components.

To master React Server Components, I decided to rewrite my blog using the App Router. Previously, my blog was built with Astro. Here’s a preview of the old blog.

My requirements for the new blog were:

  1. Fully utilize the App Router and Server Components to optimize performance.
  2. Adopt the latest and cutting-edge technologies.
  3. No backend services.
  4. Make it as visually appealing as possible.

Regarding the first point, Server Components performed admirably.


For the second point, I am currently using:

  1. TailwindCSS — Needs no introduction.
  2. React Aria Components — Not shadcn/ui, nor radix-ui.
  3. @tabler/icons-react — Over 5k icons, simply astonishing.
  4. shiki — Updated, more powerful syntax highlighting.
  5. MDX — Write React code within Markdown.

The highlights are MDX and shiki. I aim to include as many code examples as possible in my posts, allowing readers to interact with them. shiki supports numerous plugins like diff, focus, highlight, and the best one is twoslash, which makes code blocks more user-friendly.

MDX and shiki are a match made in heaven. All these effects can run server-side without bundling any js.

For the third point, I employed a novel approach:

Using GitHub Discussions as the Blog Backend

I haven’t seen anyone else using this method. I find it more blog-friendly than using GitHub Issues. It has several distinct advantages:

  1. Permissions Management — Only the author can post content; others can only comment (unlike GitHub Issues).
  2. Categories — GitHub Discussions allows multiple categories (again, unlike GitHub Issues).
  3. Tags — Customizable tags for posts with adjustable colors.
  4. Image Uploads — Pasting an image in the Discussions input box uploads it to GitHub automatically.
  5. Comments — Complete commenting system from GitHub, including likes, replies, and mentions (with slight differences between Discussions and Issues).

Moreover, GitHub provides a robust GraphQL API, enabling blog development with any front-end technology, even a console app.

For the fourth point:

I studied Bento design on Dribbble, drawing inspiration from various Bento-style blogs.

Current missing features in my blog:

If you previewed my blog and found it appealing, you can visit my GitHub repository. It supports one-click deployment and includes a simple forking tutorial.