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:

Congrats! Very nice progress!

Looping everyone in: @Eiji quotes fragments of a discussion we had in a GitHub issue: Missing or undocumented features when adding Hologram support to existing LiveView app · Issue #181 · bartblast/hologram · GitHub

Correct.

These are two separate things - in some scenarios we may need to just trigger an action for a single connection (window tab) without having to define a subscription in a component. The DSL would be for channel-like scenarios where we want to send to specific topics (e.g. chat scenario). What are your thoughts in this regard?

I agree with @jam - this would be confusing if we supported both.

I don’t reject the idea of introducing some simple syntax for partials eventually, but not in the medium-term.

Can you elaborate on that?

Browsers collapse sequences of whitespace into a single space when rendering text content. For block elements, whitespace at the beginning and end of content is ignored entirely. In normal text flow, no matter how many spaces, tabs, or line breaks you have between words, they’ll render as a single space. There are specific exceptions to this, but in such rare cases (like <pre> elements) you can just write the if block without surrounding whitespaces.

Minifying whitespace text nodes makes sense, though, in my opinion.

At the moment there is no way to react to prop changes. The only things that can change the state are actions that react to DOM events, other actions, or commands.

Example use case is described here: How to modify component state in reaction to a prop change? · Issue #161 · bartblast/hologram · GitHub