When we say "first page" of a blog, we usually mean the first page visitors see—the homepage with the latest posts. But what if we treated a blog like what it actually is: a notebook or diary?

In a physical notebook, page 1 contains your first entry. As you write more, you fill pages 2, 3, 4, and so on. When someone wants to read it, they naturally start from page 1 or jump to the last page for recent entries.

Traditional blog pagination works backwards because it was simpler for developers to write SELECT * FROM posts ORDER BY dt DESC LIMIT 10. But it creates a fundamental problem: page contents change with every new post.

You can't say "this post is on page 10" because page 10 contains different posts after each publish. This isn't just conceptually messy—it has real technical costs. Links to /page/10 become meaningless. Static site generators must rebuild and upload N index pages per post. Git histories bloat with N changed files.

The Solution

Treat your blog like a notebook with fixed pages:

• Page 1: posts 1-20
• Page 2: posts 21-40
• Page 3: posts 41-60

Your homepage becomes the last page—the one you're currently writing.

To avoid a sparse final page, keep a buffer of 20-39 posts on the homepage. When you publish post 101, articles 81-100 stay on the homepage. Once you hit post 120, page 5 (posts 81-100) gets finalized, and the cycle repeats.

This blog works this way. Visit blog.vrypan.net, and you land on page 138, because I've been posting for years, and this is the page I'm currently writing on.

Note: This is how pagination works on bckt since v0.5.2. Of course, if you think this way of thinking will confuse your users, you don't have to expose it to them, and tell them they are on page 100. You can show links to previous and next pages, just like they are used to. But whne you post a new article, you wont have to re-upload or git commit 100 new index pages ;-)