I was specifically talking about platforms I don't "need" to support.
Obviously, it goes without saying that all of the listed have a barrier to entry several orders of magnitude more than web technology. wxWidgets seems fun for some uses, but how would one go about making it look appropriate for end users?
I personally know a couple of end users who don't know what the URL bar in their web browser does, but they can easily use wxWidgets applications. Why should it be harder?
It will take a gorillion more development hours, which means you won't be first to market with features, so no one will use it.
Or it won't look as "good", so even if has well-needed features it will be quickly taken over by a project that steals the features and provides a better-looking but less performant frontend.
Also, I forgot to mention this before, not having to install the app (we aren't talking dependencies here, but even downloading an executable and opening it from the filesystem / app store) is a key feature to user acquisition.
So reusing UI components between a less featureful web app and a fully featured hybrid app is a big benefit, both for user consistency and developer productivity.
which means you won't be first to market with features, so no one will use it.
Slack was made popular a quarter century after the IRC and yet people moved to it.
Or it won't look as "good"
The look of an application is not controlled by the chosen framework. There are really ugly Electron applications and really beautiful native applications.
Beautiful native applications are a lot of work.
It makes sense for Photoshop or Ableton Live to have custom native UI, but most apps such as social media, commerce, communication, and most interfaces to brick-and-mortar businesses don't need to invest in that complexity.
You need a version of your application in the browser anyway, otherwise how will people start deriving value from your application and want to install it?
Perhaps because it's software for professionals(1), for deep work(2), that is clientside resource-limited(3), with a decades long legacy of brand recognition(4) from before anything resembling the modern web, with legacy native code on multiple platforms(5) by a company that has 4 gorillion senior programmers(6) and whose core business is clientside software and not another service(7).
If I ever need a real-life example for over-engineering, I'll choose that.
Do you have a thinner alternative?
Not using web technologies for the desktop, I guess.
So, shipping my own renderer?
To what graphics API abstraction?
What about other OSes?
There already are cross-platform solutions for that...!
Like what? Qt?
Like FireMonkey, Xamarin, wxWidgets, IUP ... :-) it all depends on which platforms you "need" to support.
I was specifically talking about platforms I don't "need" to support.
Obviously, it goes without saying that all of the listed have a barrier to entry several orders of magnitude more than web technology.
wxWidgetsseems fun for some uses, but how would one go about making it look appropriate for end users?I personally know a couple of end users who don't know what the URL bar in their web browser does, but they can easily use wxWidgets applications. Why should it be harder?
Because end users want something that looks like Discord and not something that looks like Windows Administrative Tools
And you cannot develop something that looks like Discord with existing desktop GUI technologies, because...?
(I honestly doubt that users "want" that - users have not designed it in the first place. They take what they get.)
It will take a gorillion more development hours, which means you won't be first to market with features, so no one will use it.
Or it won't look as "good", so even if has well-needed features it will be quickly taken over by a project that steals the features and provides a better-looking but less performant frontend.
Also, I forgot to mention this before, not having to install the app (we aren't talking dependencies here, but even downloading an executable and opening it from the filesystem / app store) is a key feature to user acquisition.
So reusing UI components between a less featureful web app and a fully featured hybrid app is a big benefit, both for user consistency and developer productivity.
Huh? Why?
Slack was made popular a quarter century after the IRC and yet people moved to it.
The look of an application is not controlled by the chosen framework. There are really ugly Electron applications and really beautiful native applications.
Beautiful native applications are a lot of work.
It makes sense for Photoshop or Ableton Live to have custom native UI, but most apps such as social media, commerce, communication, and most interfaces to brick-and-mortar businesses don't need to invest in that complexity.
Beautiful web applications are a lot of work.
Work that someone else has already mostly done for you.
Which is true for desktop applications as well. (That said, I wouldn't consider "glueing together other people's code" to be "programming"...)
Business doesn't care if you call it "programming" but you better be focusing on what makes you different and not reinventing Redux.
Business doesn't care whether I glue together desktop or web code as long as it runs anywhere.
Does your desktop code run in the browser?
Or will that be a complete duplication?
No, you won't need a browser for a good desktop application. But it could communicate over HTTP(S) if you feel like it.
You need a version of your application in the browser anyway, otherwise how will people start deriving value from your application and want to install it?
Good question. How does Photoshop sell so well? It has no browser version.
Just make good software.
Perhaps because it's software for professionals(1), for deep work(2), that is clientside resource-limited(3), with a decades long legacy of brand recognition(4) from before anything resembling the modern web, with legacy native code on multiple platforms(5) by a company that has 4 gorillion senior programmers(6) and whose core business is clientside software and not another service(7).
And you have the chance to make a new one. Don't waste it on the web.