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.
> 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’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.
My first reaction to this before clicking the link: why would anyone want a programmable timer?
After clicking the link and seeing the demo: man, I’ve always wanted a programmable timer.
This is awesome, can see myself using this for workouts and focus sessions. Thank you for sharing.
I read this comment, which convinced me to click the link, and had the exact same reaction.
Such a compelling idea - feels completely obvious after seeing the demo that this is what I want in a timer.
I’m wondering whether anything could be done in terms of name/“tagline” to clarify this? (Or maybe this is just a peculiar niche?)
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.
Tested, browsed to another tab, switched to another app, turned off screen. Are there any limitations compared to a native app?
It needs an example of nested loop and skipping last item, with comments.
> 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).
If you 'Add to Home Screen' you don't get the address bar. Effectively fullscreen.
Not sure how that would work with the state being saved in the URL — you'd need to save each routine separately I think.
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.
Oh that's pretty cool! I also like how you can bookmark timers to save them and then keep a list of them for various activities/purposes.
Also when I saw the HN post I knew something was familiar and I remembered an old project of yours: x[it]!
From time to time I still think about that one. Are you still engaging with x[it] or have you moved on in a sense?
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.
(Links for reference: https://xit.jotaen.net and https://klog.jotaen.net)
nice work … would love to have this on my apul watch
Nice work! Love it.
I love the declarative syntax, and it makes me wonder if there is a use case for a timeline-based scripting language.
Functions, variables, data structures... Intervals (timers) as a first-class citizen - an actual keyword "timer"[1] that works like const or let.
Anyway, this is really cool.
[1] Where are my VB6 devs??