Some thoughts Bart…

As an independent full-stack framework

Does Hologram require Phoenix to run? If so I don’t think this option would be worth pursuing (unless you have plans for it to run without Phoenix).

As a frontend framework that extends Phoenix

Will Hologram (or is your intended use of it, to) just handle the FE aspects of an app? If so this could be a good option - use Phoenix, and then when you need heavier client side functionality (beyond LiveView) slot in Hologram.

As a full-stack framework that extends Phoenix

This could be another option but I think you’d need to be clear why someone might want to use Hologram instead of Phoenix if they are having to install Phoenix anyway.

I’d actually suggest that it might be worth putting out some screencasts first yo help show how Hologram can be used, what your intended vision was, and what your ideas or areas of exploration are. I would try to keep the screencasts short as that may lead to more people viewing them (and so more being able to offer an opinion).

In general though I am a firm believer in pursuing what you are most passionate about, so if you have one particular vision in mind I’d say go for it!

One thing I might add though is I think it would be difficult to compete with Phoenix. As we’ve seen from large established frameworks (like Rails, and now Phoenix) once they get to a certain point it is hard to displace them, and the other frameworks often just get a smaller, more niche share, unless, they have the potential to replace the current leader on all or most fronts that the leader currently excels in - and then some. I think Volt (Ruby) was a good example of this.

Personally I really like the idea of being able to use Hologram for parts of an app when Phoenix and LiveView might not be enough, but I’d really need to see what Hologram is capable of, what it can be used for etc (as above) before forming a more concrete opinion.

Either way good luck, I’m sure there’s a place for Hologram in the ecosystem

I think having more independent frameworks is a good thing because there is more space to experiment with new ideas. Even if Phoenix remains the biggest framework, good ideas from others’ work will bubble back up eventually and make the whole ecosystem better.

The Elixir community is pretty small and yet this has already happened many times, e.g. the component work from Surface making it back into LiveView.

At the moment yes, Hologram does require Phoenix to run. However, at the current stage it would be relatively doable to make it run separately if there was demand for that direction.

At the moment that’s essentially the case - Hologram handles the frontend aspects. But I’ve got some ideas related to cross-platform development that would necessitate increasing the scope beyond just frontend concerns. Additionally, implementing some features I envision related to offline support (including client-side data store) would probably require some database integration, which would push beyond pure frontend territory.

Regarding the screencasts - that’s definitely in the plan and I’m consistently hearing this feedback from the community. I’m planning to create a video playlist once the short-term goals on the roadmap are completed and the framework supports the minimal features that make it usable for real-world applications.

Yeah, that’s my thoughts as well. You make a valid point about the challenges of establishing a framework in an ecosystem with such a strong incumbent. Though I think there’s always room for innovation that can bring genuinely new approaches and capabilities to the table - sometimes that’s what creates those breakthrough moments that shift the landscape.

Thanks again for taking the time to share your insights - really valuable perspective!

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!

Yes, it will be available. I need to talk to Code Sync (who will publish the talks) about their plans.

Expect a big release soon