Replacement my blog

The former blog was built with VuePress 1.x.

VuePress 1.x is a framework that relies on Vue.js 2.x and is specialized for building blogs and documentation sites.

https://github.com/search?q=repo%3Avuejs%2Fvuepress++%22vue%22%3A+&type=code

Vue.js 2.x is scheduled to be deprecated on 12/31/2023, and Vue.js 3.x is currently the default version.

Frequently Asked Questions | Vue.js #is-vue-2-still-supported

With Vue.js 2.x EOL, it was predictable that VuePress 1.x would no longer be maintained. As the announcement states, "VuePress v1 is not actively maintained now."

https://github.com/vuejs/vuepress/issues/2744

In other words, the previous blog needed to migrate to something else.

Purpose of the Migration

I decided to organize the objectives of the migration project.

Current Status

To organize the objectives, I need to understand the current situation. First, I will list the problems with the current situation.

Migration is necessary due to the deprecation of Vue.js 2.x.
VuePress is not scalable, which makes bold modifications more difficult.
- In particular, design changes are more cumbersome.
As VuePress lacks flexibility compared to plain web frameworks, it is not suitable as a playground to experiment with various technologies. This reduces the willingness to maintain it.
It was difficult to make it do heavy processing because the VuePress application behaves as a SPA.
I think the response time during cold start is slow(coz it deployed on Netlify ?).
When I update content, such as when I post a new blog, it takes more than 10 seconds to detect the new content.
- detection of new content had to be resolved on the front end (e.g. cache busting) coz markdown files were placed and rendered on the front end. Cache updates were dependent on the VuePress context, which was cumbersome to modify.

Technology Selection

Based on the above, the following points were essential for this migration project.

Build a blog with portability in mind.
Use relatively plain frameworks and libraries that are easy to add many of your functions.
Use technologies that are close to your technical area so that you can use them as a sandbox for your everyday use.
Build with SSR and distribute from a CDN.

Here, several options were considered as technology choices.

Build with Vue 3.x dependent Vue-like frameworks.
Build with a React-based framework such as Next.js.
Give up building my blog and use a blogging service.

I usually use Vue.js (Nuxt.js) and am not familiar with React.js. I would choose 1 if I wanted to focus on the technology I am using in front of me, choose 2 if my will to be proficient in React as well is strong right now, and choose 3 if I don't care anymore.

Of the above options, I chose 1, using Nuxt.js series 3 with SSR and delivering from a CDN using Cloudflare workers. I don't know if the change from Netlify to Cloudflare workers has increased the display speed, but I feel that the response time has improved by about 30%.

I also have to consider content delivery. In the past, I used the VuePress feature to put Markdown files on the front end and render them on the front end.

However, I would like to separate the content from the front end if possible. The reasons for this are as follows.

Managing content in a draft state becomes troublesome when it exists on the front end, and the way it is managed can affect the release process.
Including content on the front end can make the front-end source heavy.
When content exists in the front-end, new content may not be detected by the cache.
Separating content from the front end reduces dependencies on front-end PJs and increases portability.

Because of these concerns, I decided to separate the content. Also, since the main theme of this project is to port the front-end blog application, I decided to use micro CMS, a headless CMS, for its ease of use.

Design

To enhance portability, I challenged ourselves to separate the JavaScript world from the Vue world from the design stage.

By doing so, the cost of porting was reduced, and it appears that I did not have to make a major rework as I did this time around.

I initially wrote the code according to the default settings of Nuxt.js, but as a side effect, following this kind of architecture seems to have made it more readable.

Conclusion

I will keep striving to improve.

Reference

https://github.com/jabelic/JabelicWebPress
Vue 2 LTS, EOL & Extended Support

#blog