Hi everyone! 
I’m writing to close the loop and notify those watching this thread. First, thank you all for voting in the poll and sharing your thoughtful feedback – both here and in other threads. It’s been incredibly valuable in shaping Hologram’s direction. I’m now closing the poll as the plans have crystallized.
Here’s what Hologram will be:
Hologram will support two modes of operation:
1. Embedded (Phoenix-based) mode:
- The current version where Hologram works as a library within Phoenix applications
- Use cases:
- 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
2. Standalone mode:
- The upcoming version that will work independently of Phoenix
- Very simple to use, with a minimal structure and no configuration needed – just install and start adding features
- Use cases:
- If you’re building a new project from scratch
- If you prefer simplicity – convention over configuration, with minimal setup required to get started
- If you prefer a cohesive, full-stack development experience built around Hologram’s philosophy, with integrated ready-made solutions (like auth) so you don’t have to choose and configure multiple libraries
- If you want to avoid learning Phoenix concepts and focus purely on Hologram’s patterns
If you’re interested in shaping standalone mode, I’ve opened a dedicated thread where we’re discussing features and ideas: Hologram standalone mode - wishlist and ideas. Would love to hear your thoughts there!
Important note: The same features will be available in both modes. However, in standalone mode, everything will work out of the box with zero configuration since the entire stack is built around Hologram. In embedded mode, while all features will still be accessible, some may require configuration or tweaking to integrate properly with your existing Phoenix setup and libraries.
The end goals (for both modes):
- Seamless Elixir to JS transpilation of client-side code
- Full Elixir client-side runtime that behaves consistently with the server-side Elixir runtime, so you’ll get the same error stacktraces in the browser and the same language semantics (including porting the Elixir process model to the browser eventually)
- Local-first features with a client-side data store that auto-syncs to the backend database
- Cross-platform development (web/mobile/desktop) from a single repository, with the ability to use isomorphic UI components on different platforms. The primary approach will be WebView-based, as gradual improvements in this technology – both performance and features – make it an increasingly viable solution. If this proves unachievable, we’ll explore other approaches, such as making the transpiler more generic and transpiling to other languages as well.
Thanks again to you all for taking the time to weigh in. Exciting times ahead! 
