Hologram v0.5.0 released!

The svg drawing demo looks hella slick & hella cool! I would love to see the repo, if possible? It would force me to actually check out hologram for real (dabbled just a bit when it came out).

curiosity killed the cat but satisfaction brought it back

Sorry if this was asked before, but do you plan to make hologram easily integrate with a LV project?

I’m very interesting in testing hologram out, but it is hard to justify the time to do that now since I don’t have a new project to use it, and at the same time, I don’t plan in rewrite all my LV projects in Hologram. So, having a way to easily integrate it with a LV page (maybe a way to add hologram components or something like that? Dunno) would be amazing and probably open doors to easily solve lateny critical parts to a LV project.

I have already suggested something like that, but it was not accepted. Also looks like there would be no support for :for and siblings, so you have to write the templates in Svelte-like syntax. For me this is one more important as in complex components I don’t want to have “half” of the indentation levels to be added by control flow (like if, for etc.) …

What I’m personally looking for is some way to communicate with page asynchronously. Looks like in the medium-term goal there would be:

• Component Subscription DSL - Create a DSL for integrating with Phoenix PubSub for real-time updates.

Preferably I would like to use send/2 and Process.send_after/3 depending on a case. Simply everything that happens in background, but affects the rendering like bot moves every pre-configured time, sending data from Repo.stream without querying all the rows or paginating them, next background music event and many, many more …

Congrats Bart! Looking great.

Congratulations on the release.

One thing that I’m taking away from the changelog is that it might be time to start taking some parts of Hologram and release them as individual specialized libraries, maybe. I’m periodically taking a look and there seems to be some mighty useful Elixir pieces in there.

I’m not saying this to give you homework. But it might help adoption.

Very cool! I would be curious about the journey of what went into optimizing the performance of Hologram.

That could be done anytime. If author decides it should be done right before 1.0.0 release. I believe there are too many important parts that blocks people from using Hologram right now. We should rather allow the author focus on them.

I disagree with this. The goal should be something like JSX where there is no template syntax at all and the templates are actually constructed with JS (with the syntax extended to make it look nicer). The :if/:for syntax, which afaik was a hack to make slots work, was a huge step backwards in this respect for Phoenix. The original eex/heex “templates” are actually full Elixir with text/html interspersed and thus far more powerful.

Templating languages are always degenerate. As a simple example, why is there no :case attribute? The case construct spans (possible) elements, so it doesn’t even make sense as an attribute. The control flow is a higher level construct than an individual element and can’t be constrained to one. It’s a mistake to go down this path at all.

It’s unfortunate because case is one of Elixir’s best features and I strongly favor it over if, even in heex.

With that said, it seems like Hologram’s templates are in fact actually templates rather than code, so that’s not any better if so.

(Incredible work on the release BTW, that’s a lot of commits!)

Video courses are coming soon in about 2-3 weeks.

The demo is a part of the website code which is currently private, but here’s the most important code:

init/3 (state initialization) and actions (event handling):

def init(_params, component, _server) do
  put_state(component, drawing?: false, path: "")
end

def action(:clear_canvas, _params, component) do
  put_state(component, drawing?: false, path: "")
end

def action(:draw_move, params, %{state: %{drawing?: true}} = component) do
  new_path = component.state.path <> " L #{params.event.offset_x} #{params.event.offset_y}"
  put_state(component, :path, new_path)
end

def action(:draw_move, _params, component) do
  component
end

def action(:start_drawing, params, component) do
  new_path = component.state.path <> " M #{params.event.offset_x} #{params.event.offset_y}"
  put_state(component, drawing?: true, path: new_path)
end

def action(:stop_drawing, _params, component) do
  put_state(component, :drawing?, false)
end

and the most important part of the template:

(...)
  <button $click="clear_canvas" class={Button.class(:md)}>Clear</button>
</div>
<svg 
  class="bg-[#0F1014] cursor-crosshair border border-[#363636] rounded w-full h-[70vh]"
  style="touch-action: none;"
  $pointer_down="start_drawing"
  $pointer_move="draw_move"
  $pointer_up="stop_drawing"
  $pointer_cancel="stop_drawing"
>
  <path d={@path} stroke="#C2BBD3" stroke-width="2" fill="none" />
</svg>

Hologram can be used alongside LiveView in the same Phoenix application. You can have some pages running in LiveView and others in Hologram - they can coexist peacefully.

However, I don’t plan to work on direct Hologram/LiveView integration (like embedding Hologram components within LiveView pages or vice versa). This would introduce significant complexity and several drawbacks, including maintenance burden, architecture lock-in, conflicting paradigms, performance overhead, and others.

If you need to stick with LiveView for any reason (time constraints, existing codebase, etc.), you can always gradually migrate specific pages to Hologram when it aligns with your project’s requirements. This approach gives you the flexibility to use both frameworks without the complexity of trying to make them work together. Additionally, I plan to start working on a companion UI components library soon, which should significantly reduce the time investment needed to build interfaces with Hologram and make migration easier.