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.

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.

Hours for a single screen ? Exactly what I'm talking about. The fact you think that's quick is worrying.

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).

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.

As a developer I prefer web tech for UIs, because it's actually a nice toolkit to work with, and has great tooling.

I can easily debug and live edit the UI with DevTools. OTOH in Xcode's constraint-based layout I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses). On Windows I don't even know which of the many UI frameworks is the least deprecated this year.

I would say that accurately describes my experience with CSS. Any selector has the potential to mess up the entire page.

With NSLayoutConstraints, not only does it match my mental model of how layout ought to work, but I know that in a properly-factored layout, constraints can only mess up their local section.

Globals make debugging tough in any context, and I wouldn't blame the language simply for allowing their use.

That's true, but the modern web stack has several solutions to this. If you don't mind "CSS-in-JS", I've been using the excellent styled-components [1] library for my company's React app. I believe Vuejs supports scoped styles out of the box [2]. And if you'd prefer to just write plain CSS, CSS modules [3] will mangle the classnames in your CSS files so you don't have to worry about collision.

[1] https://www.styled-components.com/

[2] https://vue-loader.vuejs.org/en/features/scoped-css.html

[3] https://github.com/css-modules/css-modules

Don't discount the native platforms though, which are still very powerful. Constraint-based layout can be frustrating at first, but I've found it's not noticeably more awkward than CSS after a little experience.

Similarly, it's no worse figuring out how to build a native Windows GUI than it is figuring out what CSS or JS framework to use. Just a bit of research :)

As the development is mostly web driven nowadays, HTML/CSS/JavaScript is something that the most developers tend to already know and thus have crossed the first barriers of entry to this kind of development.

If you know both HTML and a proper UI toolkit, you'll see how insane it is to use HTML for anything else than marking up text. It's like launching a space shuttle to go to the supermarket around the corner instead of just walking. The only thing HTML has got going for it is how easy it is to show 'Hello World' on screen. Anything more complicated than that and it becomes a total horror show, especially compared to how easy to use and simple regular UI toolkits are.

I would argue the exact opposite is true for anything more complicated than 'hello world'

I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps. It turned out that native UI toolkits really are very well suited to building native UIs with minimal effort!

As a native developer I have the exact opposite view. Web development is insanely complicated compared to native. It's a complete jungle of flavour-of-the-day frameworks all designed to make web-development somewhat workable (and all of them failing in some ways.

If you're building a website, you have little choice, but if you're actually building a desktop app it's totally insane to use web based UI.

There’s an irony that people who will drop whatever they’re doing to learn this week’s hot crazy brain-bending quasi-DSL JavaScript framework think that learning Swift is too hard and don’t want to have to learn something new.

I've recently been using Windows Forms with C# again and am amazed at the ease of use, if only they had made styling easy this framework would have been a gold standard for years to come. It's even cross platform too thanks to Mono.

I've written a lot of webforms and do really like it for "quick and dirty" UI's, but it has a lot of limitations that make it a bad choice for non-trivial apps.

Off the top of my head: -styling -resizing (text reflow and re-layout of items is very hard to get right/working) -screen scaling (non-integer, say 150%)

I also found it requires a ton of boilerplate code to programmatically change the UI.

That said, my favourite part is the first class support for events. Knowing this paradigm made my shift to Qt (which has something similar called signals) much easier.

WPF is based on Direct3D 9, and is easily stylable. I consider it is the gold standard. But it is Windows only. There are cross platform alternatives, xamarin, avalonia, but I don't have hands on experience with them.

In contrast, platform-native UI frameworks are absolutely optimised for things like this. There's definitely no difficulty in using hotkeys or windowing functions in Appkit, for example.