Migrating another personal project to Astro

This is one of those projects that’s been hanging around in the background of my life for a while. I actually started this thing about 10 years ago, as a blog, using a CMS that I might have even paid for, imagine that. I remember the platform was horrible, so I shifted, and I shifted again, and again. This porject has moved several times and the purpose it serves has morphed a little a long the way.

The version before Astro…

A couple of years ago — when I was properly trying to pivot into a development role — I built a version of this site as a React app as a portfolio piece. It was a fake e-commerce site selling Chinese hotpot ingredients. Bit random on the surface, but it made sense to me. The blog was essentially shelved.

But some background

My wife is Chinese, we both enjoy and sometimes host hotpot at home, and it’s one of those things that’s become part of our life here in the UK. Originally, this was just a blog, we used a commerical CMS, I forget the name, but it was naff. The blogging idea didn’t really work, my blogging interest is more technical, my wife wasn’t that bothered about updating it and then we found out we were expectant parents, things like this just got parked. The domain (chinesehotpot.co.uk) stuck around even after the original goal faded.

Side projects

Like many side projects, it drifted a bit. It ended up as a mix of:

• A few blog posts about China and hosting hotpot
• Some Amazon-style product listings
• A general “this exists” presence on the internet

Traffic has always been minimal. But I kept it going because it felt like it meant something to me — not just another throwaway repo. But over time, it started to feel like effort for the sake of it.

Where React Stopped Making Sense

React wasn’t the wrong choice at the time. I was learning, trying to get hired, trying to prove I could build something that looked like a modern web app. So I did exactly that. But the project didn’t grow into an app.

It quietly shrank into a small, mostly static website. And that’s where the mismatch started to show.

The slow drip of maintenance

The biggest issue wasn’t performance. It wasn’t even complexity, really. It was just the ongoing noise, which seems to be growing exponentially with the aid of AI finding holes in react components etc.

Every so often:

• GitHub would flag a vulnerability
• Something would be outdated
• Dependencies would need bumping

Nothing dramatic. But enough to create a low-level sense of “I should deal with this”. And for a site that barely gets any traffic, that starts to feel pointless quite quickly. You end up maintaining a stack that doesn’t justify itself.

Built like an app, used like a webpage

I finally got sick of this constant nagging, so sat down and thought about the problem for a moment. When I actually looked at the site, stripped of how it was built, it was basically:

• Static content
• A few pages
• No real interactivity
• No users, no data, no state worth talking about

But under the hood, it was still a full React setup. Basically I was using a tool because it’s what I was learning, not because it’s what the project needed. This is important stuff and something a junior might miss, you don’t need to build the most insane version of your app if all it does is display a little bit of text and a picture. I basically over-engineerd the site. I don’t know, maybe I planned to come back and add more, but if that’s true, I never did get round to actually comming back and building those extra bits…

At some point I realised I wasn’t avoiding working on it because I was busy. I was avoiding it because I couldn’t be bothered dealing with the overhead.

Why I moved the site to Astro

I’ve been using Astro for my main blog (this one), for a while now, so this wasn’t a big leap. If anything, it felt like the obvious correction. Astro just fits this kind of site better. I could have gone further still and built just a HTML site, but I the ability to scale up and andd functionality to something like Astro is, in my experience, easier than it would be with a raw HTML site.

Astro defaults to “simple”

The biggest win is that Astro doesn’t assume you’re building an app. You start with static pages. If you need interactivity, you add it deliberately. For chinesehotpot.co.uk, I didn’t (or don’t) need interactivity. Which meant:

• No client-side JavaScript by default
• No framework overhead
• No pretending the site is more complex than it is

The dependency situation improves overnight

Moving away from the React setup immediately cuts down the dependency tree. Which means:

• Fewer updates
• Fewer security alerts
• Less background noise

It’s not that dependencies are bad — it’s that they should earn their place. On the chinesehotpot.co.uk site, they weren’t.

It changes how the site feels to work on

This was the bit I didn’t fully appreciate until after the switch. With React, it felt like I had a small app I needed to maintain. With Astro, it feels like I have a set of pages I can edit. That sounds minor, but it changes your relationship with the project. The barrier to touching it drops quite a lot. I sometimes hesitated to add content because I thought ‘uh, I wonder what will be broken this time’. I feel like the Astro approach is just so much more stable, adding a new blog post is such a frictionless activity on this site (the one you’re looking at now) that I hope my old domain starts getting a bit more lovin’ from me, a few more updates, a bit more life. Oh and a lot fewer emails about security risks with the modules I’m using…

How I Rebuilt it (Without Overthinking it)

I didn’t try to migrate anything directly. I just rebuilt it in the simplest way possible. I will post the old blog posts again, and I think I will use an URL rewriter to avoid dead links for visitors, haven’t decided that yet, but the type of content probably isn’t the stuff you stash in favourites, so it might not be a thing to be fair.

Strip it back to basics

I reduced everything down to a few sections:

• Home
• Guides
• Recommended
• Blog

That’s it. No clever structure, no over-engineering. Just enough to make it usable.

Focus on content, not components

The React version leaned heavily into “look, I can build components” because although it started as just a blog, it evolved into a bit of a profile piece that I just don’t need today. This version is more like:

• write the thing
• present the thing
• move on

Which, for this kind of site, is exactly what it should be.

Keep the design simple (on purpose)

I didn’t try to redesign it into something fancy. It’s:

• white
• red (for obvious reasons)
• a bit of gold here and there

That’s enough.

Anything more would just be me entertaining or challenging myself rather than improving the site.

Remove anything that doesn’t justify itself

This became a bit of a rule:

If I have to explain why something exists, it probably shouldn’t be there.

So:

• no heavy components
• no unnecessary JS
• no “future-proofing”

Just a static site that does what it needs to do.

What I Took Away From This

This wasn’t a big technical challenge. It was more of a reset. I built the original site for the wrong reason.

Not wrong wrong — it made sense at the time. But I built it to look like something a junior developer would build to beef up their portfolio. Not because the project needed it. That distinction matters more the longer something lives.

Maintenance cost is real (even on tiny projects)

The React version didn’t take long to build and at the time, I was quite happy with it to be honest. But it quietly accumulated effort over time. Astro basically removes that ongoing cost. And for something like this, that’s the difference between:

• keeping it alive
• letting it die

Simple is easier to come back to

This is probably the biggest one. I’m far more likely to add to the chinesehotpot.co.uk site now than I was before. Not because I suddenly have more time — but because it no longer feels like effort to open it up and make a change. Not everything needs to be a “proper app”. This is something I wish I’d internalised earlier.

It’s very easy — especially when you’re trying to get into development — to feel like everything needs to demonstrate:

• frameworks
• patterns
• complexity

Sometimes the right answer is just:

It’s a website. Keep it simple.

The end result is… quieter.

• Fewer moving parts
• No dependency noise
• Fast, static pages
• Easy to update

More importantly, it actually feels aligned with what it is. It’s not trying to be a portfolio piece anymore. It’s just a small, personal site that reflects something I care about. And that’s probably why I’ll keep it going this time. Well, if you’re readin this post, you know my posting frequency yo-yo’s because I am always busy, but, I move forward with good intentions at least…