Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.

Such a pity that WPF was never ported to other platforms That's a UI framework that was done right in my opinion. Fast, incredibly flexible and sane.

That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.

Avalonia is a decently nice cross platform C# + XAML GUI toolkit. It doesn't cover every use case WPF does, of course, but I've still found it pleasant to use.

It also suffers similar problems to the one posted here (or at least used to), an idle app will consume quite a bit of CPU.

A WPF app is just a .Net app. I can't recall the problem described ever having been an issue.

AppKit/Cocoa is very good too, if not cross-platform. Consistent, dynamic, extensible, and there's so much your apps get for free, and new features often become retroactively available for past apps, like when NSDocument got autosaving, and now tabs for multi-document apps, the wide-gamut-aware color pickers and so on.

A project I've been keeping my eye on is libui (https://github.com/andlabs/libui), it's basically a thin wrapper around the native libraries (very SWT like) that can be used in a number of languages.

I have done both and I am not at all a fan of QT.

If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF.

Also the Qt community is minute compared to the JS community, that is significant.

"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants."

Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.

> Use the right tools for the job

i wonder if this expression constitutes a thought-terminating cliché.

It sounds a bit like one, but I think the point is that while the web can be used for everything, that doesn't mean it should. Like if we built XML into filesystems directly, instead of doing it just in the layers above.

It does, inasmuch as objective metrics for "correctness" don't exist in our field. The best we can do is show "incorrectness." It's absurd to say, "My tool is correct and therefore should be used," when all we really can demonstrate is, "My tool lacks these specific deficiencies I can identify in another choice."

This bug comes nowhere near demonstrating that Electron or VS Code or Atom are built incorrectly or incorrect tools

> Trying to shoehorn everything into "the web"

'Trying to shoehorn' is just your opinion.

> Use the right tools for the job.

What does that non-sequitur even mean in this context? Use a different native platform to write each native version of the app? That simply isn't viable for anything but very large companies.

Or should I use Qt, with it's tiny support community?

Also why is React/React-Native not 'the right tool'?

> [...] just as shitty as the web.

Again your opinion. In my opinion the web is a joy to work on compared to the cesspool that is native app development.

It's unfortunate that your opinion–that of the two most successful programmer's editors currently in use today are doing something right–is being heavily downvoted by people who object to the "web" invading on their territory for reasons unknowable.

"Eating too many CPU cycles while idle" is a problem many, many text editors have faced. It's purely an unfair bias in this case that this is justification for trying to invalidate the project.

By the way, if you'd like to really throw a stick into Qt proponents spokes, ask them what sort of accessibility story QT has for custom rendering components. Ask, "How can I support a colorblind or legally blind person with this component?"

Qt's developer story here is not nonexistent, but it throws into sharp contrast how _complete_ the web is from the perspective of accessibility for people who need auditory assistance or do not use conventional input devices.

Yes it is sad that it is one of those topics that HN users seem incapable of discussing objectively. Meanwhile Electron usage grows and grows, and will continue to until someone comes up with a viable alternative.

If you disagree, tell me what I should use instead of Electron, that is feasible to use for a small team to have a wide platform reach, and with a community comparable to even just the 'React' part of web dev.

The drive-by downvotes really just prove my point.

Yeah, thought so.

If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform, are generally slow, massive to distribute, don't integrate well with other applications and generally have weird non-native-app-like behavior. Like Discord I can resize and have the minimize/maximize/close buttons overlap the window. Atom and VS Code still can't do DPI scaling right. I wouldn't say you can build good desktop apps with them. Just crappy little ones. Maybe that's necessary to interact with one library or another, but that's a tradeoff. And a big and important one to recognize.

Maybe React Native will work on desktop and fix all this eventually, but IMO React Native is just not there yet, it doesn't even feel native on mobile.

I say this as someone who writes both an app with both an Electron/React portion (in order mainly to interact with a specific JS library) and a Qt portion. I really do like the way React does a lot of things and npm seems like the exact right way to do package management in a programming language - but the JS ecosystem is a mess. While I'll agree the wealth of developers on it has had many good results, it's also created a horrible moving target. There are half at least 5 different and fairly popular module systems, module loaders, etc. There are constant attempts to use language features which aren't official yet or even at a final spec via babel. The build and packing systems are a mess, everyone has their own different series they prefer and getting working integration between a few can be problematic.

> If you're meaning to say you can write "multi-platform desktop" apps using Electron... I suppose you're technically correct, but they don't feel native on any platform,

You know, people say this, but I'd like to push back on it. "Platform native feel" is not something that I think most folks care about. You may need it if you're looking to ship an app for a pay-for-a-copy model, but the vast majority of computing hours people spend are already mitigated by their web browser of choice, and that seems to not really cause any substantial problems.

Electron is a flawed framework for building an app, sure, but you could argue Cocoa or Windows Universal are equally flawed in many ways. They also require a lot more code to get equivalent layouts, are almost never very good at reactively resizing (you may say it doesn't matter, I say I unplug in an external monitor and expect to have something sane happen). The fact that a bug exist causing repeated simple draws to be more expensive than expected is normal for text editors. You can find issues caused by similar problems in Sublime, Emacs, and even Notepad++.

Maybe it's just me, but I always avoid apps that don't integrate well with my platform. They're just not pleasant to use. I want the same look and feel, I want the same file browser, I want the same DPI scaling my desktop uses and I want the same UI standards followed, not some giant mess of whatever every individual dev decides seems nice that day.

I'm not so sure it's mitigated by the web - people may browse Facebook and a few news sites, but those aren't complex applications at all and they have very simplistic UIs that don't attempt to imitate familiar desktop controls or to show desktop concepts like files and folders.

I have far more problems with Electron app sizing than I do with proper desktop apps - see my examples above.

> I want the same DPI scaling my desktop uses and I want the same UI standards followed, not some giant mess of whatever every individual dev decides seems nice that day.

You must not use OSX native apps then with multiple monitors then. They don't work right (at least not for me!) One of the reasons I use Chrome for so much is that when I change my workspace (as someone who does both coding and project management this is increasingly a requirement) I don't want my UI to clip off the frame unrecoverably or render as a blurry mess.

> I'm not so sure it's mitigated by the web - people may browse Facebook and a few news sites, but those aren't complex applications at all and they have very simplistic UIs

You should look at the Chrome Web Store. But... also... "Facebook?" "Simplistic?" Simplistic is hacker news, where I can't use an Emoji.

> that don't attempt to imitate familiar desktop controls

One last thing: this is much more a sign of the current UI style of the time, and is very much a product of a post iPhone world where unique visual styles are expected. Even then, a text editor is such a specialist piece of work even native apps struggle and cheat, doing things like avoiding sheet animations and providing unique UI and UX components. Native apps have been introducing their own file hierarchy and multi-modal buttons since the time of emacs.

As someone who maintain other peoples code I really don't look forward to deal with js a few years from now:

What build system did they use?

Where is that package? Does it even exist anymore.

Etc.

Had similar problems trying to maintain a delphi project as an almost fresh from scool developer. At that point I understood the value of Java and Maven.

It's true, but there is an interesting mitigating effect here. If at some point you come across an old project that appears to be a product of herculean effort, note that these days its a matter of a few days effort.

The platform that JS is based upon moves incredibly fast.

Typically in Javascript, you would use npm's package.json for building, or you would use npm to install some well defined version of some build system, like you do for other packages. Like Maven builds, it works smoothly and predictably.

js community is filled with 20-somethings with ADHD (i'm 26) that reinvent the wheel every 2 weeks instead of helping polish other projects.

Seconding Qt, there's a bunch of bindings for non-C++ languages as well. It hits the uncanny valley sometimes but overall it's much better than the alternatives (like WxWidgets).

wxWidgets has improved a lot, give it a try.