How should Hologram position itself in relation to Phoenix? (Poll)

I voted independent fullstack but I guess my assumption is that when using Hologram I wouldn’t see anything related to Phoenix in the codebase even if it uses Phoenix things like PubSub and simply aliases them. I also assume Hologram will come with a vastly simplified scaffold that will look quite different than your traditional Phoenix app. Maybe that’s not what you have in mind though.

As an aside, will your talk at the recent elixir conf be available at some point? Any updates on the roadmap progress?

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

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.

As long as it works with Ash

Yeah, it does, @zachdaniel has already given Hologram a spin, see: 🎉 Hologram - An Isomorphic Elixir Web Framework is Here! - #11 by zachdaniel

I voted for Hologram being marketed as an Independent Framework.

By independent, this would mean that Hologram has 3 modes :

1. it would be it does not depend on Phoenix to run. Of course, it doesn’t stop it from using Phoenix helper libraries if needed.
2. You can build a full app with Hologram, without Phoenix.
3. Existing Phoenix applications, can use Hologram for some of their modules.

This mixing of frameworks already happens in many places.

1. Ash + Ecto
   You can build app purely on Ecto, or purely on Ash, or mixing Ecto and Ash.
2. Ruby on Rails + Hanami
   In the Ruby world, there are pure Rails apps, pure Hanami apps and Rails+Hanami apps.

In my examples above, both Ash and Hanami are marketed as independents.

@mudspot Thanks for sharing your thoughts! I’d love to clarify a couple of points about your vision for Hologram’s positioning.

In your first point, you wrote:

it would be it does not depend on Phoenix to run. Of course, it doesn’t stop it from using Phoenix helper libraries if needed.

I’m a bit confused about this part. Could you clarify what you mean by “not depend on Phoenix to run”? Are you suggesting that Hologram should:

1. Have its own web server implementation without using Phoenix’s HTTP layer, or
2. Still use Phoenix’s core HTTP functionality but have its own architectural patterns on top?

Also, in your second point:

You can build a full app with Hologram, without Phoenix.

Does this mean you envision Hologram having its own complete stack (including routing, HTTP handling, etc.) that would make Phoenix unnecessary? Or is this more about the developer experience and API design being independent of Phoenix’s patterns?

Hi @bartblast ,

my apologies for the very late reply.

Let me put it this way. If I were to design Hologram as a product,

1. I would make the developer experience / api design on Hologram totally independent of Phoenix’s patterns. (Your last comment). So that when a person looks at Hologram DSL, it doesn’t look and feel Phoenixy at all. In the Ruby world, there’s Rails where Phoenix is analogous to. And there’s Hanami, a different ruby web framework, which Hologram is similar to.

2. That said, Hologram should pick the best libraries available, even if it is a Phoenix library.

3. To answer specifically your questions

Own Web Server without using Phoenix’s HTTP Layer

Yes to this. Phoenix HTTP layer uses either cowboy or bandit. It’s a very thin abstraction layer.
Really nothing stopping Hologram from going to cowboy or bandit straight

Hologram having its own complete stack that would make Phoenix unnecessary

Yes to this. However, the #1 priority should still be the developer experience (back to point 1, first, in terms of importance)

Though having its own complete stack, does not mean that I cannot install a hologram_phoenix module that serves existing Phoenix routes.

LMK if I make sense.

This above thoughts are very brief and deserves a much longer conversation.

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

@mudspot Thanks for the detailed explanation! I think that now I understand your vision - it’s about creating a distinct developer experience while being pragmatic about using the best available tools.