RichEPub Was the Wrong Layer to Reinvent
The custom-format experiment was useful, but the active direction is better EPUB3 tooling rather than a new container.
RichEPub started from a real frustration: I wanted books to feel more like designed software. React components, richer layouts, better author tooling, and a cleaner path from draft to reader all sounded like reasons to invent a new container.
After pushing on it, I do not think the container is the real problem.
EPUB3 already describes more of the book than I first gave it credit for. It is HTML, CSS, packaged assets, metadata, and a structure that normal readers already understand. There are limits, but there is not much in the current project that truly requires a brand-new runtime format.
What actually hurts
- The source material is messy.
- Books do not begin in one clean authoring format.
- In this repo alone the path has already been
Notion -> markdown -> MDX. - If this ever grows, it will have to deal with even more input shapes and editorial cleanup.
That means the real work is not inventing a new ebook file type. The real work is building better authoring and transformation tools that can take uneven source material and compile it into cleaner EPUB3 output.
Where the experiment landed
The useful idea inside RichEPub was never "ship a .repub file everywhere." It was:
- create a stronger writing UI
- make layout choices explicit
- support custom components where they can still degrade cleanly
- compile the result into standard EPUB3 instead of asking readers to adopt a new format
If I build more in this direction, it will likely look less like a new spec and more like a React and Node based editor pipeline with structured export rules.
The more realistic next step
A better system would be something closer to a writing tool:
- lexical or another structured editor for authoring
- component-driven page blocks for images, callouts, and ornamental layout
- import paths for Notion exports, markdown, and MDX
- an export layer that compiles those decisions down to EPUB3 without leaving a pile of manual cleanup at the end
That is still a lot of work, and it may be more hassle than it is worth. But if there is a meaningful next step here, it is that. Not a new container.
The RichEPub posts stay up because the experiment was useful. The active direction is EPUB3-first tooling, better editorial workflow, and better reader presentation on top of standard output.