A hierarchical progress bar service is a cool idea in principle, for some tasks state is worth decoupling from process memory. I do note that the homepage example changes colour without real hierarchy shown though!
Something worth noting, is that the hierarchy of an important task of some kind might not be known at the start.
It's interesting to consider how to have a great developer UX for managing this. I'd probably want MCP support (or a boring OpenAPI).
If someone can show in a few lines how a developer can have a messy process get meaningful hierarchy and progress added to it and it's child nodes, without being overly rigid or SaaS externality concerns, that would be really cool, it could perhaps help give feedback on some very intractable problems.
People often don't realise that showing useful progress can easily be a really hard distributed systems problem that a lot of real life systems are bottlenecked by.
It's interesting that LLMs might actually be able to help ask questions about progress to help better represent what progress should be shown as, asking about subproblems, helping guide the state with structured decision making etc.
Interesting! I agree that nested / hierarchical progress is not straightforward. Even if all child problems are known, the weighting between their individual progress to compute the overall, aggregated parent progress is not easy to determine as it depends on the relative complexity of the child tasks. Perhaps an LLM could help here, but it would have to know the detailed scope of each task it is tracking. Alternatively, pbar could allow users to set their own weights for each sub-bar, so they could integrate their own logic or an LLM to do that. I didn’t want this to become complex in any way though. I therefore opted to do the same as tqdm. A parent progress bar simply counts how many of its children bars are fully completed. It will show 90% progress if 9 out of 10 child tasks are done, even if the last task takes much longer than the others. You can try it e.g. by making nested loops using the tqdm wrapper.
You've got a great start, I agree that your swap-in interface for tqdm is very important for migration, and so you solved at the right level first, and you've found an interesting problem / solution area with beautiful execution.
I can totally see a "social layer for progress bars" and "Deep Research for progress bars" as valuable things to do on top of it. Like how decision markets and search fit in. Where is reputation and trust? Is metadata encryption needed?
There are developer UX improvements possible of course, as with most things. How exactly parent and child relationships and completions are best represented for an intuitive UX is an interesting circle to square while keeping a simple tqdm API.
I'd love it if this was open-source or zero-knowledge, though that may be a bit of a loaded term when actually wanting client side title / description metadata encryption. I guess you'd want a client doing simple but robust encryption on the metadata, but probably not progress values (or at least not at first, for sanity).
Any plans for a MCP API? It's pretty easy these days.
No plans at this point, but I'm planning to open source it soon, so you can add the MCP API if you like and start building the "social layer for progress bars" ;)
I got "Error Progress bar not found" visiting your https://pbar.io/Y8yg3BG link. However, there are no comments yet, so that might explain it. So this is a service you provide.
I must admit that idea behind this project is nice, but I'm not going to get dependent on someone else's infrastructure (and I think I'm not the only one thinking that way), can I host it myself or is the source not available? I don't see any links to sources or github, so decided to just ask here (and to also make the 1st comment here to see if your link would work now).
Thanks for trying it! The link works for me. The progress bar shows 1% now that there's 1 comment and should update to 2% after my reply ;)
I'm happy to clean up the source a bit and put it on GitHub if people like it and prefer to host it themselves. I thought I'd host it myself under a short, memorable domain, so people can easily try it out and share short links to their progress bars.
Oh, it was an error on my side, the link actually works.
If you are happy to share the code - I think quite some people would be happy. The openness doesn't guarantee, but usually leads to better security, performance, etc.
It is very nice of you to provide such a service (and for free, as I see), but your docs says we, users, better not update stuff faster than once per second and that's quite a big limitation for some big companies with lots of processes to track (which probably can't be grouped together into a single batch update as your docs suggest to do).
Yes, definitely. The service could easily be scaled and rate limits can be increased if users are willing to pay for. Self-hosting is a good alternative, as you already suggested.
I'll work on cleaning up the code, adding some dev documentation and releasing it on GitHub when I find some time. Perhaps this weekend already!
What does the backend architecture look like? Heavily distributed, or everything in-memory on a single address space server? How do you handle users writing tight loops which fetch the endpoint in rapid fire?
It's a Next.js app currently deployed on vercel with a Postgres DB running on supabase. Both are fairly scalable, but not in an optimal way in terms of costs. I'd either have to introduce a Pro pricing plan or get some donations from sponsors. The simple nature of the API would allow to heavily distribute this though, i.e. one could simply shard by progress bar.
Regarding the tight loops: Currently there is just basic rate limiting in place and the Python client batches updates by default. The app is not intended for short-lived progress bars with fast updates. These usually also don't have a good reason to be shared and live on the web. It's really much more useful for slowly updating, long running processes.
This could really help in some corporate network scenarios, where batch jobs run behind a proxy. That usually rules out pull based monitoring while this seems easy to setup
I agree, many of the monitoring tools are much more powerful than this, but also a lot harder to set up. The goal was to build something with as little friction as possible that you can set up in under a minute, which makes it viable for any one-off script you might be running.
A hierarchical progress bar service is a cool idea in principle, for some tasks state is worth decoupling from process memory. I do note that the homepage example changes colour without real hierarchy shown though! Something worth noting, is that the hierarchy of an important task of some kind might not be known at the start. It's interesting to consider how to have a great developer UX for managing this. I'd probably want MCP support (or a boring OpenAPI). If someone can show in a few lines how a developer can have a messy process get meaningful hierarchy and progress added to it and it's child nodes, without being overly rigid or SaaS externality concerns, that would be really cool, it could perhaps help give feedback on some very intractable problems. People often don't realise that showing useful progress can easily be a really hard distributed systems problem that a lot of real life systems are bottlenecked by. It's interesting that LLMs might actually be able to help ask questions about progress to help better represent what progress should be shown as, asking about subproblems, helping guide the state with structured decision making etc.
Interesting! I agree that nested / hierarchical progress is not straightforward. Even if all child problems are known, the weighting between their individual progress to compute the overall, aggregated parent progress is not easy to determine as it depends on the relative complexity of the child tasks. Perhaps an LLM could help here, but it would have to know the detailed scope of each task it is tracking. Alternatively, pbar could allow users to set their own weights for each sub-bar, so they could integrate their own logic or an LLM to do that. I didn’t want this to become complex in any way though. I therefore opted to do the same as tqdm. A parent progress bar simply counts how many of its children bars are fully completed. It will show 90% progress if 9 out of 10 child tasks are done, even if the last task takes much longer than the others. You can try it e.g. by making nested loops using the tqdm wrapper.
You've got a great start, I agree that your swap-in interface for tqdm is very important for migration, and so you solved at the right level first, and you've found an interesting problem / solution area with beautiful execution.
I can totally see a "social layer for progress bars" and "Deep Research for progress bars" as valuable things to do on top of it. Like how decision markets and search fit in. Where is reputation and trust? Is metadata encryption needed?
There are developer UX improvements possible of course, as with most things. How exactly parent and child relationships and completions are best represented for an intuitive UX is an interesting circle to square while keeping a simple tqdm API.
I'd love it if this was open-source or zero-knowledge, though that may be a bit of a loaded term when actually wanting client side title / description metadata encryption. I guess you'd want a client doing simple but robust encryption on the metadata, but probably not progress values (or at least not at first, for sanity).
Any plans for a MCP API? It's pretty easy these days.
No plans at this point, but I'm planning to open source it soon, so you can add the MCP API if you like and start building the "social layer for progress bars" ;)
Like what about key life events?
I got "Error Progress bar not found" visiting your https://pbar.io/Y8yg3BG link. However, there are no comments yet, so that might explain it. So this is a service you provide.
I must admit that idea behind this project is nice, but I'm not going to get dependent on someone else's infrastructure (and I think I'm not the only one thinking that way), can I host it myself or is the source not available? I don't see any links to sources or github, so decided to just ask here (and to also make the 1st comment here to see if your link would work now).
Thanks for trying it! The link works for me. The progress bar shows 1% now that there's 1 comment and should update to 2% after my reply ;)
I'm happy to clean up the source a bit and put it on GitHub if people like it and prefer to host it themselves. I thought I'd host it myself under a short, memorable domain, so people can easily try it out and share short links to their progress bars.
Oh, it was an error on my side, the link actually works.
If you are happy to share the code - I think quite some people would be happy. The openness doesn't guarantee, but usually leads to better security, performance, etc.
It is very nice of you to provide such a service (and for free, as I see), but your docs says we, users, better not update stuff faster than once per second and that's quite a big limitation for some big companies with lots of processes to track (which probably can't be grouped together into a single batch update as your docs suggest to do).
Yes, definitely. The service could easily be scaled and rate limits can be increased if users are willing to pay for. Self-hosting is a good alternative, as you already suggested.
I'll work on cleaning up the code, adding some dev documentation and releasing it on GitHub when I find some time. Perhaps this weekend already!
What does the backend architecture look like? Heavily distributed, or everything in-memory on a single address space server? How do you handle users writing tight loops which fetch the endpoint in rapid fire?
It's a Next.js app currently deployed on vercel with a Postgres DB running on supabase. Both are fairly scalable, but not in an optimal way in terms of costs. I'd either have to introduce a Pro pricing plan or get some donations from sponsors. The simple nature of the API would allow to heavily distribute this though, i.e. one could simply shard by progress bar.
Regarding the tight loops: Currently there is just basic rate limiting in place and the Python client batches updates by default. The app is not intended for short-lived progress bars with fast updates. These usually also don't have a good reason to be shared and live on the web. It's really much more useful for slowly updating, long running processes.
This could really help in some corporate network scenarios, where batch jobs run behind a proxy. That usually rules out pull based monitoring while this seems easy to setup
I agree, many of the monitoring tools are much more powerful than this, but also a lot harder to set up. The goal was to build something with as little friction as possible that you can set up in under a minute, which makes it viable for any one-off script you might be running.
Really clever, nice work. Love the minimal but polished approach you’ve taken
Thanks very much! A minimal approach is indeed one of the goals.
This is an incredibly ingenious feature. I'm speechless. It's one of those "I should have come up with it!" things.
Although the practical use case is unclear.
Make number go up