Hacker News new | ask | show | jobs
by stephenr 3356 days ago
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".

1 comments

"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?
> 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.

But how do you manage deployment of a new version? That's where the web comes into its own.
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/), 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.

There are multiple solutions for handling updates of native apps.

Managing updates to a cluster of backend servers is at least as difficult, because they usually have shared state (a database).

By "the correct choice" I mean the correct choice for a desktop application.

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.