The aspects you mention mostly make things easier for the developer side, not for the user side, which get only the indirect advantage of a more feature rich app.

If you want to do things properly, you hire separate teams who do native development for each platform, or you hire one Qt team for desktop and two teams for the two app platforms. Of course that's expensive, but again developer vs user side. That's what I mean by cutting corners.

And regarding electron there are different kinds of apps performance wise, like Atom vs VS Code. Discord is more on the Atom side of things, sadly.

Discord is also so big, that interested people develop lean third party clients for it. It's possible, but Discord rather bans them and forces users on the worse electron/web alternative.

>It's about time to effect change. It's about cross device and platform support. It's about it being easier to find developers familiar with the browser stack then native app developer.

One might consider these as cutting corners - hiring web developers to build an app that really should be native

Most of this is false. Ripcord achieves near-feature-parity with the official Discord and Slack apps using cross-platform desktop technologies with a fraction of the resource usage with a single developer.

Ripcord's very existence contradicts most of the claims you've made above.

You can also just look at how many developers it took to build similar programs, native and cross-platform, in, say, the 90s and early 00s. I wouldn't be surprised if a bunch of them had smaller teams for all platforms combined than Discord has for its single desktop client. Yet one would hope we've gotten more efficient at software development since then, and the entire excuse for using things like Electron is supposed to be that it saves a whole bunch of developer hours—but then you look at how tiny teams were on some of even the fairly-big programs back then, and all our "more-correct" processes and technologies start to look pretty damn suspect.

I only ever used it for small GUIs for some scientific computing I did back in college, so maybe it's hard to use for larger projects, but the impression that I remember of Qt was that it had a pretty large component library, extensive documentation, and a drag-and-drop WYSIWYG UI editor!

The workflow that I've seen for frontend coding today is that a designer makes a mockup in something like Figma, and then a frontend programmer has to go remake it from scratch in typescript? It seems crazy that we have not made any progress (or even regressed) here in 15 years, but hopefully I'm just out of the loop on state of the art.

> a drag-and-drop WYSIWYG UI editor!

I like Qt for how much it enables us to do, but having worked with Qt Designer, it can get off the rails once things get too complex. Probably doesn't help when you enable/disable UI elements programmatically, but still lol

Yeah, I think you guys are right. It's like the history of vitamin C and scurvy on ships. We seem to have collectively lost some very obvious and straightforward knowledge

The usual explanation is that non-JavaScript devs (every programmer over the age of 40) was an amazing genius, and we need Electron/Flutter/Node/left-pad/etc now since there are so many new coders. I think you're on to something though. Somehow modern practices just result in wasting incredible amounts of time and effort tinkering with fiddly frameworks and boilerplate code