YACReaderWeb: the comic reader I wanted in a browser

I have been running YACReader for years. It's a great iOS app that serves up your digitized comics/manga onto screens beautifully. The only problem is its very clunky to use on a Desktop and involves installing some 'just trust us' .exe files. I don't think this is a great way to add functionality to your computing experience in 2026.

So I wanted a browser app that could sit in front of an existing YACReaderLibrary, browse libraries and folders, open comics, remember where I stopped, and not not interfere with the iOS apps. That sounds like a small ask, but its not something that is going to be monetized, so nobody wrote it.

Basically, a web UI in front of a backend database. A perfect use case for AI coding.

So I built YACReaderWeb.

The architecture is deliberately boring

The backend part was already solved. YACReaderLibraryServer was sitting there in Docker, serving the same library to my kids iPads. That part worked great and I have no intention of changing it. My new web app would just read that library but not write anything.

I did not want a giant stack for this. No database. No elaborate frontend build. No extra services. The upstream server already knows about libraries, folders, page images, and comic metadata. The web layer just needed to be a decent translator.

So YACReaderWeb is a small Node app that talks to YACReaderLibraryServer, renders HTML, proxies covers and pages, and serves a little bit of browser-side JavaScript for the reader.

The whole thing is configured with a couple of environment variables:

services:
  webreader:
    image: ghcr.io/abort-retry-ignore/yacreaderweb:latest
    environment:
      WEBREADER_PORT: 3000
      YACR_SERVER_URL: http://host.docker.internal:60000
      WEBREADER_BASIC_AUTH_USERNAME:
      WEBREADER_BASIC_AUTH_PASSWORD:

That is the shape I wanted from the start. Point it at the real library server, run one container, and stop thinking about infrastructure.

This also keeps the boundary clean. YACReaderWeb is not pretending to be a new library manager. It is a browser shell in front of the one that already exists.

Why the sidecar model is the right one

I like sidecars for personal software because they let existing tools keep doing their jobs.

Instead of inventing new persistence, YACReaderWeb just stores reader progress in local storage. Instead of copying library data, it asks upstream for folders, comics, and pages as needed. Instead of a heavy auth system, it can sit behind a dead simple username and password if I want it exposed somewhere that is not purely local.

This is one of those cases where doing less is not just easier. It is better.

Authentication needed to stay simple

So optional auth is just this: if WEBREADER_BASIC_AUTH_USERNAME and WEBREADER_BASIC_AUTH_PASSWORD are set, the app shows a login page and protects every route. If they are not set, auth is off.

That is enough.

There is no account recovery flow because I am not running a SaaS. There is no extra database tables because there are no users to store. There is no role model because I am not building a corporate document portal. The software is better because it knows what it is not.

Keeping it testable without making it huge

I did not want to review every change made by AI, so the project has Playwright tests defined that validate expected behavior.

That lets me verify the parts that actually matter:

• reader progress resumes correctly
• loading states behave properly
• Escape navigation backs out of comics and folders cleanly
• hidden toolbar behavior stays sane on touch devices

For a project like this, those tests are a good trade. They cover real behavior instead of validating every line of UI code.

Why I like this kind of project now

There is a class of software that used to be just annoying enough to postpone forever.

Not hard. Just annoying. Too many little moving pieces. Too much browser fiddling. Too many half-boring details like CSS, manifests, cookies, local storage keys, and responsive layouts.

This is exactly the kind of thing that becomes much easier once AI can help with the grind while you keep the shape of the system in your head.

I still had to know what I wanted. I still had to decide where the boundaries were. I still had to reject dumb ideas and keep it from growing into nonsense. But turning a clear mental model into working software is faster than it used to be, especially for side projects with lots of glue code.

That is probably the most interesting thing about YACReaderWeb. It is not some grand technical achievement. It is a practical little tool that now exists because the cost of building practical little tools has dropped.

And honestly, that is enough for me.