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.