It's depressing to watch this trope start to bleed over into HN.

After all it's neither going to be popular because it's a popular sentiment nor is it particularly likely to be something interesting/relevant to get upvotes on merit. It's just going to be an unpopular opinion that gets ignored.

But seriously Electron is so many times better than writing native apps .. or even trying to find the documentation for how to do _one single thing_ in a native app the way you want to.

You are less likely to read the truly unpopular opinions but yes I agree, seems like a cheap way to gain popularity.

I'd say you're right about the GUI shitshow, and the web ecosystem is just a slightly different kind of shitshow.

There's a huge amount of tiny chores with web development, that if you hadn't learnt how to do them in 1.5 seconds 5 years ago, would take you 2-3 days to figure out.

There are a hundred small chores that must be done to build and launch software on the web that you have to learn before you get it going.

I strongly doubt desktop doesn't have the exact same volume of inane things as webdev.

If you insist on using the new hotness being offered for any platform (web, native, whatever), then sure, you're doing to see this. But in the web context, you reference the DOM APIs that are stable ... in the same way that Qt, GTK (or even Cocoa) have been. New APIs for web dev show up monthly, but you apparently manage to not keep switching from one to the other. Why would you do the same thing for native dev?

But the number of Windows native app APIs is insane, and every year I try to learn how to create an XCode basic app and it’s different. Creating a simple app with HTML and JS however is the same as it’s always been.

https://ardour.org was first ported to then-OSX in 2006. Almost nothing in the codebase that relates specifically to now-macOS has changed in that time.

XCode is a tool, not a platform. Cocoa is the platform, and it changes very little and very infrequently.

When we first ported Ardour to OSX/macOS, it was abundantly clear that XCode was a non-starter in terms of technology, partly because it was single platform, and partly because its scope was too large - as Unix-based developers we understood the merits (and occasional pain) of more modular toolsets. So I found a handy guide to writing "nibless applications" that completely removed XCode from the picture (along with some Cocoa boilerplate code that isn't actually required). As a result, we've continued to interact with the stable API core of Cocoa, even as Apple dither around the edges.

Apple (and Microsoft and .... ) are not your friends. They want you to build software for their platforms, but beyond making that possible in some way, their incentives do not align with yours in any substantive way (partly because they make software too, and have their own API goals and needs that may/will conflict with yours). If you don't understand this, you're inevitably going to have the sort of experience you describe above.

By the way, a blog post on how to create Nibless apps would be invaluable.

I'm not sure if this is the source I used, because the date is a little late, but it seems very thorough and excellent:

http://lapcatsoftware.com/blog/2007/05/16/working-without-a-...

Qt is native in that sense, just as much as any other toolkit designed for the same purpose.

Native GUI is more cplicated nowadays too, but I don't expect it to change too much - controlling layout using CSS+HTML is harder than in most (if not all) native GUI frameworks.

I still cannot comprehed how we ended up with the shitshow that is CSS/HTML. Even Javascript nowadays is a workable language ( or otherwise typescript ) WebAssembly is great... but the actual UI Layer with the DOM and CSS .... just a nightmare

Every time i have to work on something a bit more complex on the browser, i ponder of writing my own UI Toolkit based on Canvas/WebGL or WebGPU and just draw everything myself

For me its a no go to have a language that's bascially a dead end outside of one specific ui framework.. Seems like a solution in search of a problem.

What other framework doesn't maintain 60 fps in its hello world?!

Flutter works great on mobile and desktop though, I shipped multiple apps using it and currently writing a desktop app.

Any desktop app I make that needs a GUI gets written in Java. Swing is antiquated but doesn’t change every year like everything else keeps doing. I use an XML UI definition language (Swixml) to make it RAD. With a modern look-and-feel package it looks great, runs fast on modern hardware, works the same on Windows/Mac, is easy to deploy, and most importantly: I know it will work basically forever.

So you had an app that was already written, ported it to electron (designed to make the port as painless as possible), and you note that this is easier than writing it from scratch with non-web APIs? This is not exactly suprising, is it?

In a parallel universe, a junior dev who only learned Qt would have same amount lot of trouble making websites.

True, and had we tried to port to native, that intern would have given up. Most of the business functionality was in a REST api, so porting to native was something that was doable, but the level of effort would have been extreme. Oh, and had we wanted native on Mac, Windows, Linux, Android and iOS... well... that's 5x jumbo right there.

You can sort of kind of pull this off with a relatively limited web app, where the interactions are limited to tapping (since there's generally touch interaction on the desktop) and the fluid layout possibilities of modern CSS give you some chance of coming up with a general design that can work sort of kind of OK across all browsers on all platforms.

But try this for a more complex app, the sort that has been traditionally desktop only, and I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms, regardless of the actual toolkits /technology you are willing to use.

Android and iOS represent the majority of devices your software can be run on. They are ubiquitous, and also very dependent on a native UI frameworks that are a somewhat better developer experience than their desktop counterparts, but only because the years of accumulated cruft are less. Incidentally, Android actually does have a desktop mode for it's GUI. That said, users rarely use the desktop Android GUI.

> You can sort of kind of pull this off with a relatively limited web app

I've had better luck with electron and PWAs on the desktop than non-native mobile tooling. This is largely because non-native mobile frameworks often don't have access to the same libraries - or the abstraction layer loses fidelity in trying to be cross platform. There's really no QT grade multiplatform tooling on mobile. There's some promising starts.

> I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms

It's hard to get a decent GUI on both Android and iOS that doesn't have a lot of rough edges with cross platform frameworks. They are coming along, but it's still just not quite there yet.

Flatpaks make distribution a non-issue too.