Is it a good idea to use desktop technologies for Intranet apps at least (with only API endpoints on the server)? Which stack would you recommend? How hard will it be to auto update the software?
Thanks.
Desktop applications can avoid security problems inherent in web apps that are run through a general purpose browser.
The commonly cited tradeoff with desktop apps is they are harder to deploy and update. I don't believe this is necessarily true. You can tell a desktop application to periodically check for updates and notify the user to restart before allowing further writes to any central data stores. If fact many already do this. Problems arise when the OS prevents updates from being applied by non-admin users and you are deploying within a locked down corporate environment.
Java SE/Swing is a good platform for writing cross platform desktop applications. I work on an engineering simulation tool with a complex UI written in Swing. With Nimbus Look and Feel it looks and works the same across Windows, Linux and OS X without changes. Some people (devs) complain that is doesn't look native - none of my users care though.
The few times I have ventured into web development I have been horrified by the amount of work required to get web apps to look and work the same across different browsers. JQuery and Bootstrap deal with a lot of the pain but web dev still feels very hacked-together compared to desktop development to me.
It starts out as a web app, because you can iterate quickly and its mostly platform agnostic. Then people realise that what you're doing means a 'dedicated' app is a better experience.
At this point, the correct choice would be to have someone create a desktop app that uses your existing web app as an API. If your web stack handles accepts/content-type switching in a decent way, this may mean very little or no work on the backend.
Unfortunately this is also the point where its become common to adopt Electron. Like a lot of things that are wrong in this industry, I blame it on the cool kid javascript/front end developers. "Oh sure I can just make you an electron app for desktop users, its just js/html/css".
Having a desktop application doesn't mean you can't/shouldn't have a web application. It also doesn't mean they need to look/behave exactly the same.
Yes. Desktop applications can be just as quick to develop and iterate on as web based ones. Slapping together a winforms UI in visual studio is still the quickest way to get to MVP status.
A better solution would be something like chocolatey (https://chocolatey.org/), which is basically a package manager for windows. It doesn't do the automatic updating, but doing that with a remote powershell script should be doable.
For some perspective though, if you automate this as part of a CI builds it should be a once off cost, it's not a justification to make something a web app instead.
Managing updates to a cluster of backend servers is at least as difficult, because they usually have shared state (a database).
I see most of the companies I work with moving towards AWS or Azure with all the scaling support and APIs that really make web apps easier to work with.
Instead of dealing with dozens of IT rules as to what can be installed on the various corporate images (which now include Macs), it's easier to just point users at a URL and make sure whatever single sign on they've got is integrated.
Another point: desktop apps are just as complicated as web apps these days, especially when dealing with Mac, Unix, Windows compatibility along with mobile. It seems like nobody has really done a good job of replacing VB6, Delphi, etc, and I haven't touched (as a Java developer) Swing or JavaFX in years.
As for the stack, c# and winforms is a good bet, particularly if you need to target older versions of windows. If you need a bit more performance or cross platform support then c++ and qt would be better. You could go c++ and win32, but MS dropped the ball on creating a nice api.
Deployments are another area MS dropped the ball, click once is sort of ok if you are using visual studio, but either way chocolatey is better. You may want something better for release management, in which case look into octopus deploy. These suggestions apply to electron apps as well.
Basically, had windows XP come with a better programming APIs (more like qt/gtk) and a better deployment model then web apps would have never been a thing. OSS has made windows a viable desktop.
It's simply a matter of what those variables are. A sick leave application form that get's used a few times a year? Stick that on the web, the installation cost isn't worth it. A productivity tool that's used all day, every day by a lot of people? Make that a desktop application, especially if you need local resources, like files. An application used by millions world wide everyday? Write that in a natively compiled language and use the native (or decent cross platform) UI, there's no reason your productivity is more important than the millions of users.
We're talking corporate intranets though, so a PC (or occasionally mac) will be the norm because that's required for productivity apps. Most things simple enough to be a touch screen app would fit into the category of also being simple enough for a web app. As I said, web apps are a good choice for simple and/or rarely used apps.
Irrelevant side story: For my second ever paid programming job (which only lasted a few weeks for other reasons) I was handed a fairly complex windows mobile app to learn. The app loaded every table in the windows CE database into memory when it started, which took about 15 seconds. Within a couple of days I'd modified this to load on demand instead, cutting start times to zero and impressing the boss.