Console #192 -- Interview with John of Foliate, an e-book reader for Linux
Console #192 -- Interview with John of Foliate, an e-book reader for Linux
Featuring Shoelace, GitUI, and Celestia
🤝 Sponsor
This space is reserved for sponsors that support us to keep the newsletter going! Want to support Console? Send us a note at osh@codesee.io
🏗️ Projects
Browse through open source projects on OpenSourceHub.io, add your project to get more exposure and connect with other maintainers and contributors!
Shoelace
A collection of professionally designed, every day UI components built on Web standards. Works with all frameworks as well as regular HTML/CSS/JS.
language: TypeScript stars: 11081
repo: github.com/shoelace-style/shoelace
site: shoelace.style
GitUI
Blazing 💥 fast terminal-ui for git written in rust 🦀
language: Rust stars: 15984
repo: github.com/extrawurst/gitui
Celestia
A real-time space simulation that lets you experience our universe in 3D.
language: C++ stars: 1567
repo: github.com/CelestiaProject/Celestia
site: celestiaproject.space
Foliate
Read e-books in style. Foliate is an e-book reader for Linux.
language: JS stars: 4692
repo: github.com/johnfactotum/foliate
site: johnfactotum.github.io/foliate/
Join thousands of other open-source enthusiasts and developers in the Open Source Hub Discord server to continue the discussion on the projects in this week's email!
🎙️ Interview with John of Foliate, an e-book reader for Linux
Hey John! Thanks for joining us! Let us start with your background.
I became interested in building websites when I was quite young, but I never had any formal programming education and was mostly self-taught. Probably related to this, I seem to have an aversion towards complicated frameworks and prefer the more artisanal or what one might even call amateurish approach to development. I started out with PHP, but I’ve forgotten most of it at this point. Now I use JavaScript unless I have no choice, mostly simply out of familiarity, and also because of its ubiquity. But I also like how dynamic and expressive it is, particularly how easy it is to define anonymous, first-class functions.
What’s your most controversial programming opinion?
For JavaScript, I prefer four spaces for indentation and no semicolons. In my humble opinion, two space indentation is terrible. It’s too small. It makes everything unreadable. And adding semicolons requires extra keystrokes for very little benefit, and it also adds noise when reading the code. Unfortunately, I seem to be in the minority. For some reason, people who use four spaces seem to like semicolons (the classic Crockford style), and people who don’t use semicolons tend to prefer two spaces (Standard style). And then the most popular Google/Airbnb style uses two spaces and semicolons.
What is your favorite software tool?
GNOME Text Editor. Many people like to use fancy editors or IDEs, but personally I love the simplicity of working in a simple text editor.
Why was Foliate started?
I wanted to open EPUB files, but the existing projects were all lacking. I chanced upon Marta Milakovic’s blog, where she talked about the Google Summer of Code project where she was developing an e-book app for GNOME using WebKitGTK and Epub.js (as far as I know, that work was never really finished or released). So I decided to try building my own app with Epub.js in a WebView. And that’s how Foliate started.
How does Foliate work?
Foliate is a GTK app written in JavaScript, using GJS. It uses a WebKitGTK WebView for rendering the contents of the e-book. Previously, it used Epub.js, but now it has its own renderer called foliate-js, which is available as a separate library and included in Foliate as a git submodule. The renderer works similarly to Epub.js: it’s completely client-side and serves the contents in iframes with blob URLs, and it uses CSS multicolumn to handle pagination.
Why did you pick GTK?
I chose GTK mainly because I have personally been using GNOME and other desktop environments in the GTK ecosystem. GTK has bindings in many languages, and JavaScript was the one I was most familiar with.
Where did the name for Foliate come from?
The name was derived from “folio”, which means “leaf”, a term with various meanings connected to books and printing. The concept of a leaf, as illustrated in Foliate’s icon, is also related to the practice of drying and preserving leaves in books, where the leaf could also serve as a bookmark.
Are there any overarching goals of Foliate that drive design or implementation? If so, what trade-offs have been made in Foliate as a consequence of these goals?
I would say the biggest goal is simplicity, even if it means sacrificing efficiency or functionality sometimes. For example, unlike most other e-book apps, Foliate uses flat JSON files instead of a database. This makes everything dead simple, but without indexing, you can’t query the data efficiently.
What were the existing projects lacking that made you consider building something new?
I wanted something that (1) integrates well with the GNOME desktop, (2) is a “file viewer” that doesn’t require importing/copying/modifying files, (3) with a simple and distraction-free UI.
What was the most surprising thing you learned while working on Foliate?
I’m surprised at how often people (myself included) neglect to read specs carefully when implementing various standards. For example, EPUB has a spec called CFI (Canonical Fragment Identifiers). Recently, I did a quick review and discovered that most libraries and apps have incorrect CFI implementations. Another example is that I recently reimplemented OPDS support in Foliate, and I was surprised by the mistakes I made in the old version related to not reading the relevant specs. It’s easy to assume that things are correct if you’re just looking at a few examples, but sometimes even the tests could be incorrect or fail to cover some edge cases.
Is Foliate intended to be eventually monetized?
I started accepting donations recently. In the future I’m thinking that it could become pay-what-you-want similar to how elementary OS and elementary apps work today.
How did the project get popular?
It received some initial attention after it was made available on Flathub, and after that it was picked up by a couple of blogs and on Hacker News. The people behind Flathub and the GNOME ecosystem have done a terrific job enabling developers to distribute apps and reach users easily.
Have you ever experienced burnout? How did you deal with it?
Taking a break helps. But it’s easy to feel restless when you remember that there are people out there using and possibly depending on the app. So I try to remind myself that per the license, the app comes with absolutely no warranty, which certainly helps me sleep better at night.
If you plan to continue developing Foliate, where do you see the project heading next?
I would like to make a version of Foliate with only Web technologies, such as a progressive web app, a WebExtension, or possibly an Electron app. This will make it available on more platforms, especially on Windows where there doesn’t seem to be many e-book apps available, particularly since the demise of EPUB support in Edge (unlike say, macOS, where there’s Apple Books).
What motivates you to continue contributing to Foliate?
Mostly because I use it myself, but I’d also like to think of it as building something that helps the dissemination of knowledge, which makes me feel like being part of something greater than merely maintaining a simple utility app.
Where do you see software development heading next?
Most answers to this question today would probably include the word “AI”. The common adage is that code is read far more often than it is written. Right now there’s a lot of emphasis on AI writing the code but far less on reading the code. It would be interesting to see how AI could be used to grapple with the increasing complexity in software.
Where do you see open-source heading next?
I think the GNOME people have worked hard to build an ecosystem, and we’re starting to see a sort of Renaissance of indie apps on the platform.
Do you have any suggestions for someone trying to make their first contribution to an open-source project?
I would say: start small. It is a capital mistake to try to bring big changes without engaging with the maintainer first. Even more often, people are discouraged from contributing due to the sheer size or complexity of the codebase. In these cases, it helps to start small and move gradually from there.
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at osh@codesee.io or mention us @ConsoleWeekly!