Here's a real-time-ish planning poker written in Go + Htmx in ~500 LoC

App (can take a few seconds to spin up if dormant): https://estimate.work/

Source: https://github.com/weiliddat/estimate-work

I mean I built a pretty featureful P2P planning poker app using React and it's around 1300 lines of typescript.

More, but I don't think it's a mind-blowing difference and I wasn't playing code golf when I wrote it. I wouldn't have used redux if I was!

https://github.com/ceuk/planning-poker

▲

weiliddat 2 days ago | parent [-]

Oh cool, very interesting approach!

Did a quick test, since before this I also used some very ad-heavy p2p solution, and I see similar issues there. Not sure if you're looking for feedback, but these were all issues I considered before settling on a server-based HTMX long-interrupted-polling approach, which if you think about having server + client + realtime-ish features in the context of "just htmx" + tiny LoC is pretty cool (well I think it's pretty cool :D)

In the WebRTC p2p approach, without some sort of sync protocol that validates the state of data:

- the host must be online / already there to join a room; the host leaving the room means everyone gets kicked!

- if you rejoin a room and don't receive updates, you get a partial view of the data

- if you have data connectivity issues, you get a partial view of the data

- you must have a WebRTC capable browser and Internet connection

	▲	ceuk 2 days ago \| parent [-]
		Yeah I set out to build something with WebRTC rather than to build a planning poker app if that makes sense. Just wanted to test out the tech. Having said that, I do still use this off and on and personally the limitations don't bug me too much. Would be a nightmare for more mission-critical software though