Last week, I realized that it’s been nearly a decade since I published my checklist-manifesto applet using FHIR and Meteor. So over the weekend, I went and vibe-coded a rewrite using the latest tooling.
I’ve been preparing to pivot back into software product ownership; and this was a nice little one-off exercise to make sure that the @accounts-js and meteor-desktop still work as expected. If you use a Mac, feel free to download the latest build and give it a try.
Hi @awatson1978 ! Great to see you come back with something I can understand (not a bunch of medical industry gobbledygook! 
)
It looks really nice (on the screenshot) and I like the reference to “the checklist manifesto” - It’s a great book IMHO, I enjoyed it very much! I would love to have a nice way to keep personal (and maybe professional, but that’d probably imply multiplayer / multiuser support) SOPs and Checklists ready to click through in a simple and effective fashion!
And it ties in nicely with your medical and professional process-based background I think!
I gave it a quick whirl, and I stumbled across two issues:
a) the download page shows me an error (but then starts the download) AND then tries to repeatedly re-download the .dmg (I really only need it once)
but unfortunately b) is a blocker; the app doesn’t load / start correctly on my machine. I’ll attach a screenshot for you.
Let me know or PM me here if you want more details or if I can help you debug this.
Thank you and nice to see you around & being creative!
Amazing! I have looked into meteor-desktop yesterday. There are still many issues and I couldn’t get it to work on my machine, but I will keep at it so that we can get to a new version in the near future.
@DanielDornhardt - Hi! Thank you for giving the rebuild a try. The issue you’re running into is simply that the desktop app requires the source code to be run, so the desktop can connect to the server component.
There are pros/cons to this architecture. Obviously, it’s not a stand-alone app; and sets up unmet expectations when one downloads and installs the software. On the other hand, all of the source code for the server is there, and developing server connectivity for the desktop app is an effort unto itself; so this actually provides a more enterprise oriented application from the get-go.
I’ve spent the past three days trying to build an all-in-one self contained distributable file. That, however, involves downloading the MongoDB binaries and shipping them in the distributable file. It’s been more difficult than I expected; and I’ve been hitting walls. There are issues with connectivity diagnostics, downloading architecture binaries, absolute paths, babel, a race conditions where the desktop launches before the server is run, etc.
So… options forward:
a) improve the readme to explain that the source code needs to be downloaded and run as a server, so the desktop app works.
b) maybe disable and remove Mongo altogether from the app, and create a serverless application, that stores data into LocalStorage or into a flat file.
c) get additional help from the Meteor community to figure out how to bundle the MongoDB binaries into the meteor-desktop pipeline.
d) ask Claude to write a meteor desktop alternative, using whatever latest technologies it recommends. It’s been very optimistic about just rewriting bundler and installation scripts. I’m wondering if it makes sense to just ditch the atmosphere packages. I’m also of the opinion that the .desktop directory maybe shouldn’t be prepended with a . and should just be more of a well-known directory like /client and /server, and be handled with .meteorignore as needed.
@storyteller - thoughts?
Hi @awatson1978 !
I see that you have instructions on the Github page on how to run the app.
Maybe a small note in the “download” info box on the homepage that a server has to be started (for now) would be good, because that’s why I didn’t “get it”, I downloaded from there & expected it to be working, because there were no further instructions.
Very nice and clean looking page by the way.
