Technical post, for anyone interested in that sort of thing.
AdonisJS
Manga Kotoba is built on Node.js using the AdonisJS framework. AdonisJS is an “opinionated” framework, meaning it’s built on the “correct” libraries for handling certain things. For someone who wants to build a site without worrying about choosing the right library or developing their own, it’s a great framework. (If you’re not interested in the “opinionated” aspect, you can still use other libraries, but at the point AdonsiJS starts to lose a bit of its purpose for a project.)
SSR vs CSR
A primary objective with Manga Kotoba was to have it use SSR (server-side rendering), meaning the server generates the web page and sends it to the user. The alternative, CSR (client-side rendering) means the server sends a page template and data, and the user’s browser puts it together using Javascript. That’s great for the 99.9% of people who browse the web with JavaScript completely enabled.
For the 0.1% (not an accurate percentage, by the way), CSR websites, such as AniList, tend to look like this:
And if I visit the Discourse meta forum?
As such, I built MangaKotoba with Edge templates, which AdonisJS opinions to be the right way to template pages in an SSR world.
On the CSR side, there’s things like Svelte and Vue.
But AdonisJS also has an opinion on how to develop pages that are SSR when first sent to the user, and CSR the rest of the time (if JavaScript is available), using Inertia.
Implementing Intertia + Svelte
Manual Efforts
Back in 2025, I created a Git branch of Manga Kotoba and set to work attempting to port the site to Inertia and Svelte, two things I basically knew nothing about. (But I also knew nothing about TypeScript and Edge etc. when I first built the site.)
I quickly found it was too big of a lift. There were too many pages to convert over, especially considering Interia uses its own routing separately from Edge, and I wasn’t even certain at the time if it was possible to use both routers. (As it turns out, it is possible.)
I gave up on that plan, although I did later create some Svelte components (for progress bars and the reading status dropdown). The downside here is that I had to create everything in a component twice: an SSR version and a CSR version. This did have benefits (it was easier to update the vocabulary progress bar when marking vocabulary words as known), but also made it more complex, and thus more work to maintain.
Enter AI
A month ago, I decided to see if I could get Claude Sonnet 4.5 to convert the site over the Inertia. It failed so miserably that I wasn’t ready to spend the API code to try Claude Opus 4.5 on it.
We’ll just pretend this branch doesn’t exist.
Recently, I’ve been wanting to leave my “safe space” of using Claude Sonnet 4.5 and try out OpenAI’s Codex. And with GPT 5.3 Codex’s recent release and general availability, I decided this would be a good project to throw its way.
I did do things a bit differently this time. Rather than just tell the AI “convert this site from Edge to Inertia and Svelte”, I used Copilot’s Plan mode and have it save that as a Markdown file so I could have the AI tackle it piece by piece.
Codex hasn’t been perfect at it. It leaves some elements out when converting a page over. It also tries to improve some things, which can be good (I’ve kept some of its changes) or bad (I’ve had to revert some changes that were not okay).
Example of a good fix:
| Before |
After |
 |
 |
How did I miss including the 日? Was it was intentional or something?
A conversion project that would likely have taken me several months, while stagnating any other work on the site, will instead take under a week (not counting testing and minor clean-up). And I’m learning more about Svelte along the way.
I estimate the majority of the work will total around $5 in API costs. Cheaper if I had an OpenAI subscription (subsidized) versus Copilot (full-price API calls). That’s well worth the time saved versus trying to do all the work myself, and getting a vastly subpar result after many months of effort.
Mobile Layout
I’m also using this opportunity to start improving the mobile layout. While I’m not yet completely on board with having CSS declarations appear directly in the same Svelte file as HTML (and JavaScript), as I expect it to lead to duplicating some of the CSS that’s used the same for different components, it makes it a lot easier to locate the CSS related to a component. The mental processing required to update CSS falls drastically. I don’t think it will take too long to make me a convert, and I’ll likely wonder why I accepted using unencapsulated CSS for the past quarter of a century. 
Current library on mobile:
Updated library on mobile (not live yet):
No promises on the whole site being better on mobile when the Inertia version goes live, but the encapsulated CSS will make it a lot easier to manage and maintain responsive design.
Considering most of the site’s visitors (the majority of whom are people in Japan looking to download manga without paying for it) use mobile devices, I probably should put a little more focus into the mobile interface. (Or I can use my existing search position and convert the site into a manga 
site with ads.)
But for now, I need to get back to checking every site route one by one to find broken things to get fixed.
