Migrated Site to SvelteKit
In September, I migrated my site to a new stack. In this post I want to discuss the reasons for and result of the migration, as well as share my impressions of the new stack.
I had two main reasons to rebuild the site: the desire to radically simplify everything and the feeling that Next is not good for generating static sites.
Desire for Simplification
For a simple blog, the previous stack was overly demanding in terms of maintenance resources. Dependencies took a long time to update, dev server performance was low, React and TypeScript required various “ceremonies” before I could add a new page or feature. I wanted a faster, cheaper, and simpler solution.
Next Not Really Suited for SSG
I felt like I had to reinvent the wheel when working with Next, which was time-consuming, and I didn’t like the result of SSG—resulting pages seemed unnecessarily heavy. I wanted a more user-friendly and reliable tool.
Astro seemed interesting, but I was already a bit familiar with SvelteKit—I wrote the web version of my refactoring book with it last year—so I chose it.
TypeScript is something I decided to move away from this time. Most of the code on the blog is “infrastructure” that I’m unlikely to change often, so I wouldn’t get much use out of TypeScript but the maintenance cost would increase again.
For tests, I chose Playwright. I thought that the only thing important for a blog is how the pages look in the end, so I decided to only use screenshot tests, and Playwright had subjectively the nicest API for them.
There were a lot of changes. In addition to the “infrastructure” changes, I also updated the design, improved the content structure in the repository and translated some old posts into English.
I’ve been wanting to do this for a long time, so I finally freshened up the design of the main page and some other pages. The redesign of the post list is inspired by Andrey Romanov’s site and the redesign of the projects page by is inspired by Salavat Abdullin’s site. If you’re reading—thank you!
In addition, I got rid of dedicated pages for each of the projects. Now the links lead directly to the app, book, or project itself on GitHub. All the “cool stories” about the process of working on projects and their releases (e.g. “How we launched MRKT”) I moved to the blog.
Tags have become a little more useful. Each tag is now a “thematic compilation” of everything I’ve written, programmed, and said on the topic. Such compilations are convenient, for example, to send in response to questions like “What to read about X?”, which I sometimes receive in mail or in my GitHub issues.
I also now use tags to find and interlink similar content—something I’ve been wanting to do for a long time but never got around to it. So far I’ve only added a “Related Topics” section to the tag page, but I plan to add a similar section to the individual article page as well.
Some Old Posts Resurrected
I published some posts that got lost when the site was first moved from MODX to JAM-stack. Some of them were in drafts, some of them were unpublished (and I don’t really remember why). Among such posts, for example:
- Reasoning about night-coding
- Impressions from first use of flexbox
- The very first mention of Prokrutchik
Anyway, I dug them up, translated them into English, and published them.
Content Structure Improved
In the new version, I’m using GitHub as an alternative way to read my articles. Each post is a directory inside
storage that contains everything related to that particular post. Pictures, YouTube links, metadata, and text in all the languages I’ve managed to translate the post into.
The new content structure helps you read articles directly on GitHub—looks fine:
GitHub, however, doesn’t render the
alt text of the images as a caption to the
figure as I do on my site, so sometimes the images are shown without additional context, but I found it not very critical.
Images Cleaned Up
I removed images in “old” formats (
png) from my posts and left only
webp, which already has about 96% global support.
At the same time, I removed everything related to automated image minification and resizing. I don’t write posts very often, I don’t have a lot of images, so it seemed expensive and useless to me to build infrastructure for auto-minification, resizing and converting images to different formats. I decided to simply prepare images manually.
Of note, I can highlight the quality of the generated pages and the speed of the stack.
I use Static Adapter to generate pages, and I like that it has a “don’t use CSR” option. The output pages are now simple, lightweight, and most importantly, don’t contain client-side JS where it isn’t needed.
Fast Dev Server
Vite, which runs under the hood at SvelteKit, actually starts and builds the site much faster than my previous stack with Next. Even on my old home laptop, the project starts almost instantly.
Fast Builds and Deploy
The compiler is fast, so the build takes no more than half a minute, and the light weight of the pages makes for a fast deploy.
This time I decided not to be too careful about “code purity.” The reasons are about the same as for not using TypeScript: I’m unlikely to change this code very often.
The lack of restrictions reduces the friction before starting a new feature, page, or testing an idea. Since I’m working on the project alone, there’s not much point in “enforcing best practices on the team,” but the amount of development time is reduced significantly.
Not everything, however, is perfectly smooth. For example, I had to do a bit of work with integrating “custom components” like
Switch into posts. I couldn’t find any handy tool, so I wrote an auto-import hack. I hope I won’t have to touch it often because of breaking changes in SvelteKit.
On the whole, I am satisfied with the new stack. I like that the routing is page-based, that the server code is not mixed with the client code, and that the framework uses standard web-platform-based stuff.
Separately, I liked the “server pages” and how they are rendered when generated statically. In the previous stack I had to “find a workaround” when generating an RSS feed, but SvelteKit allows me to create a
+server.js file and specify how to render it when building—so that the output becomes an
.xml file. No helpers, no workarounds.
I also like Svelte itself better than React. At least I don’t have to think of 100500 ways to integrate styles—everything is already thought out for me. Of course, there is a limitation that in Svelte a component is single file, but inside it there is everything it needs: markup, styles, logic.
There is a slight feeling that SvelteKit is crude for generating static blogs because there are issues with rendering Markdown files and components within it 1, 2, 3, 4, but maybe this is purely my problem due to dynamic components within articles.
In any case, all these problems can be fixed by workarounds, and the number of workarounds this time is much less than last time.
Sources and References
- Page Options,
- Static Adapter
- Page Router in Next
- App Router in Next