- Change the series widget to a collapsible list. If there are 5 or fewer posts, it should be open by default. If there are more than 5 posts, it should be closed by default.
- Authors page and posts by author
- Treat the first tag on a post as the "primary" tag, kinda how Quanta Magazine does it
- Improve the tertiary pages (posts by author, posts by tag, posts by series) by adding pagination, most read posts, on the /posts/tags/abc page add a small link back to the all tags page, etc.
- Swap anchor tags in markdown with next/link
- Comment system
- Increase line spacing in the body text
- Github Flavored Markdown. Give it a shot. https://github.com/remarkjs/remark-gfm
- Trending / Most Popular posts / Analytics
- SEO
- Newsletter
- RSS
- New Next 13 features and best practices
- Reorganize the code following DDD or onion architecture principles
- Syntax highlighting for markdown code snippets
- Audit the eslint setup
- Blog post ToC
- Blog post footnotes
- Different layouts for different types of blog posts
- Scroll Restoration
- Feature to allow users to report typos or suggest changes
- Monetization (ads, job board, paywall for some gated content, etc). This should be a priority in the future though.
- Internationalization. It's not yet clear how this would work in Next 13 anyway.
- Blog post excerpts. We already support "description" in the frontmatter, so I'm inclined to say no on this one
- Categories. We already have the concept of tags and series.
- Feature flags. They might be useful in the future though when the blog is more complex.
- SafeQL has a better moon/sun dark mode toggle. Not a high priority though.
- Admin panel and/or authoriing posts in the browser. Too much work for not enough gain.
- Remote content and images. Again, too much work for right now. Push the local filesystem workflow to it's limits first.
-
- Preview Mode. It doesn't seem to be implemented in Next 13 yet.
- The file
lib/md.tshas strayed quite far from only being focused on markdown. It contains lots of business logic. This file should probably be renamed or broken up. - This goes along with DDD principles mentioned above, but it may be worth investigating if domain objects such as
Posts should come with methods attached, or if they should continue to just be a collection of properties.
- https://www.ryanfiller.com/blog/remark-and-rehype-plugins
- https://using-remark.gatsbyjs.org/custom-components/
- A lot of people focus on the dangers of optimizing or over-engineering too early. But people rarely talk about the dangers of waiting long to start implementing more robust patterns. There exists a golden window of when you should should focus on re-architecting... as soon as working within the current architecture begins to feel painful and tedious. As soon as you feel like the existing architecture is steering you into spaghetti more often than it is steering you into the pit of success. You should always be vigilant about looking for this golden window. If you over-engineer early on, you will likely create an architecture that isn't actually suited to the domain you're working in because the process wasn't informed enough by real-world experience. On the flip side, if you allow simple and naive patterns stick around well past their welcome, then you will one day find yourself lost in a maze with no idea how to get out. Either way, you eventually end up with a pile of spaghetti code. So, when you start that next project, perhaps you start out with a handful of transaction scripts, eventually graduate to MVC, and finally you go all-in on DDD. Always be on the lookout for when it's time to graduate, or if you are happy with where you're at.
- How I built this blog
- How to fork my repo and get up and running with your own blog