Looking good! Thanks for sharing.

JS Interop

Curious what this might look like.

Component Subscription DSL

This definitely caught my attention. Would be interested to learn more.

I think Svelte-like blocks are much more readable and maintainable than Vue-like ones

fwiw, I agree. I also think that supporting both would be more confusing.

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.

When props change, the component is not reinitialized - this is similar to how both LiveView and modern JS frameworks work. Components persist across renders, and only their props are updated. You’re right that the goal is similar to LiveView’s update function, though I prefer a more declarative approach where components can listen for specific prop changes. One key difference is that LiveView’s update doesn’t have access to previous prop values, only the new ones.

No worries at all, I’m here to explain and answer your questions!

I appreciate your inquisitiveness. It’s important to note that I don’t expect users to understand these implementation details. In fact, the goal of Hologram is to let developers focus on shipping features without worrying about the underlying boilerplate they’d otherwise have to write.

If you’re interested in understanding what’s happening with the scripts, you can check out the UI.Runtime module here:

https://github.com/bartblast/hologram/blob/master/lib/hologram/ui/runtime.ex