Rendered at 22:43:29 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
r3trohack3r 24 hours ago [-]
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.
benn0 22 hours ago [-]
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.
jotaen 21 hours ago [-]
I’m wondering whether anything could be done in terms of name/“tagline” to clarify this? (Or maybe this is just a peculiar niche?)
altmanaltman 19 hours ago [-]
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.
aquariusDue 23 hours ago [-]
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?
jotaen 23 hours ago [-]
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.
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.
jotaen 14 hours ago [-]
> 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).
perilunar 10 hours ago [-]
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.
unfinished_thum 8 hours ago [-]
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.
librasteve 11 hours ago [-]
nice work … would love to have this on my apul watch
vibrio 21 hours ago [-]
Nice work! Love it.
redmoonx 21 hours ago [-]
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.
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.
Such a compelling idea - feels completely obvious after seeing the demo that this is what I want in a timer.
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 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)
It needs an example of nested loop and skipping last item, with comments.
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).
Not sure how that would work with the state being saved in the URL — you'd need to save each routine separately I think.
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.
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??