There’s an important clarification about Hologram’s architecture - it’s misleading to classify it as SSR because “SSR” can mean different things: rendering pages (e.g. initial HTML) vs rendering each interaction (like LiveView/Hotwire).

Your Bold Button Concern - Already Solved!

You thought clicking Bold would go through the server, but it’s the opposite - it runs entirely client-side because Hologram transpiles your Elixir action/3 function to JavaScript.

No server round-trip for UI interactions.

Proof: SVG Drawing Demo - each mouse move runs client-side, not server round-trips.

Hologram’s Real Value Proposition

The key insight is transpiling Elixir to JavaScript - don’t focus on current features, but what this enables:

Right now: Nothing prevents you from running your whole Hologram app as one big page, only touching the server for data commands.

Technically possible: Hologram could bundle multiple pages for full SPA experience, handle multiple routes from one page, or change browser path via history.pushState without actual navigation.

How Navigation Actually Works

History navigation: Completely client-side. State is serialized and saved when navigating away, deserializes when returning. No refetching if page code is already registered.

Link navigation: Fetches pages (usually what you want)

Data Loading Strategies

You can render placeholders for expensive calculations and fetch data later with commands. True SPA-like behavior without any server data fetching would need Local-First features (like ElectricSQL) - that’s on Hologram’s roadmap but separate from your Bold button use case.

Architecture Comparison

I don’t see any benefits in “Phoenix WebSocket + Svelte SPA” vs Hologram. You’d get more complexity, dual codebases, and manual state coordination for the same result Hologram already gives you.

Bottom line: Your UI interactions already run client-side. Hologram’s transpilation makes it fundamentally different from server-dependent frameworks.

If you view source on the documentation site (which uses Hologram), all the content is present in the generated HTML on first load. I guess you could also render opengraph metadata, all standard meta tags and JSON-LD excerpts with the framework ?

Oh, right … it’s SSR … makes sense. What I’m looking for my specific project is rather a mixed approach. The initial render should be done on server, but all the rest should be done on the client side. Therefore the initial render would generate a placeholder-like content with SEO & no-JS compatibility allowing client to focus only on the application itself.

Think about an editor like on this forum … do we really have to render things on server every time we are clicking on B button? Also I’m looking for saving as much server resources as possible to make server focus on the tasks that could be done only on it …

I think that no framework gives me such a flexibility and I should rather choose Phoenix WebSocket + Svelte SPA setup … This would be a bit manual, but it should be the best option for my use case … For sure I understand that at least on start both LiveView and Hologram would just work for me, but for the best scalability if after some time I would anyway need to change then it’s better to start from this setup to avoid an app rewrite in the future.

I’m wondering how you might approach data loading for something like a chat app (or realtime forum) with Hologram. It seems like maybe you could get a small speed boost by rendering the most recent N messages server side when navigating to a room. Then new messages could be streamed and historical messages could be fetched. But I’m not sure what other complexities that might introduce in Hologram or if it would “just work”. There’s a nice simplicity with traditional SPAs but it’s not without tradeoffs. Is there a way to get the best of both worlds without making things too complicated?

This is interesting and makes sense for more static content. What are your thoughts on the more dynamic use case? It’d be nice to keep the state in sync for some period (maybe using pubsub subscription) so that if the user navigates back the state is still in sync and doesn’t require more server round trips.

Interesting … I wanted to visualise how it works and found in the docs:

• They are always initialized on the server-side using init/3, unlike regular components which can be initialized on either client or server

Souce: Pages - Hologram

and:

The init/2 function is used when the component is first loaded on the client.

Source: Components - Hologram

If I understand correctly Hologram renders template depending on the context like:

1. All placeholder / SEO related functionality should be done in the Page.init/3 or Component.init/3
2. Everything else renders on client? What about commands with put_session/3 calls? Look that we can call a command from the init as well as from the action and some people would find it confusing.
3. If we don’t want to render specific template (or it’s part) on the server then we either use a separate Component with init/2 or we pass empty (nil for if or empty list for each) server state and set the right data in the client state

Is that correct?

Do you support or plan to support a condition to check if we are rendering template on the client?

<div id="seo-placeholder">
  <!-- server renders @data here -->
</div>
<div id="app">
  <!-- client renders @data here on some condition and hides div#seo-placeholder when done -->
</div>

In theory we can simply put a state on the server and change it on the client, but since hologram already knows context it feels like a waste. Think that to do it properly in a complex template we would have to check if few props are nil and some people would rely only on only one which may be error prone if by accident it would be changed in the server state.

Therefore we could have some dev-only optimisation checks. Look that if hologram would not detect a server state usage in the template then it could show a warning about unused state (similar to unused variable in Elixir). This with a clear separation of client-side rendered template would really improve the developer experience by avoiding a very simple bugs in the code that sometimes may be hard to notice.

What hologram would do if inside a Component we would define both init/2 and init/3? I guess that it would either raise on compilation time or use init/3 first and maybe even ignore init/2?

I think that a new developers would find confusing that there is no init/3 example in your Pages documentation. I know there is one in the Quick Start section, but I believe that you should show even the simplest examples in mentioned page too.

Could you please clarify in the documentation when the rendering happens and provide some examples? Since on the server we can change the client state for some people it may be a bit confusing. SEO is a very important and many people would like to create a placeholders for the client state and simulate in DevTools a very slow connection, so maybe a separate small guide with a list of cases and simple example would be a good idea here?