Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X.
I don't think Electron a good match for this project, which while fast during use, probably has horrendous startup times and memory usage. But I can certainly understand the sentiment pushing developers into Electron and driving them to avoid multiple native applications like the plague. I have developed and deployed custom Eclipse environments that supported Windows and Linux, with a mix of Java and C/C++. It costed me years out of my life.
But a project like this specifically seems to have most of the secret sauce implemented in a cross-platform library. That seems to be to be a great application structure and candidate for native UI implementation. It increases the development effort from n+m to 3n+m, where n is hopefully much smaller than m.
> Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X.
No, it won't. Building any non-trivial UI in HTML takes orders of magnitude more effort and time than building it in a UI toolkit that was actually designed to build user interfaces in.
I can put together a full HTML/CSS/JS UI for a screen in hours where it will take me days to do it on Android or iOS alone, ignoring the fact that I'd have to make sure it's responsive on all those platforms anyway (because tablets), then still build it for windows, linux, mac, and sometimes a web version anyway.
You are the second person to say this, what are you doing that's faster?
I'm talking from start-to-finish creating the UI, wiring into business-logic, handling UI state, making it fully responsive, etc...
I've used WPF, QT, some old java swing stuff, and the Android studio layout editor, and none of them are a fraction as fast and capable as a well setup react web application (which to be fair, took a good chunk of time to setup).
Sure, because the browser will go out of its way to render something sensible out of any tag soup thrown at it, as opposed to throwing an exception like native frameworks do.
If you are including the wiring of the UI into the application in that time I'm impressed, however you still will need to do another 3 major platforms.
And you'll need to have a designer look them over or design them in the first place for each platform, and write documentation for each platform, and test each platform, etc...
In many cases I won't argue that a native app won't be better for the user in many ways, but you can't argue that it's faster to re-create, document, and test your UI 5 different times.
I don't think Electron a good match for this project, which while fast during use, probably has horrendous startup times and memory usage. But I can certainly understand the sentiment pushing developers into Electron and driving them to avoid multiple native applications like the plague. I have developed and deployed custom Eclipse environments that supported Windows and Linux, with a mix of Java and C/C++. It costed me years out of my life.