> Are there any limitations compared to a native app?
Probably only minor ones; three come to mind:
- The web app has to be loaded every time (~700K total right now), whereas the native app works offline. This could be mitigated with a progressive web app, though.
- Fullscreen mode is usually blocked by mobile devices for websites, so you always see e.g. the address bar. That’s just a visual thing, though.
- I’d assume that native audio APIs would allow for more control (and are likely easier to work with too).
Add to Home Screen does give you fullscreen. But if your state is in the
URL, here is something I found out the hard way: on iOS, a PWA opened
from the home screen has its own localStorage, separate from Safari. My
own browser game keeps data in localStorage, and things a user saved in
Safari were not there after adding it to the home screen. They had to do
it again.
Keeping the state in the URL actually avoids this. There is no storage
to be separated. The cost is what perilunar said, one shortcut per
routine.
I think people hear timer web app and they immediately have the reaction like why the f will anyone use this, but your idea is pretty cool in reality. Ideally should not call it a timer or have app in it. Even something like (Name) - A timer that can be programmed will be a better title than what it currently is.
I’m still using [x]it! every day for tracking daily todos or various check lists (e.g. tracking payments or packing lists) – same for klog, by the way, which I use for time tracking.
I consider the [x]it! file format mostly complete, so in a way there isn’t much for me to do anymore. But I guess that’s also a good thing about such standards – that there is little to no maintenance burden compared to “actual” software.
I think there is a difference between “nitpicking” and “discussing” details. I personally do not see any nitpicking in OP’s comment, I rather see it as valuable and well-presented contribution to the general (wholistic) discussion.
To me, your response would have been just fine with only the last sentence.
Not a VSCode user, so a genuine question: what are practical use-cases in which you want VSCode to automatically execute a task only by opening a folder?
Is it only for convenience so it already `npm i` or `npm start` without you having to do anything, or are there any other legitimate purposes beyond that?
Apart from this feature specifically, in general people would like their IDE to run language servers, set up build systems, and any number of other things which are likely to require some configuration which allows executing some code in the folder to work. VS code has a restricted mode to prevent this, which you need to accept a dialog to disable, but it also disables most of its features.
> in general people would like their IDE to run language servers, set up build systems, and any number of other things
That I understand, I’m mainly wondering why all that would have to happen automatically by merely opening a folder.
My personal preference may differ here, but for things like running a build or starting a dev server, I usually prefer to trigger them manually, and not have them silently executed only by me browsing through the sources.
Therefore I’m trying to understand whether there are legitimate use-cases for this “auto-run on open folder” feature besides the obvious convenience aspect of saving one or two extra clicks.
When I used it, the one use case I used it was to automatically launch a Jekyll server - if I'm working on a site I'm almost certainly going to want to look at my changes in the browser. Now that I've switched I just run one extra command, it wasn't a big saving, but it was kind of nice.
Probably only minor ones; three come to mind:
- The web app has to be loaded every time (~700K total right now), whereas the native app works offline. This could be mitigated with a progressive web app, though.
- Fullscreen mode is usually blocked by mobile devices for websites, so you always see e.g. the address bar. That’s just a visual thing, though.
- I’d assume that native audio APIs would allow for more control (and are likely easier to work with too).