Show HN: Programmable timer web app (for gym workouts or stretching sessions)

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.

Years ago, I wrote something similar but simpler and non-programmable using Pith (JS with Python-like syntax).

https://gabrielsroka.github.io/webpages/pith.html

  cancel = false
  editor.style.display = 'none'
  debug.hide()
  btn = button('Stop', 'cancel=true id=stopBtn')
  bar.html(btn)
  beep = new Audio('beep.mp3')
  lock = await navigator.wakeLock.request('screen')
  stopBtn.style.fontSize = runProgram.style.fontSize = results.style.fontSize = '72px'
  
  wus = 'roll shoulders,arm circles,arm hugs,knee raises,rotate torso,rotate hips'
  wus = wus.split(',')
  
  sets = 'march in place,squat,push up,standing bicycle crunch,stand and box,split squat,push up,plank,jumping jacks,wall sit,push up,standing side crunch'
  sets = sets.split(',')
  
  cools = 'walk,hands up,hands forward,hands back,right leg,left leg,right hams,left hams,balance'
  cools = cools.split(',')
  
  await countdown('check volume.', 5, true)
  
  for wu in wus
    await countdown(wu, 12)
  
  await countdown('first up ' + sets[0])
  
  for set in range(sets.length)
    msg = (set + 1) + '. ' + sets[set]
    await countdown(msg, 30, true)
    if set < sets.length - 1
      await countdown('next up: ' + sets[set + 1])
  
  for cool in cools
    await countdown(cool, 15)
  
  results.html('done')
  lock.release()
  editor.style.display = ''
  
  async def countdown(msg, secs=5, play)
    for s in range(secs)
      results.html(msg + '<br>' + (secs - s))
      if play && secs - s <= 3
        beep.play()
      if cancel
        break
      await sleep(1000)

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)

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.

nice work … would love to have this on my apul watch

Nice work! Love it.