(Feature request) Transition to React

[Myzel394]

Preflight Checklist

• [X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe feature

Okay this was clickbait. We don't necessarily need to transition to React in short term, but I would strongly suggest transitioning to a framework/library in long term.

The project is starting to get complex. If we keep adding new features (which isn't a bad thing), we will soon lose control over the codebase. Some features could have already been implemented if we had used a framework (translation for example). If speed is a concern, we can also use a fast framework (for example Preact instead of React). But I think it's more important that we can provide good updates and a secure app and I think it's not really that important whether the site loads in 0.2 secs or 0.5 secs.

Btw, Trilium uses a React-like approach with it's TPL variable in every component and it's event handling.

Additional Information

No response

[zadam]

Hi,

Conversion would take a huge amount of time and I'm not even completely convinced if the benefits would outweigh the (potential) negatives.

I think it's not really that important whether the site loads in 0.2 secs or 0.5 secs.

Initial load maybe not, but other than that performance is super important to have good UX and difference between 0.2s and 0.5s is huge in performing actions. I don't doubt that (p)react performs well, but frameworks typically shoehorn you into some particular pattern which might not be the best (most performant) for the particular use case, and you often happen to fight against the framework.

OTOH I understand your reasoning. Custom frameworks are always a PITA for external developers with poor/non-existing documentation. Using some framework might attract some other developers to the project etc.

But ultimately, I don't see this happening in the near/mid term future.

(BTW I reject translation not because of the implementation costs, but because of the continuous maintenance effort required, which would be the case for any framework based solution as well)

[Myzel394]

(BTW I reject translation not because of the implementation costs, but because of the continuous maintenance effort required, which would be the case for any framework based solution as well)

I don't fully understand. Do you mean the need to continously update when the framework updates? If that's the case, that's partially true, because we could use LTS version to avoid always having the need to update to the latest version

[Myzel394]

Initial load maybe not, but other than that performance is super important to have good UX and difference between 0.2s and 0.5s is huge in performing actions

afaik only the initial load is really what's "bad" about using a big framework/library like react. Other subsequent actions won't really be that much slower compared to vanilla Javascript (in terms of UX)

[zadam]

No, it's all the work outside of the localization framework. Creating localization mappings, updating the files, designing all the text boxes with the assumption that the lengths/contents can differ greatly, keeping BC with old strings when doing feature redesigns, dealing with bad/inconsistent translations which I can't resolve, dealing with misunderstandings (bug reports) caused by those bad translations. Another level is dealing with RTL languages, going further in localization (date formats, number formats).

[Myzel394]

I understand your concerns, but this is not a problem with a framework, but with localization itself. I was concentrating on suggesting to transition to a framework. BTW,

Conversion would take a huge amount of time and I'm not even completely convinced if the benefits would outweigh the (potential) negatives.

I honestly can't see any negatives, despite having a (not noticeable) slower app. Otherwise we would create awesome UI/UX and DX.

[zadam]

I understand your concerns, but this is not a problem with a framework, but with localization itself

Yes, my point was that having react or any other framework would not actually help to bring localization to Trilium.

I honestly can't see any negatives, despite having a (not noticeable) slower app.

I don't actually know react that well to be able to effectively judge it. Just my experience with frameworks in general tells me that every single framework represents a trade-off.

[Myzel394]

Yes, my point was that having react or any other framework would not actually help to bring localization to Trilium.

Okay that was a bad example from me :D In general, it will be easier to add new features and fix bugs. (and probably there will be less bugs because React covers many things already)

I don't actually know react that well to be able to effectively judge it. Just my experience with frameworks in general tells me that every single framework represents a trade-off.

Yes that's correct. Most of the time it's speed and performance, but from what I have seen so far, I think that vanilla Javascript is great for small project and React (and Vue) are great for Web-Apps which are complex.

[fidelix]

This would indeed be a big effort, although worth it IMHO.

But ultimately the best person to make that assessment is the maintainer. It would indeed bring in more PRs, which means more effort in maintaining those PRs for zadam, but less time in fixing bugs or adding new features.

I would have collaborated a few things already if trilium was built with a simple framework (ie. definitely not React or Angular). Right now it's a bit daunting and because of that I don't feel motivated to send PRs. I'm sure other people would agree.

Vue or Svelte are super simple and extremely easy to get started with. React codebases are usually complicated explicitly due to the issues Zadam mentioned:

but frameworks typically shoehorn you into some particular pattern which might not be the best (most performant) for the particular use case, and you often happen to fight against the framework.

I agree. This is exactly my experience, which is why I prefer something like Vue or Svelte. They are thin and simple, and anyone who knows JS can get started and actually be productive in a matter of hours.

[eliandoran]

@fidelix , are you still a user of Trilium? We are starting a new organization following the maintenance of Trilium and adapting the client to Svelte would be an interesting idea. I'd appreciate it if you could contribute in any way.

[fidelix]

@eliandoran please send me some info or share some links. I'd like to take a look.

[eliandoran]

@fidelix , really glad to hear that.

Currently we just have a fork org here: https://github.com/TriliumNext (we've just started yesterday) Feel free to browse our discussions and the discussion I've opened relating to this: https://github.com/orgs/TriliumNext/discussions/10

Thank you. :)