4 ms·

I think you could just say the world has moved on from client-side desktop apps. Doesn't matter much what language, the majority of applications are web-based

I think you could just say the world has moved on from client-side desktop apps. Doesn't matter much what language, the majority of applications are web-based and there are major negatives to having a client side install experience with patching, versioning, support, etc. Yes there are still niche domains that would need a desktop app but those are probably more rare as time goes on and/or already have established players.

mike_hearn 5y ago
Client side install experience is what mobile apps have, and everyone seems to prefer them to web apps. Web apps also have major downsides. It's easy to forget about them as developers, but for example, one is the lack of versioning. Someone pushes a new version of the app that's buggy/an UI downgrade/causes an outage and the users can't do anything about it. Often you want an app to be local because it's interacting with local data, or local hardware, or it suffers from latency, or you don't want your data to go outside your jurisdiction, or it's doing something else where distance between you and the app is problematic. Client side apps written using normal toolkits (not HTML) have a lot of major end user advantages, which is why: • Mobile apps beat web apps, despite devs trying to make users accept them (recall the history of the Facebook app for example). • HTML5 keeps sprouting features that desktop apps have had since the beginning. Filesystem access is a recent example. Any time you want your data to be independent of the apps that work with it, web apps just faceplant. In my view developers push web apps on users usually for our own convenience, e.g. being easier to bypass IT department bureaucracy. But there's a lot of ways to do better than web apps, and yes, the JVM is pretty good platform to do that on (JavaFX is a great toolkit for instance, and JetPack Compose is very interesting). What it needs is a great distribution and update solution.
- mattbrewsbytes 5y ago
  I was mostly referring to desktop app vs. web app since the OP was talking about desktop apps. Mobile apps are a different topic but they also share a set of the similar trade-offs of a desktop app with install/upgrade and support (i.e. multiple devices/versions). Pushing buggy/UI problematic software is a process/people problem not really a technology problem. I would bet the feedback loop for getting fixes in on web apps can be much shorter than client desktop apps (or mobile). Once a fix/change is tested we can have it out in production on a web app for 100% of users in 20 minutes. Stand-alone apps are a great niche where the native UI kit or other UI kits that work for the problem being solved are a great solution, there isn't a need for web tooling.
  - mike_hearn 5y ago
    On the web, regressions are a pure technology problem exactly because there aren't any chances for processes or people to get involved (other than the devs themselves). When users have more control over software rollouts they can tailor their risk profiles and tolerances to their own situations, do regression testing on their own scenarios etc. In turn that means you can offer better privacy. An extreme example of where this matters is in the military. You cannot have an army in battle being brought to a halt because some web dev pushed a syntax error in a PHP file. You must have a qualification procedure that tests it in the scenarios that matter, which the developers may not even understand all that well. Another example is medical software. If you push an app update to equipment in an operating theatre and a button stops rendering because the doctor had the font size wound up higher than expected, then people might die. You just cannot do that. Heck you cannot even allow it to depend on working internet. It has to be a desktop app (well, embedded, but a lot of embedded apps are just desktop apps on kiosk mode operating systems). Now you're right that if you do push a bug, then due to all the data collection and the way browsers commingle data and code, you can fix things faster than the slower more async process preferred in the desktop world. But there's no fundamental reason it has to be that way, it's just a question of social norms. You can make a desktop app that can be force updated immediately or even on a per-screen basis. People just don't do it because often if you're writing a desktop app in the first place, it's because your users want or need more control than a web app would give them.

mike_hearn 5y ago

Client side install experience is what mobile apps have, and everyone seems to prefer them to web apps. Web apps also have major downsides. It's easy to forget about them as developers, but for example, one is the lack of versioning. Someone pushes a new version of the app that's buggy/an UI downgrade/causes an outage and the users can't do anything about it. Often you want an app to be local because it's interacting with local data, or local hardware, or it suffers from latency, or you don't want your data to go outside your jurisdiction, or it's doing something else where distance between you and the app is problematic. Client side apps written using normal toolkits (not HTML) have a lot of major end user advantages, which is why: • Mobile apps beat web apps, despite devs trying to make users accept them (recall the history of the Facebook app for example). • HTML5 keeps sprouting features that desktop apps have had since the beginning. Filesystem access is a recent example. Any time you want your data to be independent of the apps that work with it, web apps just faceplant. In my view developers push web apps on users usually for our own convenience, e.g. being easier to bypass IT department bureaucracy. But there's a lot of ways to do better than web apps, and yes, the JVM is pretty good platform to do that on (JavaFX is a great toolkit for instance, and JetPack Compose is very interesting). What it needs is a great distribution and update solution.

mattbrewsbytes 5y ago
I was mostly referring to desktop app vs. web app since the OP was talking about desktop apps. Mobile apps are a different topic but they also share a set of the similar trade-offs of a desktop app with install/upgrade and support (i.e. multiple devices/versions). Pushing buggy/UI problematic software is a process/people problem not really a technology problem. I would bet the feedback loop for getting fixes in on web apps can be much shorter than client desktop apps (or mobile). Once a fix/change is tested we can have it out in production on a web app for 100% of users in 20 minutes. Stand-alone apps are a great niche where the native UI kit or other UI kits that work for the problem being solved are a great solution, there isn't a need for web tooling.
- mike_hearn 5y ago
  On the web, regressions are a pure technology problem exactly because there aren't any chances for processes or people to get involved (other than the devs themselves). When users have more control over software rollouts they can tailor their risk profiles and tolerances to their own situations, do regression testing on their own scenarios etc. In turn that means you can offer better privacy. An extreme example of where this matters is in the military. You cannot have an army in battle being brought to a halt because some web dev pushed a syntax error in a PHP file. You must have a qualification procedure that tests it in the scenarios that matter, which the developers may not even understand all that well. Another example is medical software. If you push an app update to equipment in an operating theatre and a button stops rendering because the doctor had the font size wound up higher than expected, then people might die. You just cannot do that. Heck you cannot even allow it to depend on working internet. It has to be a desktop app (well, embedded, but a lot of embedded apps are just desktop apps on kiosk mode operating systems). Now you're right that if you do push a bug, then due to all the data collection and the way browsers commingle data and code, you can fix things faster than the slower more async process preferred in the desktop world. But there's no fundamental reason it has to be that way, it's just a question of social norms. You can make a desktop app that can be force updated immediately or even on a per-screen basis. People just don't do it because often if you're writing a desktop app in the first place, it's because your users want or need more control than a web app would give them.