Hologram provides a way to write your entire web application in Elixir, with automatic transpilation to JavaScript for the frontend. It handles client-server communication and server-side commands, while running on top of your Phoenix application. This means you can use it alongside your existing Phoenix code.
I’m worried that this relationship might be causing confusion and potentially hindering adoption.
I’d love to hear your thoughts on how Hologram should position itself to avoid confusion and better serve the community. Thanks!
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?
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.
@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:
Have its own web server implementation without using Phoenix’s HTTP layer, or
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?
Let me put it this way. If I were to design Hologram as a product,
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.
That said, Hologram should pick the best libraries available, even if it is a Phoenix library.
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.
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.
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!
You limited the options some way but let me throw my 2 cents. You could try to position it for API development , think about FastAPI.
API products is a major component of any digital product these days and having a framework specialized in serving it would be of interest. It could have some UI but mainly for required admin and configuration of business logic, access control configuration,.. Etc or it could utilize those ones ftom other libraries.
Hologram’s primary use case is building UIs with pure Elixir that automatically transpile to JavaScript. The client-server communication is just an implementation detail.
Are we talking about the same thing? If so, can you elaborate?
I think I caused some misunderstanding. My suggestion is to make Hologram usable as a glorified static site generator. Your core competency is to transpile Elixir to Javascript to run on the client site, right? Can the transpile process be ran once and be decoupled from a backend at runtime?
I did not pay attention to where you are in development now so I thought from the question maybe you are still at an early stage so I would welcome a lot an API dedicated framework similar to FastAPI “I know we have others doing it now but built in a general purpose to serve other needs too.”
But since you are at that stage I think what some colleagues like @derek-zhou indicated in there responses about making it a front end framework in elixir “at least as a start” because we can have then E2E elixir with a flavor of client side not just server side as phoenix.
If so, can you elaborate?
