A "SvelteKit" appreciation post

Published on: 9/24/2025

This is a different kind of post as opposed to my usual blog posts. It doesn’t really talk about my projects outside this blog, and talks about the blog, as the project.

Background

Ever since I started this blog, I’ve been using AstroJS as the programming framework, and Vercel as the deployment platform.

I purposefully chose Vercel since it integrates well with many modern frameworks, and because the free tier does everything that I want to do. Pipeline integrated deployments (CD), automatic build failure fail over and analytics.

AstroJS on the other hand, was not really something I set out to use. Out of curiosity, I looked up alternatives to React, which is what I have the most experience in. AstroJS was one that peeked my interest, with its description as an MPA framework.

The positives about AstroJS

So I went ahead and started developing this blog using it. My initial experience was pretty nice, automatic image optimization. Automatic cache breaking (or so I thought). Ease of dynamic content generation, I.E. writing blogs in Markdown and having the framework translate them to HTML.

My issues with AstroJS

After a few months of using AstroJS I started to notice some issues that I had not noticed initially.

Relied on JavaScript to render page contents
- If the browser had JavaScript disabled, it would not render the page’s content, even the index page. (Server-Side Rendering (SSR) probably would’ve fixed the issue, but I didn’t understand the documentation about how to turn it on)
- Caused brief white flashes while it loaded the JavaScript, then the page contents
If I turned on caching on everything except the HTML, the cache breaker, would not break the cache.

Initial attempt at migrating to NextJS

I heard a lot of good things about NextJS. With my vanilla React knowledge, I assumed it would be pretty simple to migrate to NextJS. Which I would end up just rewriting the whole thing anyway. Boy was I wrong, my brain would just not accept the NextJS way of thinking. I ended up having to fight the framework to do basic things, and I quickly gave up.

I acknowledge that it probably wasn’t the framework’s fault, and I probably did not take enough time to learn it. However, for a hobby project, I didn’t see the value.

Enter SvelteKit

I’ve heard about Svelte, mostly in some off-hand comments about how it’s better than everything. Kind of like the “let’s rewrite this in rust” crowd. It’s kind of why I never bothered to look at it, because I am very skeptical of groups that tout their solution as the best for everything.

However, I was looking for a solution to my issues. I started casually looking into Svelte, and found it looked like a promising solution! It promised the following:

a simple syntax
built-in simple to use routing
a compiler to avoid shipping a JavaScript runtime
being overall lightweight compared to other JS frameworks

My experience rewriting my blog to SvelteKit

If I’m honest, it was a breeze. A true breath of fresh air. I rewrote my entire blog codebase, which is pretty simple, in a single afternoon. It fixes most of my issues with AstroJS.

It uses SSR by default, which means that it works on browsers that disable JavaScript, and that I didn’t need to figure out how to enable it.
- Since it uses SSR, it loads considerably faster, and cleaner! No more flashing page as the page loads on less powerful devices
The syntax is slightly simpler than the AstroJS syntax for pretty much everything.
Documentation seems a tad easier to understand

It still doesn’t address my issues with cache breaking, but since the page renders a hell of a lot faster, I don’t need as aggressive caching anymore.

Overall, pretty pleased with my experience.

Will definitely consider SvelteKit for my next project! 😄

-Tacocake