Zathura can use mupdf as a backend. You get the same rendering speed but an interface that doesn't suck and it works for epubs and pdfs.

I just tried Zathura but found it did not support EPUB where mupdf has no problems with that format:

$ zathura Books/nonfiction/English/Douglas_Murray/Douglas_Murray-The_War_on_the_West-2022-HarperCollins-English.epub

error: Could not determine file type.

This is the version currently on Debian/Sid, with all packages installed (zathura, zathura-ps, zathura-djvu, zathura-cb). I also noticed zathura renders PDF differently (and noticeably slower) compared to mupdf. It does not use mupdf as a backend, instead depending on libpoppler:

Depends: libc6 (>= 2.4), libgirara-gtk3-3 (>= 0.2.7), libglib2.0-0 (>= 2.16.0), libpoppler-glib8 (>= 0.18.0), zathura-abi-4

Which version of Zathura do you have installed?

[edit]

Checking around I noticed that Zathura can use mupdf as a backend but this is not enabled in the build currently on Debian/Sid. It is available in e.g. Arch [1] but Debian does not package this part. I'll build it myself and give it a try.

[1] https://archlinux.org/packages/?name=zathura-pdf-mupdf

I use both MuPDF and Okular, which is much better than using only one of them.

MuPDF is very noticeably faster than Okular, so I use MuPDF for most cases when I just want to read quickly a PDF file or search through it. Therefore MuPDF is the default application for opening a PDF file, because it opens the file instantaneously, saving me a lot of time when I browse through many PDF files.

Whenever I find a PDF file with which MuPDF has difficulties or I need a feature available only in Okular, I use Okular.

Okular also pulls in a sizeable part of KDE as dependencies:

Depends: kinit, kio, libc6 (>= 2.33), libfreetype6 (>= 2.2.1), libjpeg62-turbo (>= 1.3.1), libkf5activities5 (>= 5.68.0~), libkf5archive5 (>= 5.68.0~), libkf5bookmarks5 (>= 5.68.0~), libkf5codecs5 (>= 4.96.0), libkf5completion5 (>= 5.68.0~), libkf5configcore5 (>= 5.68.0~), libkf5configgui5 (>= 5.68.0~), libkf5configwidgets5 (>= 5.83.0), libkf5coreaddons5 (>= 5.68.0~), libkf5crash5 (>= 5.68.0~), libkf5i18n5 (>= 5.68.0~), libkf5itemviews5 (>= 4.96.0), libkf5jobwidgets5 (>= 4.96.0), libkf5kexiv2-15.0.0 (>= 5.68.0~), libkf5kiocore5 (>= 5.69.0), libkf5kiowidgets5 (>= 5.69.0), libkf5parts5 (>= 5.68.0~), libkf5pty5 (>= 5.68.0~), libkf5purpose-bin, libkf5purpose5 (>= 5.68.0~), libkf5service-bin, libkf5service5 (>= 4.96.0), libkf5textwidgets5 (>= 5.68.0~), libkf5wallet-bin, libkf5wallet5 (>= 5.68.0~), libkf5widgetsaddons5 (>= 5.77.0), libkf5windowsystem5 (>= 5.68.0~), libkf5xmlgui5 (>= 5.80.0), libokular5core9 (= 4:21.12.3-2), libphonon4qt5-4 (>= 4:4.8.0), libpoppler-qt5-1 (>= 21.11.0), libqmobipocket2 (>= 4:17.08~), libqt5core5a (>= 5.15.1), libqt5dbus5 (>= 5.14.1), libqt5gui5 (>= 5.14.1) | libqt5gui5-gles (>= 5.14.1), libqt5printsupport5 (>= 5.13.0~), libqt5texttospeech5 (>= 5.12.0~), libqt5widgets5 (>= 5.15.1), libqt5xml5 (>= 5.13.0~), libspectre1 (>= 0.2.3), libstdc++6 (>= 11), phonon4qt5, zlib1g (>= 1:1.1.4)

Compare this to mupdf:

Depends: freeglut3 (>= 2.8.1), libc6 (>= 2.33), libfreetype6 (>= 2.6), libgl1, libgumbo1 (>= 0.9.2), libharfbuzz0b (>= 0.9.11), libjbig2dec0 (>= 0.19), libjpeg62-turbo (>= 1.3.1), libmujs1 (>= 1.0.7), libopenjp2-7 (>= 2.0.0), libssl1.1 (>= 1.1.0), libx11-6, libxext6, zlib1g (>= 1:1.2.0)

If you're already using KDE Okular is a natural choice. If you're not there are better alternatives, e.g. Atril for Mate-users, Evince for Gnome users and, yes, mupdf for those who do not use any "desktop environment". Those who use older hardware (like me) appreciate the nimbleness of tools like mupdf. It also fits in perfectly when using a tiling window manager (Xmonad etc) as it does not have any UI elements getting in the way, only showing what you're actually interested in. It supports (according to the man page) PDF, XPS, EPUB, XHTML, CBZ, and various image formats such as PNG, JPEG, GIF, and TIFF.

This is akin to vi vs VS-Code, to each his own I'd say.

This is how I finally gave in to using FlatPak. I wanted Okular, but also wanted the rest of the QT stuff it's own little sandbox as I wasn't using it anywhere else.

I did the AppImage thing for a while, but it was too difficult to keep up to date without the developers prodiving that themselves.

Side Note: Flatpak is actually pretty nice, the lengthas I went to avoid it were pretty unreasonable in retrospect.

I want the opposite - the Unix way: just one copy and one (latest release) version of every library my apps use, one theme for all the apps using the same toolkit rather than every app bundling their own version/instance.

Same here, I have yet to find a containerised application platform which fits my ideas of how to build a system. A sensible package manager with a reliable dependency graph - or plain old apt with judicious use of deborphan - goes a long way in allowing the installation of applications with a number of dependencies, testing it and removing all traces of it afterwards. Containers have their use but Flatpak and Appimage have not hit the right spot for me, at least not yet.