How well does Hologram handle SEO?

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 ?

Hologram handles SEO excellently from a technical perspective. The key thing to understand is that Hologram renders pages on the server-side, so when a browser (or search engine crawler) requests a page, it receives the complete HTML content right away - not an empty page that gets populated by JavaScript later.

This means search engines can see and index all your content immediately, which gives you a significant SEO advantage over client-side rendered frameworks. As Lucas mentioned, you can see this in action by viewing the source of any Hologram-powered site - all the content is there in the initial HTML.

From there, SEO performance really depends on how well you optimize your pages using standard techniques:

• Proper meta tags (title, description, keywords)
• Open Graph and Twitter Card metadata
• JSON-LD structured data
• Semantic HTML structure
• Fast loading times
• Mobile responsiveness

Hologram gives you all the tools to implement these optimizations - it’s just a matter of using them effectively in your templates and components.

So in short: Hologram provides excellent server-side rendering that search engines love, and the rest is up to you to implement good SEO practices!

Hope this helps!

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.

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.

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?

That’s exactly the way to go for now IMO: Render the most recent N messages server-side for that initial speed boost and SEO benefits, then progressively load historical data and stream new messages via real-time updates.

Hologram’s init/3 function runs on the server during page rendering, so you can fetch recent messages there and they’ll be baked right into the initial HTML. Then use commands for lazy-loading older messages when users scroll up.

For new message streaming, while Hologram has WebSocket infrastructure, pushing messages from server to client via pub/sub isn’t implemented yet, but it’s on the immediate roadmap. You’d need to implement polling or use commands triggered by user actions for now. The foundation is there though - the WebSocket connection exists and real-time server-to-client messaging and broadcasting is coming soon.

Eventually, a Local-First sync engine that handles all of this syncing automatically would be the holy grail - imagine having offline-capable, conflict-resolving data synchronization built right into the framework. That would eliminate most of the manual state management complexity entirely.

It would make sense for Hologram to notify the component when it’s being restored from browser history (back/forward buttons) so the component can decide whether to trigger a resync. Currently the state just gets restored silently, but having a lifecycle hook like “on history restore” would let you implement smart catch-up logic.

Thanks for the feedback!

I can see there are some misconceptions about how Hologram’s initialization works, so let me clarify the key points.

The most important thing to understand: Each stateful component instance is initialized exactly once during its lifetime. This is a crucial detail that I think will clear up most of your confusion.

I’ve just added a section to the Components page that explains this:

Initialization

Important: Each stateful component instance is initialized exactly once during its lifetime. The initialization method depends on where the component’s lifecycle starts:

• init/3: When the component’s lifecycle starts as part of server-side page rendering (pages are always first rendered on the server when you navigate to them)

• init/2: When the component’s lifecycle starts by being dynamically added to an already-loaded page

A component module can define both functions since you may have multiple instances - some starting on the server and others starting directly on the client. Each instance has its own unique cid and separate state.

(…)

Optional Initialization

Both init/3 and init/2 functions are optional. If you don’t need to initialize state or perform any preparation, you can omit them entirely - Hologram provides default implementations that simply return the Component and Server structs unchanged.

Now to address your specific questions:

Everything else renders on client?

The initial render of any page always happens on the server when you navigate to that page. After that, all rerenders happen on the client as state changes.

What about commands with put_session/3 calls?

Commands are essentially Hologram’s implementation of the command pattern for remote procedure calls. Actions and init/* functions don’t call commands directly - they return commands as instructions to be executed on the server.

What hologram would do if inside a Component we would define both init/2 and init/3?

Both can coexist in the same module because they serve different purposes. Hologram will call the appropriate one based on where the component instance’s lifecycle starts - there’s no conflict.

I think that a new developers would find confusing that there is no init/3 example in your Pages documentation.

I included a basic init/3 in example on the Pages page.

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

Remember that each component instance only initializes once, so you typically wouldn’t need this pattern. If you need different behavior for server vs client initialization, that’s what init/3 vs init/2 is for.

The SEO placeholder pattern you described would typically be handled by having the server-side initialization (init/3) set up the SEO-friendly state, and then client-side updates modify that state as needed.

i’d check whether your pages can render on the server first, since that usually helps with indexing. If not i’ve had good results using pre-rendered static pages for key routes

Hologram has you covered here: pages are always server-rendered on the initial load, and the client takes over afterwards. So SSR-for-indexing works out of the box, no extra setup needed.