The author details recent technical maintenance, addressing a React security patch, deprecating old APIs, and resolving Vercel timeouts by enabling Fluid Computing. Faced with static site generation needs, they migrated from React/Next.js to Nuxt, optimizing caching for performance. They also implemented a custom email domain via Mailgun and updated site copyrights to 2026. Additionally, they discuss efficiency improvements in a Minecraft datapack (riscvmc) and plans for a RISC-V precompiler.
There's a new critical remote code execution bug in React,
so it took me a while to upgrade all the projects.
And since the IN site is deprecated, the domestic API is useless now.
It still requires a lot of effort to maintain them,
so I just shut them down.
For security reasons, I removed all the tokens and JWKS from the database. I realized that the cron job (implemented via a fetch request) would definitely exceed the time limit on Vercel, so I spent some time thinking about how to fix it, but found it really challenging.
Eventually, I realized I just needed to enable a feature called Fluid Computing, then the time limit would be sufficient. It’s a default option now, but this project is so old that it wasn’t enabled automatically.
Regarding the attitude toward React and Next.js, I have noticed some unfriendly opinions. These systems do have disadvantages, but if implemented properly, the code can be quite safe and fast, which makes them perfect for hobby projects. This time, something really undesirable happened, This time it has done something really bad, but that is not the reason to attack or discriminate it.
The blog is slow sometimes when accessed through my phone,
but it's reported to be smooth via laptop (including on my laptop).
So I picked up the old idea and tried to make it a static site.
To generate only the necessary content,
we need to keep the old blogs and JS files and put new ones among them.
React and Next.js do not support this,
so I had no choice but to rewrite it in Nuxt.
The key point is I didn’t do a feasibility analysis,
so I realized later that I need a new repo to store the cached (generated) blogs,
which goes against at least my principle for GitHub repos.
Sigh
But the good news is I'm getting used to Nuxt,
so I may switch the new Vue site to Nuxt.
Vue doesn’t really support static HTML export, right?
I'm really excited about my modifications to the blog.
There are two main points: first, I didn't enable Cloudflare proxy,
so it’s DNS only, and Vercel doesn’t have a good enough CDN system compared to Cloudflare.
Also, I didn’t set the cache control header.
I used to believe React would send client packets with diffes in the HTML files to enable dynamic pages,
but that’s wrong. It’s done through JavaScript, which is another static file.
So I can just cache them!
Done in 781 ms, just like a flash! I love it.
I own a domain, which is cool, but being able to send emails that end with my own domain would be even cooler!
So that’s what I did.
Custom domains are often not free, so I found Mailgun and sent emails through its Api.
Replies are forwarded to my private email account.
If I want to reply again, I just need to get the message ID from the source and put it in the h:In-Reply-To header.
I also need to set the h:References header, and boom-the reply will be sent!
It works the same for deeper replies.
It's 2026 now! Anything exciting? (besides academic pressure) Yeah, the answer is turning every 2025 in the copyright section of my websites to 2026. Haha. Actually, there are only two sites with this issue: one updates automatically, while the other (my main website) requires manual modification.
Another thing is about riscvmc, the datapack. I accidentally found that using a scoreboard is always faster than using a binary array in storage; the bitwise operations only require 96 lines of commands, or are even faster with some execute magic. That’s way better than my previous 300+ line method! Also, using an emulator isn’t a great idea either. It requires decoding instructions, which costs a lot of performance. So, my plan is to make a datapack precompiler for RISC-V. I have a lot of ideas for it, but it requires a lot of time and effort—I may work on it later, perhaps in May or beyond...