
Ask HN: Is it better to build intranet apps with desktop technologies? - curiousgeek
In the recent &quot;Electron is like Flash&quot; thread it was claimed by many people that desktop apps are much easier to create and have better tooling than for the browser.<p>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?<p>Thanks.
======
fian
If your application needs to do some heavy lifting on the client machines,
then yes desktop technologies will be better. Web browsers are sand boxed for
security and can be too limited for some purposes.

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.

------
IslaDeEncanta
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.

~~~
stephenr
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 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".

~~~
monkpit
"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?

~~~
flukus
> Would any of the rapid feature iteration and widespread adoption have
> happened if this theoretical application was _initially_ created as a native
> app?

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.

~~~
untog
But how do you manage deployment of a new version? That's where the web comes
into its own.

~~~
flukus
Deployment is definitely harder, but not to the point where it's unmanageable.
Click once is one solution that's very common, though not great. It will check
a url for a new version at startup and install that version. This URL can be a
simple aspx page that gives each user the right version, I recently automated
this as part of our CI deployment.

A better solution would be something like chocolatey
([https://chocolatey.org/](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.

------
hiram112
I don't think so anymore, though I would have said yes even a few years ago.

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.

------
guitarbill
Web apps are great for most intranet apps. Especially if you already have a
single sign on solution. Deployment and maintenance are easier, as is
replacing the thing when it becomes obsolete. With a desktop app, once it's
out there, it's out there with all the headaches that brings. Otherwise, hard
to make a recommendation without any specifics.

------
flukus
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.

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.

~~~
monkpit
Why bother with bad apis and hacky deployments? I'd venture to say the answer
to OP's question is a simple "no".

~~~
flukus
Because I don't have utter contempt for the users of my software and a little
bit of once off pain for me (like fiddling with click once deployments) is
worth if it the product is better for 1000 people that use it everyday.

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.

------
Atami
Thanks for your answers!

