Posting this as a separate thread as I’m sure lots of people will be curious - what will the (or the intended) differences be and when might you want to use one over the other Bart?
1 Like
Allright! The main use cases are:
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.
10 Likes
Let’s go! 
3 Likes
Nice. This seems like the best of both worlds.
The best choice is not having to choose!
4 Likes
Your end goal reminds me a lot of MeteorJS or https://zero.rocicorp.dev/. Is that accurate? Excited to follow the development of Hologram.
2 Likes
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.
4 Likes
Yes! This is the dream and why I’m a big fan of the Hologram vision. Meteor’s DX is unmatched to this day which is crazy. Even Zero, inspired by Meteor, doesn’t quite match it imo. InstantDB looks interesting but it seems you’re completely at their mercy and scaling is anyone’s guess.
Once you sync subsets of data to the client, any other way feels archaic. Now, beyond a certain scale, Meteor’s approach to syncing those subsets will run into issues. This is what originally led me to Elixir and the BEAM, the other benefits were mostly icing on the cake.
2 Likes
