Assuming that I can't get away with a web app, and need to install something native on the client side... is cross-platform support required?
If so, then your choices are:
1. Write separate native clients for Windows (in C#) and OS X (in Swift or Objective-C), and perhaps Linux (in whatever). It'll be hard to hire people who can work on all three, so you'll need more headcount and organizational/technical complexity.
2. Use a cross-platform framework like Qt, Wx, Gtk, etc. This will probably push you toward C++, which can be difficult to hire for. And you'll get constant complaints that the UI doesn't "look native enough" anyway.
3. Use Electron, and whichever JavaScript SPA framework is trendy this week. Have everyone on Hacker News declare your client to be "Flash for the Desktop", and be forced to re-write it with the next trendy framework two years later so that anyone will want to work for you.
4. Use JavaFX, and the JDK's built-in "javapackager" tool to create native installers for Windows, OS X, and Linux. Each of which includes a bundled JRE, with a size smaller than Electron. You won't be able to find a lot of JavaFX experience on the market... but Java developers are easy to find, and it only take a few weeks for decent ones to get up to speed with the framework.
Hell yeah, I'd use Java on the client side. None of the options are great, but Java's probably the least-bad.
I wish that applets had never been invented, too. But only because of market confusion. So many people who don't know anything about Java mix up applets (which haven't been relevant in almost 20 years) with Swing or JavaFX desktop apps, think that security vulnerabilities found in the browser plugin mean that standalone Java apps are "insecure" in general, etc.
Applets have nothing to do with Java desktop app development, and I don't think anyone has confused the relationship between Java and JavaScript in over a decade.
I don't believe you really have anything to contribute to this thread, and are just bouncing from one tangential reference to the next to feel insightful.
If so, then your choices are:
1. Write separate native clients for Windows (in C#) and OS X (in Swift or Objective-C), and perhaps Linux (in whatever). It'll be hard to hire people who can work on all three, so you'll need more headcount and organizational/technical complexity.
2. Use a cross-platform framework like Qt, Wx, Gtk, etc. This will probably push you toward C++, which can be difficult to hire for. And you'll get constant complaints that the UI doesn't "look native enough" anyway.
3. Use Electron, and whichever JavaScript SPA framework is trendy this week. Have everyone on Hacker News declare your client to be "Flash for the Desktop", and be forced to re-write it with the next trendy framework two years later so that anyone will want to work for you.
4. Use JavaFX, and the JDK's built-in "javapackager" tool to create native installers for Windows, OS X, and Linux. Each of which includes a bundled JRE, with a size smaller than Electron. You won't be able to find a lot of JavaFX experience on the market... but Java developers are easy to find, and it only take a few weeks for decent ones to get up to speed with the framework.
Hell yeah, I'd use Java on the client side. None of the options are great, but Java's probably the least-bad.