In line with "the web was a mistake" I think the idea that you can create cross platform software is an equally big mistake.
You can do the core functionality of your product as cross platform, to some extend, but once you hit the interaction with the OS and especially the UI libraries of the OS, I think you'd get better software if you just accept that you'll need to write multiple application.
We see this on mobile, there's just two target platform really, yet companies don't even want to do that.
The choice isn't surprising, in a world where companies are more concerned with saving and branding, compared to creating good products.
>You can do the core functionality of your product as cross platform, to some extend, but once you hit the interaction with the OS and especially the UI libraries of the OS, I think you'd get better software if you just accept that you'll need to write multiple application.
Or you can use a VM, which is essentially what a modern browser is anyway. I wrote and maintained a Java app for many years with seamless cross platform development. The browser is the right architecture. It's the implementation that's painful, mostly for historical reasons.
But using a browser (or a VM) buys into the fallacy that your customers across different platforms (Windows, Mac, etc) want the same product. They’re already distinguished by choosing a different platform! They have different aesthetics, different usability expectations, different priorities around accessibility and discover ability. You can produce an application (or web app) that is mediocre for all of them, but to provide a good product requires taking advantage of these distinctions — a good application will be different for different platforms, whether or not the toolkit is different.
I've only done one platform gui work (python) but I'd guess this is stuff that is ripe for transpiling since a lot of gui code is just reusing the same boilerplate everyone is using to get the same ui patters everyone is using. Like if I make something in tkinter seems like it should be pretty straightforward to write a tool that can translate all my function calls as I've structured them into a chunk of Swift that would draw the same size window same buttons etc.
We get into transpiling and we essentially start to rebuild yet another cross platform framework. Starts with "read this filetype and turn it into this layout" and it ends up with "we'll make sure this can deploy on X,Y,Z,W..."
It'd be nice if companies could just play nice and agree on a standard interface. That's the one good thing the web managed to do. It's just stuck to what's ultimately 3 decades of tech debt from a prototype document reader made in a few weeks.
>It'd be nice if companies could just play nice and agree on a standard interface
They basically do though. Every cross platform native ported app I've used the GUI is the same layout. Well, except on macos the menu ribbon is on the topbar and windows it has its own ribbon layer in the application window. But that is it. All these frameworks already have feature parity with another. It is expected that they have these same functions and ui paradigms. Here's your button function. Here is where you specify window dimensions. This function opens a file browser. This one takes in user input to the textbox. I mean it is all pretty standardized and limited what you can expect to do in ui already.
You can do the core functionality of your product as cross platform, to some extend, but once you hit the interaction with the OS and especially the UI libraries of the OS, I think you'd get better software if you just accept that you'll need to write multiple application.
We see this on mobile, there's just two target platform really, yet companies don't even want to do that.
The choice isn't surprising, in a world where companies are more concerned with saving and branding, compared to creating good products.