Hacker News new | ask | show | jobs
by tapoxi 1539 days ago
I think Electron won out because Microsoft kept pulling the rug out from under Windows developers as they went from Win32, to Windows.Forms, to WPF, to UWP, to WinUI 3. Why take the risk on the most modern Windows framework when you could just go Electron, have a broader pool of developers, and get Mac & Linux support as well?
6 comments

This. We (at Remotion) are currently evaluating what platform to build for, given our start with macOS native / Cocoa. But for Windows, what is Windows Native?

Seeming like more of a collection of half-baked ideas than robust frameworks that we'd want to bet a bunch of dev time on.

As you both mention, we might end up with a cocoa macOS app and an Electron app for Windows & Linux.

Please don't make Linux users suffer because of Windows.
I'm not a frequent Linux user so that comment crept in there—we haven't evaluated as deeply. Any suggestions for how to best build Remotion (lightweight video chat + dock for your team) onto Linux?
Are Qt, GTK4 or Compose (Jetbrains) viable options?
I'm not a fan of Qt from my time at Dropbox (we used it for our desktop client preferences for some time), but will need to check out GTK4 and Compose. Thanks!
I used to be a big Qt fan but I have started favoring Gtk. Glade is better than any Qt designer. And being C based you tend to get better Gtk bindings in other languages. Who wants to develop in C++ these days unless they are doing systems programming?

My strategy would be Cocoa for MacOS/iOS and Gtk for Linux/Windows.

Check compose mpp, uses Kotlin and Skia under the hood. Really good performance overall.

https://www.jetbrains.com/lp/compose-mpp/

Not native.
I'd like to point out that, while that's a good reason why Electron might have won in terms of developer mindshare, that's not necessarily the reason why it won on in terms of marketshare.

I personally believe that the cause of the latter is a combination of (1) cost-saving through fewer platforms to support (2) cost-saving through a larger developer pool and (3) better branding support, but I've never worked in the business myself.

I remember having to import obscure Win32 libraries because the latest platforms were never complete. Like the fontpicker would drop you from WPF to Win32 because MS couldn't be bothered to update it.
Don't forget Silverlight!
Or just bite the bullet and use win32/COM, because its basically the API under all these newer APIs anyway, and in the cases its not there is a compatibility shim.

Of course this doesn't stop MS from simply removing functionality, like they have been doing for the past 10 years. Explorer has a fraction of the API surface it had in the past, as do large parts of the OS. Like for example the color APIs which used to describe every little part of the UI so it could be tweaked are now basically gone.

Well, you don't use the bleeding edge Windows API. You shouldn't use the bleeding edge of any API in general.