Hologram Roadmap Unveiled: The Path to ElixirConf 2025 and Beyond

[bartblast]

@Eiji

Support for Phoenix templates

Just think that every project and every library on hex that uses Phoenix templates needs to be rewritten to support Hologram not because the logic changes, but because it uses different syntax or something only different sigil. It’s like Linux vs Windows - sure, Linux have many native games, but it’s still better to optionally support Windows, right?

I believe that such thing would definitely speed up Hologram adoption. Just think that all default Phoenix templates and generators would be supported out-of-the-box by Hologram. For sure it’s not #1 must have, but something I would definitely like to see before 1.0.0 release.

Regarding Phoenix template support - I understand that compatibility with Phoenix templates would certainly ease adoption and reduce the migration burden for developers looking to try Hologram. It’s a thoughtful suggestion that I’ve considered carefully.

However, after weighing the tradeoffs, I’ve decided not to pursue Phoenix template compatibility for several important reasons:

1. Divergent Design Philosophies: Hologram and Phoenix have fundamentally different approaches to UI rendering. Hologram is designed for client-side rendering with Elixir-to-JavaScript transpilation, while Phoenix templates are server-rendered. Supporting both could create conceptual inconsistencies and may confuse developers (point 3).

2. Maintenance Burden: Supporting two template syntaxes means maintaining two parallel systems, doubling the work for every feature, bug fix, and optimization. This could significantly slow down Hologram’s development.

3. Confusing Developer Experience: Offering two ways to do the same thing can create decision fatigue and confusion for developers. New users might struggle to understand which approach to use when.

4. Diluted Innovation: By trying to maintain compatibility with Phoenix templates, we might constrain Hologram’s ability to innovate in ways that are optimized for client-side rendering patterns.

5. Optimization Challenges: Hologram’s template system is optimized for its specific transpilation approach (and will be optimized even more). Phoenix templates might not transpile as efficiently to JavaScript, potentially leading to performance issues.

6. Documentation Complexity: Having to document two parallel systems would make the documentation more complex and potentially harder to navigate.

7. Testing Overhead: We’d need to test all features across both template systems, increasing the testing burden.

8. Divergent Evolution: As Phoenix continues to evolve its template system, maintaining compatibility would become increasingly difficult over time.

9. Mixed Paradigms: Phoenix templates are designed with server-side rendering in mind, while Hologram templates are designed for client-side rendering. These different paradigms might lead to subtle bugs or unexpected behaviors when mixing approaches.

10. Clear Differentiation: Having a distinct template syntax helps clearly position Hologram as a different approach to UI development in Elixir, rather than just an alternative to Phoenix LiveView.

11. Focus on Core Strengths: By focusing exclusively on own template system, we can ensure it’s the best it can be, rather than dividing resources between two systems.

12. Migration Path vs. Compatibility: Instead of supporting Phoenix templates directly, we could focus on providing clear migration paths and tools to help developers transition from Phoenix to Hologram.

I believe that maintaining a focused, single-template approach will ultimately lead to a better developer experience and a stronger framework in the long run. That said, I’m committed to providing clear migration paths and documentation to help Phoenix developers transition to Hologram as smoothly as possible.