Using InfernoJS to render parts of DeltaChat Desktop for massive performance improvement

Feature Proposal
1

Hello!

InfernoJS is a very performant JS framework both on Processor and Memory usage. How about we use it sometime for better performance where there is potential?

It makes sense we use InfernoJs where normalization is costy because InfernoJS can avoid it using certain flags if children shape and type can be known at compile time. For instance, If we know for sure the children is just text, we can have this:

function Example(props: any) {
  return (
      <p $HasTextChildren>{props.text}</p>
   )
}
2

for massive performance improvement

hello, did you benchmark this? could you provide some benchmarking results before and after applying some changes how this really provides a massive performance improvement?

it doesn’t make much sense to refactor a lot of code if it is only a theoretical assumption

1 Like
3

  1. It does not make economic sense to refactor the whole deltachat desktop codebase to use a different framework at this time. (not enough gain compared to the required work)

  2. Inferno JS is too different from react to use them side by side in deltachat desktop.

  3. Inferno JS is less used than React, so less potential Contributors.

1 Like
4

also there are some frameworks like svelte that compile to sth close to vanilla javascript, basically don’t having a framework runtime and no virtual Dom, just updating the Dom surgically where it’s needed, I guess those frameworks would be the fastest, but even those frameworks don’t give enough benefit to justify the work/effort in my estimation.

1 Like
5

I will have to do experiments to see how much is the real benefit. Nevertheless, I am highly confident there will be significant memory usage decrease and performance increase.

Furthermore, what you folks say about refactoring the whole DeltaChat in InfernoJS, is not what this proposal suggests. I am thinking if we could use InfernoJS in certain parts which normalization happens a lot and there are quite a big number of elements.

Regarding benchmarks with other frameworks, InfernoJS for sure beats React in both memory and processor usage according to this benchmark

  1. It’s not about refactoring the whole app. Just some small parts satisfying some metrics such as frequency of usage and normalization.

  2. I wouldn’t be confident about this till someone does some experiments. I’ve asked in the InfernoJS Discord and there are people who are already doing so.

  3. InfernoJS overlaps so much with React, is much simpler, and has so many less features so learning it for new contributors won’t be of a problem IMO.

I’ve posted this on the forum to receive your comments and opinions. So thanks for expressing them, being agreeing ot disagreeing.

6

The question is not generic benchmarks but delta chat desktop relevant benchmarks. There need to be a measurable DC desktop performance problem with react for beginning a discussion about using something else … Weighed against fixing / avoiding the problem in another more pragmatic way. Desktop is a highly evolved product where people rely daily on. revisiting base choices is a very high hanging fruit at this point.

Fundamental changes like eg Simons effort to rebase on delta tauri instead of Elektron address long running complaints and problems (dependency on chromium, bloat, package size) and also pave the way for a web version of DC … And even then it’s not an easy slam dunk.

2 Likes
7

inferno js is very different, in react we mostly do functional components with hook, infernojs only allows pure (just render without state) functional components.
Having additional frameworks much increases code complexity, even if only used for some parts of the app.
Also as far as I understood infernos, you need some babel compiler transpiler to get all the benefits, and that would add more complexity to the build process.

What part of the deltachat desktop application even needs this? Is there a concrete example of sth thats impossible to solve with react?

1 Like
8

Simon’s and Holger’s arguments convince me that this was a bad suggestion.

3 Likes
9

On second thought, this can come back to the table if Linux mobile users complain about performance and we cannot fix it with React.

10

TBH I don’t think that DOM manipulation and rendering is the biggest performance bottleneck of Delta Chat Desktop. I think in most cases it’s the excessive reliance on RPC calls with await, and pure JavaScript utilization, such as excessive memory allocation.
For example, look how many RPC calls jumpToMessage has, or the recent contact lazy-loading MR (to be fair though, the contact list performance actually also had to do with DOM, see this MR).
If one wants to improve performance, I think it’s better to target these areas.

Not saying that Delta Chat wouldn’t be faster if it was written in Inferno from the get go, but yeah.

3 Likes