For the me the main issue with dedicated heex files is that for function components you end up with attributes and function head in one file, and the template in another. But It’s those things that I want together! Otherwise, with 90% of my LiveViews not fitting on one screen, the editor splitting argument is moot because I’m going to end up splitting the same file so I can see different part of it at the same time (this isn’t something I personally like doing but I know many do). The other problem is that if there are a lot of little private function components extracted (which is a practice I do not like but many don’t agree), it would be a pain to have to hop through several tiny template files as opposed to being able to scroll through them.
sodapopcan
nikfp
I can see your point. I struggle with picking relevant context out of a lot of noise though, and when it’s all one big ball of markup that’s what happens to me. Playing “find the assign I’m looking for” has taken a lot of time away from me. Dividing it up helps me but YMMV.
As for where to divide it, I’ve found that splitting based on assigns is about right. If I have to prop drill an assign down through multiple components it’s a code smell to me.
cmo
I often set assigns inside render before the sigil, so I moved most of my .sface and .heex to be in the godfile.
the_wildgoose
I also significantly prefer surface over HEEx, however, it seems like it’s now on lifesupport, so I hesitate to use it for new projects?
derek-zhou
I won’t say Surface is on life support. It is a stable and solid library which does not need constant update. I only wish author can release 1.0 to reduce the hesitation of adoption. Besides the prettier syntax, it also offers hook organization and scoped css support, both are very nice.
evnp
Off original topic, but with all the discussion about JSX and DSLs vs string-based templating systems, I’m curious. Anyone using GitHub - mhanberg/temple: An HTML DSL for Elixir and Phoenix · GitHub ?
With Elixir’s macro system we already have the ability, without any extra tooling/compilers, to create a more beautiful/readable/expressive DSL than React devs could ever dream of (disclaimer: I am a begrudging React user but also a longtime enjoyer of JSX, for many of the reasons already stated more eloquently than I could, above).
To me this is such a clear demonstration of the power of the language, and it’s been really eye-opening as an experiment. I personally have yet to write production code with Temple, curious if anyone else has experiences to share.
Translating the example from above:
def my_component(%{error_message: error_message, count: count}) do
temple do
if error_message do
div do: error_message
else
count = (count * 2) - 1
case count do
0 -> div do: "No count!"
n -> ol do
for index <- 1..n do
li do: index
end
end
end
end
end
end
garrison
Temple is neat but fundamentally it is still being used as a templating language, albeit a better one. This isn’t really its fault; it has to work with Phoenix. To get the full benefit you would really want to redesign LiveView’s engine.
Some may not realize this, but React’s engine does not work with HTML at all. The VDOM, nodes, and diffs are all encoded directly into the execution structure as it evaluates the application code. The structure mimics the DOM structure and the tree “matches up” during the diff. They essentially conceptually bypassed HTML completely, which is really the only sane thing to do. The DOM structure is still there, but there is no Markup or Language.
You can see this come up in one of my favorite “mistakes” in Phoenix: LiveComponents need a root node in the template. Why?
Look at these React components:
function GenericPost({children}) {
return <div>{children}</div>
}
function SpecialPost({content}) {
return <GenericPost>{content}</GenericPost>
}
The app tree is:
<SpecialPost>
<GenericPost>
<div>whatever</div>
</GenericPost>
</SpecialPost>
But the DOM tree is only:
<div>whatever</div>
LiveView fails to handle this case, which is problematic because it comes up a lot when you try to compose components. The extra divs you have to insert mess up layout (like CSS grid containers). This is a real problem I’ve had to deal with; it’s not purely academic.
React is able to cope with this because there is no template at all, anywhere. The diffing algorithm is bespoke and understands that a parent can exist with no corresponding DOM node.
bartblast
Since Hologram got mentioned a few times here (@Eiji, @jam), figured I’d chime in – not directly on the original question about template organization, but on the JSX vs templates discussion that emerged, specifically how it relates to Hologram’s design.
The usual JSX argument is expressiveness, right? Being able to freely mix logic and markup. And that’s genuinely powerful for complex conditional logic and heavy data transformation – though whether those should be in the view is another question. But I found that leveraging Elixir’s pattern matching for view variants gives you a different kind of expressiveness that’s really clean.
Let me show what I mean using (slightly simplified) @garrison’s example:
def my_component(%{error_message: error_message, count: count}) do
zero_message = <div>No count!</div>
if error_message do
<div>{error_message}</div>
else
case count do
0 -> zero_message
n -> <ol>{for i <- n, do: <li>{i}</li>}</ol>
end
end
end
Hologram with pattern matched partials (coming soon):
def my_component(%{error_message: nil, count: 0}) do
~HOLO"<div>No count!</div>"
end
def my_component(%{error_message: nil, count: count}) do
~HOLO"""
<ol>
{%for i <- count}
<li>{i}</li>
{/for}
</ol>
"""
end
def my_component(%{error_message: error_message}) do
~HOLO"<div>{error_message}</div>"
end
Now, readability is subjective – I know JSX fans prefer “it’s just code” precisely because there’s no special syntax. But to me, this pattern-matching approach leverages what Elixir is really good at. The template acts as guardrails that naturally push you toward separating concerns, and each variant’s structure is immediately visible. This gets even cleaner when you add computed properties into the mix – derived values stay declarative and outside the template.
You could achieve similar separation in JSX by extracting functions, but it wouldn’t be quite as idiomatic or concise. This is one area where Elixir genuinely has an edge that JavaScript doesn’t.
bartblast
Another reason I went with templates is how they work in Hologram – they compile to data structures, not strings. This makes them fundamentally different from traditional template systems like EEx or ERB.
When I was starting work on Hologram, one of the big design decisions was templates vs a JSX-style approach. I ended up choosing templates – but not traditional string-based templates. Something different that I think sits in an interesting middle ground.
When you write this:
~HOLO"""
<div>
<span>{@foo}</span>
{%for i <- @items}<span>{i}</span>{/for}
</div>
"""
It compiles to something like:
fn vars ->
[
{:element, "div", [],
[
{:text, "\\n "},
{:element, "span", [], [expression: {vars.foo}]},
for i <- vars.items, do: {:element, "span", [], [expression: {i}]},
{:text, "\\n"}
]}
]
end
This is basically what @derek-zhou showed earlier – it’s closer to Clojure’s Hiccup than traditional templates. Because they compile to tuples, there’s potential to support both approaches. For example, when you need full expressiveness, you could drop down to raw tuples like this:
def my_component(%{count: 0}) do
{:div, "No count!"}
end
This isn’t implemented yet, but it’s planned. The template syntax gives you readability in the common case, while the data structure approach keeps the door open for direct tuple manipulation when needed, alternative template systems that compile to the same representation, and interesting possibilities for tooling.
bartblast
There’s also another interesting aspect of templates that compile to data: the potential for compile-time validation of HTML semantics.
Compare these two approaches:
Hologram:
[{:element, "div", [], [...]}]
JSX:
React.createElement('div', null, ...)
JSX represents HTML as function calls that execute to produce elements. This means the HTML structure only exists at runtime - the compiler just sees function calls. Even with static analysis tools like TypeScript or ESLint, certain validations aren’t possible:
- Block vs inline rules:
<p><div></div></p> - Required parent elements:
<li>outside<ul>,<tr>outside<table> - Disallowed interactive nesting: nested
<button>or<a>elements
Yes, TypeScript can catch prop type errors and invalid attributes for specific components, but it can’t validate HTML semantic structure. The issue isn’t insufficient tooling - it’s that the structure is implicit in the runtime execution rather than explicit in the code.
Hologram templates compile to data structures that explicitly represent HTML structure, so the compiler can validate these structural and semantic rules at compile time. It can see “this is a p element containing a div element” and validate against HTML rules before any code runs.