The fact remains that proprietary software seem to be a license to print money, and with the ability to print money is the ability to entrench said software, such as heavy investment in software development.
This is a uphill battle for open source software, but it seems that open source software tend to keep improving in the long run.
It seems like proprietary software has a big advantage when there's still lots of room for improvement, so that investment in further development pays off.
However, in some cases, there's little room for real improvement, and the thing becomes a "solved problem" for the most part. At this point, the proprietary companies then start enshittifying the software (look at Photoshop, now a cloud-based program) to try to extract more money from users, and to keep users on the upgrade treadmill. Part of this is probably from the way corporate politics work: when you're a manager with a team in place, you need something to keep that team busy, to justify your team's continued employment to upper management, so when you run out of useful improvements to make, you invent less-than-useful "improvements" (e.g., ugly new UIs).
This is where FOSS seems to be able to do well: it doesn't need to waste resources on useless improvements (we'll ignore GNOME for a moment as an exception), and can just focus on delivering the necessary functionality. Once that's done, it can just go into maintenance mode and people can move on to other projects. Until then, it can continue to improve and attract users to switch from the enshittifying proprietary stuff.
FOSS only does well when it isn't the main source of income for contributors.
GNOME I'll heartily agree on. But I've never liked GNOME myself (v1 seemed OK though) and have always criticized that project. I've always been a KDE fan, though admittedly they've had some similar problems and have handled some major changes rather poorly (esp. 4.0). Really, the desktop environments are one place where FOSS hasn't really done that well, frequently re-inventing the wheel for questionable reasons, or adopting questionable new design philosophies. At least there's a fair amount of competition in the space, so if one project rubs you the wrong way, you can try another; this proliferation of competitors also shows just how much disagreement there is in the community on this particular matter.
I really don't know enough about the audio stack changes; I can only guess that they found big problems with older solutions there which required major architectural changes, esp. for certain high-performance applications.
It is to be expected that there is a proliferation of different UIs if there is the possibility of making different UIs run on the same OS. The reason is that everybody has a different workflow, different aesthetic preferences, different ways of doing things (e.g.: leaning more toward keyboard, mouse, touchpad, touchscreen). The best thing I remember in this space were the dozen or so X11 windows managers of the 90s. The worst one is the single UIs for Windows and Macs. There are some ways to customize them but not as heavily as it is possible with Linux.
Wayland seems to restrict what's possible to customize but I might be wrong because I have no direct experience. I'm still of X11 because of an old NVIDIA card and frankly I could stay on X11 forever. I know that I'll have to switch sooner or later because of software compatibility. I'd hate to have to buy a new laptop only to be able to run Wayland. It's still good enough to work with me for my customers.
Which is why Windows and Mac still get native UIs for many desktop products, while Linux if a product actually targets it, gets Electron.
Native widget libraries is whatever the OS vendor puts on the SDK, and ships on the installers for their compilers.
The large majority of Electron apps that happen to land on Mac and Windows land, usually come from GNU/Linux shops, that also feel like targeting other operating systems, and since that is the solution for GNU/Linux, they dump it into everyone else.
In the process they help Google take over the browser ecosystem, and then talk about how M$ used to be all over the place with IE.
But meanwhile, the OS vendors got creative and pumped out a bunch of new, _more modern_ libraries, which have abilities that the old, "system" ones do not have. You want Acrylic design on Windows? Better be satisfied with WinUI -- which, in v3 is the recommended way to write native applications by the platform owner, and which is decoupled from system releases and from Windows SDK.
Electron apps are coming from any shop, that want to throw together some installable, locally running app and figured out, that paying HTML+CSS devs is cheaper, than paying C++ (or ObjC) ones. Having shorter development time is also something positive. It has nothing to do with Linux shops; there are Electron apps, that could be running on Linux if there was a will, but aren't (Whatsapp), or almost-electron-but-edge_webview-instead (Teams).
Doubled down at .NET Conf 2024 during the last week.
Regardless of the GUI framework from Apple, and Microsoft, those are managed bindings to the underlying native APIS (Win32 and Cocoa), which is why they also expose handles to do lowlevel stuff if one so desires, coding like 2000.
Webviews are a different matter, as they don't require shipping Chrome with the application.
It definelty has a lot to do with Linux shops, as they can't be bothered to support GNOME, KDE, Sway, XFCE, or whatever everyone else uses, so Electron it is.
And then they want Mac OS and Windows customers as well.
So maybe Microsoft should update their own guides then: https://learn.microsoft.com/en-us/windows/apps/get-started/?...
| Many apps for Windows are written using Win32, Windows Forms, or UWP. Each of these frameworks is supported and will continue to receive bug, reliability, and security fixes, but varying levels of investment for new features and styles. For more information about these app types see the following tabs.
Yes, in Build 2024, there was backpedaling back to WPF, since WinUI is in terrible shape.
> Webviews are a different matter, as they don't require shipping Chrome with the application.
Electron also doesn't ship Chrome with application; it ships the rendering engine (blink) and javascript engine (v8). Which is exactly the same, as edge webview. Unlike edge webview, they are not dragged in by Microsoft Edge, the browser (so you get it whether you have an use for it or not).
> It definelty has a lot to do with Linux shops, as they can't be bothered to support GNOME, KDE, Sway, XFCE, or whatever everyone else uses, so Electron it is.
So how do you imagine such support would look like? I know a thing or two about development on linux, but I have no idea what would supporting XFCE or Sway explicitly in an app would involve. Unless you hyperbolize, right?
The only real decision would be choosing Gtk or Qt; the desktop environments have no real impact on your app and with Qt, you are getting the multiplatform support, that is supposedly behind the electron usage of those linux shops.
Also, what exactly are those linux shops, that target multiplatform by using electron? Is it like Cisco? Or Meta? Maybe Bitwarden? Discord? Figma? Microsoft (skype, vscode)?