The offline support story here looks interesting. My Elixir/Phoenix app, which relies heavily on LiveView, has some new "offline" and "low bandwidth" set of requirements.

Can Hologram sit alongside the existing routes of a Phoenix app?

▲

bartblast 4 days ago | parent [-]

Yes, absolutely! Hologram can work on top of Phoenix and coexist peacefully with LiveView in the same app. You can have some routes handled by LiveView for server-rendered interactions, and other routes handled by Hologram for client-side interactions that need to work offline or on low bandwidth. The session data is shared between them, so users can seamlessly move between LiveView and Hologram pages while maintaining their authentication state and other session information.

This is actually a really nice migration path - you don't have to rewrite your entire app. You can gradually move specific features to Hologram where offline support or instant responsiveness matters most, while keeping LiveView for parts where server-side rendering is enough.

For your offline/low bandwidth requirements specifically, Hologram is perfect because once the JavaScript is loaded, all the UI logic runs locally. No more waiting for server roundtrips on every interaction, and the app continues working even when connectivity is spotty.

▲

bdunks 3 days ago | parent | next [-]

I've just read through the entire documentation end-to-end. It's very clear and well written, thank you for the time and love.

One thing that's unclear to me in how I might manage this "side-by-side coexistence": how you manage potential route conflicts, e.g., You have a Hologram "page" that defines `route "/hello-world"`, and the Phoenix application router.ex also defines a route, `live "/hello-world', MyApp.HellowWorld, :index`.

I could imagine the lack of a central router may be offset through conventions of how you organize pages (perhaps a directory-based-routing convention). I saw in the Installation section that it's common to organize under `app/`, and `app/pages`. Maybe an expansion on best practices for larger project organization, and how you keep Hologram routes straight, would be interesting to other people as well.

Regardless, I've just started dipping my toes in the elixir and phoenix ecosystem about 3 months ago, and it's been a real joy. I'm throwing every hobby project I can think of at it to learn more. I'll give hologram a spin -- thanks again for such clear documentation.

	▲	bartblast 3 days ago \| parent [-]
		Thanks for the kind words about the documentation! I'm glad it came across as clear - I put a lot of effort into making it accessible. You raise an excellent point about route conflicts. I'm actually thinking about detecting these at compilation time and throwing an error with details about which routes are conflicting and where they're defined. That should catch these issues early and make them easy to resolve. The best practices guide is definitely a great idea and something I've been thinking about. I already have some ideas regarding project organization and routing conventions, but I want to ship a few more core features first before diving deep into that documentation. Hologram really obsesses over developer experience, and comprehensive docs are a big part of that :) It's awesome to hear you're enjoying the Elixir/Phoenix ecosystem! Three months in and already exploring different frameworks shows great curiosity. I'd love to hear how your experience goes with Hologram when you give it a spin. Thanks again for reading through all the docs and providing such thoughtful feedback! :)

▲

dsiegel2275 4 days ago | parent | prev [-]

Thank you for the reply! I will be looking into this for sure.