A philosophical question: how does the author reconcile his source code being full of ".js" files and saying "lightweight" with a straight face?
.
And a more practical one: do they not teach people about how power management works anymore? Who thinks this is a good idea...?
Refreshes the cache every 15 minutes (use INTERVAL environment value for custom number of minutes - more)
Do you update your app every 15 minutes? And are you presumptuous enough to assume your users need each update immediately? Maybe you simply just not care for users' devices' battery lives? If you really insist on the NIH approach to updates, check at app launch time, or once every 24 hours at most for long-running apps..
and then
Automatically detects the platform/OS of the visitor by parsing the user agent
When did it become OK to trust user agent strings for feature or device detection?
If your app ever gets popular and causes unreasonable traffic to your GitHub repo, or if GitHub decides they hate you for any other reason, your app will work only by GitHub's mercy and generosity.
> Do you update your app every 15 minutes? And are you presumptuous enough to assume your users need each update immediately?
I don't think you quite understand that this project is the server side, so the every 15 minute update frequency (which is user configurable) controls how often the server polls GitHub.
> When did it become OK to trust user agent strings for feature or device detection?
I never really understood the complaint against this. UA string detection is good enough 99.99% of the time and sure it's not trustworthy in the sense that the end user can mess with it, but so what? If the user is messing with the the string they know what they're doing.
my own experience? I've been developing for the web for 19 years. I know the issues with UA strings. It's an old argument. On the modern web, for the most part UA sniffing isn't necessary. If you do need it, there are plenty of libraries that will very reliably sniff strings which account for 99.99% of the web. Possibly mobile strings are an issue, but there are services like http://wurfl.sourceforge.net/ which will again get you to your 99%+ range. Of course do all the other things like feature detection, graceful degradation and progressive enhancement, but I find the entire argument a bit overblown.
Nothing about this seems to be 'for Electron apps'?
It just sits between the app looking for an update and Github releases; returns the latest release if newer than a supplied version number assumed to be the current.
Is it really so bad to have that `if latest.version > version` logic in the app itself, and download directly from Github?
Github releases are presumably pushed over a CDN and already well-cached - and almost certainly have better up-time than someone running an instance of this somewhere, which of course is still potentially victim to Github's down-time.
If this works as described, it will be a lifesaver.
I've been running nuts on Heroku for my Electron app and never got it fully working. (It was very good at being able to tell there was an update available, but performing the update wouldn't work)
For Windows, you can literally just type `now` in the Releases directory. No micro server needed. Great project though, sorry all those years ago I couldn't convince the Squirrel.Mac folx to do it my way.
.
And a more practical one: do they not teach people about how power management works anymore? Who thinks this is a good idea...?
Do you update your app every 15 minutes? And are you presumptuous enough to assume your users need each update immediately? Maybe you simply just not care for users' devices' battery lives? If you really insist on the NIH approach to updates, check at app launch time, or once every 24 hours at most for long-running apps..and then
When did it become OK to trust user agent strings for feature or device detection?