Constructive Feedback on Trilium’s Architecture

[pyz0123-cpu]

Hi, and thanks again for all the work you’ve put into Trilium. It’s a powerful tool with a strong internal model, and I genuinely enjoyed working with it. I even ended up improving my Python skills by building a notebook‑switcher to work around some of the limitations — so I definitely learned a lot along the way. I wanted to share some constructive feedback from the perspective of someone who uses multiple notebooks and publishes content to the web. I hope this helps the project evolve, because there’s a lot of potential here.

1. Multiple notebooks. Right now, switching notebooks requires renaming directories or using command‑line flags. 1998 called — they want their workflow back. A simple “Open Notebook” dialog would make this feel like a modern desktop app.

2. No blank notebook option. Every new notebook starts with demo/system content. Sometimes users just want a clean slate without having to delete the welcome tour.

3. Desktop vs. server mode. The desktop app feels like a thin wrapper around the server version. Desktop users end up feeling like second‑class citizens, even though many rely on the desktop workflow.

4. Hidden notes appear in exports. Hidden notes still show up in the static HTML export, which can expose internal or system notes unintentionally.

5. Parent notes become folders. Parent notes turn into directories instead of pages, which breaks navigation and makes the exported structure incompatible with most static site generators.

6. Exported HTML navigation doesn’t collapse properly. Some branches collapse, others don’t, and the behavior doesn’t match the desktop UI.

7. Themes don’t carry over. The dark mode theme and custom CSS don’t apply to the exported HTML, so the published version looks nothing like the notebook.

8. Inflexible data directory. Requiring the data directory to be named and placed in a specific location makes it difficult to manage multiple notebooks or organize content flexibly.

9. Static HTML export isn’t suitable for real web publishing. This was the biggest challenge. The export works as a local viewer, but not as a deployable website. Internal note IDs break links, parent notes aren’t pages, hidden notes leak through, and the structure doesn’t map cleanly to any modern publishing pipeline. To be clear: none of the current export options (HTML, static HTML, or “web publishing”) produce output that can actually be published on a real web server. They all rely on local behavior and internal routing that doesn’t function once the files are hosted online. To be fair - there probably is no software that does that correctly right now. However, the “web publishing” export this software has behaves like a local HTML viewer wearing a trench coat pretending to be a website. It works fine on your own machine, but the moment you upload it to a real server, the whole disguise falls apart. In short: the internal architecture is powerful, but the export and notebook‑management model feels stuck in an earlier era of desktop software — great for server technicians, but challenging for end‑users who expect modern workflows.

Thanks again for your work — I appreciate the tool and wanted to offer insights from a publishing‑oriented workflow. I recognize the hard work that has gone into Trilium, and working with it locally was genuinely enjoyable. The challenge for me is that I can’t share my work with others in a clean, reliable way unless they also install Trilium. That limitation ultimately pushed me to explore other options, but I wanted to share this feedback in case it’s helpful as the project continues to evolve. Please take this feedback for what it is indented to do - help grow the project.

[eliandoran]

Multiple notebooks. Right now, switching notebooks requires renaming directories or using command‑line flags. 1998 called — they want their workflow back.

This has been already requested. Your request makes sense, but there's a reason why Trilium was made that way; it's supposed to be a personal knowledge base, so in the ideal use case you're not supposed to have multiple databases. Zadam recognized the need to separate things, such as work vs. personal notes, which is why he introduced workspaces.

No blank notebook option. Every new notebook starts with demo/system content. Sometimes users just want a clean slate without having to delete the welcome tour.

This is a sensible request. I believe there is already a feature request for it.

A simple “Open Notebook” dialog would make this feel like a modern desktop app.

Sounds simple, but in reality there's a lot of effort involved.

Desktop vs. server mode. The desktop app feels like a thin wrapper around the server version. Desktop users end up feeling like second‑class citizens, even though many rely on the desktop workflow.

Can you offer more details why you are feeling that way? Actually a lot of effort was put into the desktop application, especially on getting it to look better on various platforms (macOS, Windows). I would say that most of the user base actually uses the desktop application more than the server version.

Hidden notes appear in exports. Hidden notes still show up in the static HTML export, which can expose internal or system notes unintentionally.

I believe you have already reported this, we'll take care of the bug.

Parent notes become folders. Parent notes turn into directories instead of pages, which breaks navigation and makes the exported structure incompatible with most static site generators.

Not sure exactly what the problem described here is. Sub-directories make for beautiful/clean paths such as this: https://docs.triliumnotes.org/user-guide/advanced-usage/sharing/static-html

If you mean the export structure for Markdown files, which can impact static site generators, perhaps that can be solved but not sure of the effort involved.

Exported HTML navigation doesn’t collapse properly. Some branches collapse, others don’t, and the behavior doesn’t match the desktop UI.

Haven't heard this before. Might be worth opening a bug with more details.

Themes don’t carry over. The dark mode theme and custom CSS don’t apply to the exported HTML, so the published version looks nothing like the notebook.

This is a normal and expected behaviour. The themes and custom app CSS are app-specific. Exports (including share) are a separate concept. Even if we were to add the CSS into the export, most likely they wouldn't match the structure.

You can customize share/export static HTML to add some custom CSS, although I don't think that process is documented. You can create completely different static HTML templates, if you wish.

Inflexible data directory. Requiring the data directory to be named and placed in a specific location makes it difficult to manage multiple notebooks or organize content flexibly.

Isn't this the same as the first one? 🤔

Static HTML export isn’t suitable for real web publishing. This was the biggest challenge. The export works as a local viewer, but not as a deployable website. Internal note IDs break links, parent notes aren’t pages, hidden notes leak through, and the structure doesn’t map cleanly to any modern publishing pipeline. To be clear: none of the current export options (HTML, static HTML, or “web publishing”) produce output that can actually be published on a real web server

That's not really true, actually. Exporting with "Static HTML for web publishing" works. It's literally what https://docs.triliumnotes.org/user-guide/ does, it's a static website running on Cloudflare Pages. What web server are you using and what's your configuration?

[pyz0123-cpu]

Thanks for the clarifications — that helps a lot. A few quick notes from my side:

Multiple notebooks / data directory
I understand the single‑notebook design. My workflow involves several separate knowledge bases, so switching by renaming folders or using flags works, but it feels more like a workaround than a desktop‑style workflow.

Blank notebook
Good to know it’s already requested. A clean‑slate option would be helpful for experienced users.

Desktop vs. server
Not meant as criticism — just an observation about how some desktop expectations behave differently because of the server‑based architecture.

Hidden notes in exports
Appreciate that this is being looked at. It can surprise users who assume “hidden” means “excluded.”

Parent notes as folders
My comment was specifically about Markdown export and static site generators. Many SSGs expect each page to be a file rather than a directory, which can create friction when publishing — I ran into that myself.

Static HTML export
I might be mistaken, but the Trilium User Guide repo looks like it’s built with MkDocs Material rather than the static HTML exporter, so I wasn’t sure it was meant as an example of that pipeline. If there’s a recommended workflow for publishing the exported HTML directly — something that produces ready‑made static web pages I can drop onto GitHub Pages — I’d be interested. All my attempts so far have resulted in output that wasn’t actually publishable.

Overall, none of this is meant as criticism — I just want to share the practical friction points I hit while using Trilium for multiple notebooks and publishing. As a personal knowledge base it’s wonderful. As a multi‑notebook tool or a source of web‑ready, publishable output… not so much.