Allright! The main use cases are:

Embedded (Phoenix-based) mode:

• For existing Phoenix apps where you can’t or don’t want to fully migrate to Hologram
• To gradually adopt Hologram by adding components/pages incrementally within your Phoenix app
• If you prefer to treat Hologram as just the frontend layer while keeping Phoenix for the backend
• If you prefer staying within Phoenix’s ecosystem and conventions

Standalone mode:

• If you prefer simplicity - convention over configuration
• Goal is to be dead simple and “just work” out of the box
• The end-goal is ambitious: local-first features with a client-side data store that auto-syncs to the backend database, plus cross-platform development (web/mobile/desktop) using the same UI components from a single monorepo. The first standalone version will lay the basic foundation for this vision.

Edit:

See this newer post for a bit more detail: How should Hologram position itself in relation to Phoenix? (Poll) - #26 by bartblast

Yeah, I guess you can say so! I’d love to recreate that seamless ease of use and rapid development that Meteor devs experience (though hopefully fixing some of the architectural issues Meteor has). Zero is definitely on my radar, along with a few other related projects like ElectricSQL and PowerSync. The idea of having a subset of data on the client that syncs automatically is so compelling - so many problems just disappear this way! Add reactive client-side queries to the mix and you’ve got something pretty magical. That’s what I’m hoping to build into Hologram.

Nice. This seems like the best of both worlds.

The best choice is not having to choose!