[jquintard]

The iOS app is native Swift. The desktop app is in Electron.

But we've taken another approach for the Electron app not to become as slow as Slack or Notion. We know many people complain about that.

To give just one example. The parser in our console has not been written manually in Javascript. Instead we wrote it in Ocaml (https://ocaml.org/) and we generate the Javascript. This allows us to have a code that is more reliable, maintainable and faster.

We do the same for many other parts of the product exactly for that same reason.

[mromanuk]

Speed is not the problem with JS and Electron, it's the broken UX and expected behavior from a native app.

I've installed it and before moving it to my app folder, I tried to run it (I always do this with new apps). A popup appeared with the title "A JavaScript error occurred in the main process" (weird behavior), I didn't read the content at first, so I closed it and reopened the app again (fast fingers reached cmd-q). Later I read the message asking to move to the App folder first.

[yunohn]

As an aside, JS does definitely make things feel slower than native in some instances. Regardless, how does generating JS from OCaml make things faster, I wonder?

[mefyl]

I think our app is as reactive as a native app despite javascript; if you see any lack of responsiveness I'd be interested in knowing where so I can improve it. I do however agree that it "feels" different on OSX, since you don't have the native animations and look & feel, but I don't think it's related to speed.

Regarding OCaml, using such a strongly typed language enables heavy abstractions without a runtime performance tradeoff, leverages the static optimizer of the OCaml toolchain and outputs optimized javascript (asm like). This is, I would argue, hardly achievable by writing directly plain javascript. Note however that there are other tools that target javascript with similar benefits.