Above image from https://astro.build/blog/astro-1-release-update/
Well, yes. I'm planning another move.
It's not only because the front-end ecosystem is moving fast, but also about all the unsolved problems.
Brief History #
Before I present the motivation and possibilities of moving to Astro, let me briefly introduce the history.
The oldest version of my blog is ProgrammingNotes, which has been archived. It was built with MkDocs. It is a great tool for documentation, but not for blogs. It's more like a knowledge base than an actual blog.
Then I switched to Hugo. I chose Hugo mainly because of its wide adoption in simple personal websites. There are hundreds of awesome templates for displaying your experience and publications. And I made my own theme from a great theme called XMag. During the process of making and maintaining the theme, I found that Hugo's template language is really counter-intuitive and hard to do right (hugo-toc). Also, the comment on GitHub system is hard. The OAuth and "behave on your behalf" approach is not elegant. So I chose (vue-iblog) to blog directly with GitHub issues. And I was learning Vue, so Gridsome is a natural choice.
The Motivation #
But Gridsome has its own problem. It's updating slowly. Very slow. The Vue ecosystem has changed a lot in recent years, and Gridsome fails to keep up.
Alright, if that's the only reason, I'll just stick to Gridsome. But there are more.
It was a wrong choice to use Vuetify for a blog. Vuetify provides a lot of useful components and is a fantastic framework for apps. It was the only great UI framework for Vue I knew at that time. However, it just makes a blog site bloated. There is too much JavaScript and CSS for a site deployed on GitHub Pages and visited mainly in my region. Although I'm using PWA (Progressive Web App) tech to ease the pain, the first-page load is still slow, and PWA itself is introducing a lot of inconsistent and buggy behaviors. Besides, Vuetify's design is not suitable for blogging, or maybe it's my fault for not doing this in the right way. People are just tired of material designs, probably because it looks like a cheap app.
Things will be different if I migrate the blog's UI system to Tailwind / WindiCSS / UnoCSS. The bundle size will be small, and it will be easy if there is another move in the future. I have already used both WindiCSS and UnoCSS in a couple of projects, and they are awesome, especially the attributify mode.
Also, with the new micro-blog, the old 3-part division (moments, cheat sheets, programming) is no longer needed. The category can just act like a normal tag. Also, I'm planning to adopt a common blog index page, namely focusing on the recent posts, and hopefully making it more attractive.
Possibilities of Using Astro #
Why not Vite SSG? #
One already has great SSG (Static Site Generation) in Vite, why bother using another framework? The answer is that the SSG Vite community provides is not suitable for a blog. I really don't like the idea that every page is a component. In the context of blogging, the blog content is more data than components.
Advantages of Using Astro #
Astro fetches data ones at build time just like Gridsome, while Nuxt still fetches data when switching pages. So the logic of fetching data from GitHub Issues can just be reused.
Besides, when it comes to making blog content interactive (i.e. copying code blocks, making an interactive table of contents), the amount of required vanilla JavaScript is no less than actual Vue code. So it might be better just to embrace vanilla JavaScript and create Vue components when necessary.
Moving Blog too Often? #
Yes, it's a bad practice to constantly move blogs without writing many posts in between. However, the blog is not just a website to log something, it's also a place we explore and play around with new web technologies!
Besides, during this move, adopting Astro is just a small part of it. It's just a little more than a "regular" update.
❎ blogging ✅ blog-rewriting