Is a fork in Tauri instead of using Electron something possible or not ?

[AkechiShiro]

Hi @zadam, my question is probably not well defined yet to be answered but do you have any opinion ?

However, I have had issues with Electron updates/security and also performance (RAM seems to be cheap nowadays, yes but I prefer software that uses just what's needed)

I haven't tested much Trilium yet however, I would like to try and work on a fork that tries and uses Tauri as best as possible while slowly building the same feature set that trilium has.

However, there are multiples issues :

• Is that something possible and not extremely hard/complex to achieve ?

The benefits of such a rewrite would be :

• Lower RAM footprint
• Security might be improved (but Rust doesn't magically makes everything secure by default)
• Snappier user experience

Disadvantages :

• Major codebase rewrite
• All currently implemented feature may not be possible to implement on the rewrite.
• May fragment users between rewrite and this actual Electron one, which is very bad but seems to happen a lot in the open source ecosystem.

I'm not sure what the new organisation that is forming to help with maintaining Trilium (#4620) thinks about this idea.

@meichthys : Any thoughts ?

EDIT : I do not have enough experience in Tauri to know if this is actually achievable, if I start working on this, I'll probably start a little experiment at best, but if the community isn't interested, it will stay a pet project and nothing more than that, I believe.

[sigaloid]

Without sounding like a Rust fanatic, the idea of a Rust-based Trilium fork does excite me. I've seen a number of bugs related to Trilium caused by the use of JavaScript, things like implicit type conversions that caused problems. Not sure how much tangible value a rewrite would provide, but if there's already an effort to fork, it could be considered more seriously.

[zerebos]

It is technically possible to use Tauri as opposed to Electron for a project like Trilium. However to go from Electron to Tauri in this specific case would take a lot of work. There's so many things within Trilium that depend on things all being in the same ecosystem and having access to the same modules.

As for the potential benefits, certainly there would be a lower memory footprint, but it would not make that much of a difference for the user experience. In the end you are using a web interface in both cases, the "backend" so-to-speak of Electron is not causing lag.

It would be more realistic to tackle something like this in parallel with the fork moving forward if the fork also became more modularized and self-contained. Meaning, the frontend, backend, sync protocol, etc, would all be defined like an API so they could be swapped out for different modules. (Think like Vaultwarden being a rust-based Bitwarden compliant alternative).

As for if it would be a good idea to tackle going forward, I'd have to say probably not. Or at least, not in the short term or even as a high priority long-term goal. Specifically with Trilium, there wouldn't be such a huge benefit to using Tauri that it would be worth the massive effort to rewrite everything as well as causing the fork to diverge heavily from the source which would prevent the fork from benefitting from bugfixes and such.

[sigaloid]

I agree - your fork idea sounds very feasible - something like a flexible backend that can deliver content to a frontend of any kind (so we could use a web frontend if desired, or maybe a more efficient native GUI, etc) would be very cool. 🤔

[meichthys]

I agree strongly with @rauenzi on this.

[rom1dep]

FWIW, I primarily use Trilium through a web browser (so I can access and manage my notes on devices which are not mine), and I'm not quite sure what benefits Tauri would bring in that context. AFAICT, Tauri still is a web platform, so every (local) Tauri app still ships the hefty parts of a web browser (the renderer, the DOM, implementations for all kind of "Web APIs", … ; i.e. most things BUT the highly optimized JS interpreter).
I guess it's a convenient escape hatch into the native world for when the performances of V8 no longer cut it, but that's a problem the vast majority of projects will never face (and I suspect Trilium is no exception there).

Bringing types to the Trilium codebase (via Typescript or other languages compiling to JS/WASM) is probably not a terrible idea, and this could be accomplished incrementally, but I think I recall Zadam making the case for simplicity and keeping the project approachable to most developers, and that's probably the kind of spirit to keep around in the early days of the spin-off project.

[zerebos]

AFAICT, Tauri still is a web platform, so every (local) Tauri app still ships the hefty parts of a web browser

Tauri, like several other Electron alternatives, uses the system's webview to do the entire frontend environment and does not bundle the browser. This means that the desktop bundle of Trilium would not have a consistent platform (like chromium with Electron) and would instead have to deal with the quirks of each OS.

Bringing types to the Trilium codebase [...]

I think types could be interesting, but for me i18n would be higher priority. But that's perhaps best saved for a discussion within the GitHub org when it's made.

[zadam]

Trilium (the desktop client) depends on Electron specific APIs, but it's not a crazy dependency - the server edition after all works just fine. So I imagine, getting basically the server edition working within Tauri (or any other shell) shouldn't be very difficult. Perhaps one question is about SQLite (the only binary dependency) which needs a special build for Electron, I don't know how this is being dealt with in Tauri.

Having said that, I personally don't see a lot of value in switching to Tauri. It's a much more niche platform, which might become a problem in the future, it means less support etc. And I don't plan to do any such major changes anyway.

[Dialga]

Another frontend to consider is webui, with webui you would only have to depend on having a browser installed versus tauri which requires webview and webkitgtk.

[iilyak]

One more option is https://dioxuslabs.com/learn/0.6/guides/desktop/ although I agree with others that migration would likely be a full rewrite.

[eliandoran]

Starting with TriliumNext we have fully ported the server to TypeScript. There are no plans to move over to Rust.
We might be looking at webview-based solutions, but the space gain is not that high since we still have to ship Node.js with it.