1–10 of 18 posts
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.
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.
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.
My rule nowadays is to go with a web application unless you have a good reason not to. The difference between the work done for deployment is enormous, and it's enough to justify avoiding desktop applications 90% of the time.
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".
It's a good idea to use desktop technologies if the app is complex, for most corporate intranets a few web pages is probably good enough. 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. D…
My rule nowadays is to go with a web application unless you have a good reason not to. The difference between the work done for deployment is enormous, and it's enough to justify avoiding desktop applications 90% of the time.
For a lot of apps, this works, but I think this is also what's led to number of Electron packaged apps. 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…
Earlier quoted context omitted.
For a lot of apps, this works, but I think this is also what's led to number of Electron packaged apps. 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…
"The correct choice" was only correct after the application was created and iterated upon and somewhat widely adopted. Would any of the rapid feature iteration and widespread adoption have happened if this theoretical application was _initially_ created as a native app?
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.
It's a good idea to use desktop technologies if the app is complex, for most corporate intranets a few web pages is probably good enough. 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. D…
Why bother with bad apis and hacky deployments? I'd venture to say the answer to OP's question is a simple "no".
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.