That can be worked around by requiring a leading atom to have a space after the curly. eg: {:else} vs { :else}. I understand the dilemma though.
One more question, with the new {#XXX} syntax, are we going to deprecate all colon attributes, such as :for, :props and :if? There is not many left, and for things like :on-click we can go back to phx-click.
:for, :attrs and :props will be deprecated. The others will be kept.
Keep in mind directives manipulates the code at compile-time, usually introducing additional behaviour to improve DX. They are similar to Elixir macros in that sense.
So just as we don’t create Elixir macros to map an existing function without adding some extra behaviour, we don’t map existing attributes to do the same thing. We prefer to create a new abstraction leaving the semantics of existing attributes untouched.
For instance, the :on-click directive, by default, automatically generates both, phx-click and phx-target based on the type of the host component (stateful or stateless). That’s why we don’t use the :phx- prefix. We want to make it explicit that they are not the same thing and if you want to use the original phx- attributes, you can still do it and they should work with the same behaviour as they were originally designed.
One is basically an attribute on a single element. The other can encapsulate many elements.
<button :if={@show_button}>
Button and everything inside hidden if falsy.
</button>
<div>
Never hidden
</div>
Versus
{#if @show_button}
<button>
Hidden if falsy
</button>
<div>
Also hidden if falsy
</div>
{/if}
I know this part. What I wanted to ask was is there anything :if can do but {#if} cannot?
To answer my own question in part, it seems like :if={...} is more efficient. I converted a bunch of :if={...} to {#if...} and observed that the DOM diff down the socket is bigger. I cannot pin point the problem but it feel like the change tracking is not ideal in the cases of if...elseif or cascading if
My unsolicited 5¢. IMO YMMV 
I find that “control attributes” (such as :if, :for and similar) are a net negative on DX (not a large negative, but a negative nonetheless):
My own terminology explainer. Control attributes vs shorthand attributes
Control attributes, well, control the behaviour of an element. So, :if controls whether an element is inserted depending on some condition.
Shorthand attributes are, well, shorthands for often-used things. Like :on-click that generates phx-click and phx-target in one go.
Props are passed down to the element, control attributes “work outside of the element”
With possibly with the exception of class and style, attributes/props are what is passed down to the element, and that let the element control what to do with them. This is especially true if we don’t draw a distinction between regular HTML elements and our custom elements (React-style).
Control attributes kinda break the abstraction. “Look, we pass all this onto the element except this one, this one will be handled by something else”.
They require extra work to compose/refactor
The moment you need an else on an :if, or you need to control more than one element, you have to remove the attribute and use something else. This is less of an issue for an established codebase, but will definitely be a minor pain when prototyping or redesigning.
This also reminds me of how awkward if/else is, for example, in Angular: Angular
Optimised for a special case
Bullet point 2 stems from the fact that control attributes are optimised for a very special case: a single element that we can control.
In my opinion, this is not a good way to optimise. There are way more special cases that we can come up with syntax for, and each special case will be sufficiently different from others that you will need a cheatsheet to remember them all
Even now, what is the actual difference between these three? (the question is a bit toungue-in-cheek 
):
<div :if={ @show_div }>
<div :show={ @show_div }>
<div class="{{ "show": @show }}">
An extension of 1 and 3: they break assumptions because they look like shorthand props
By way of example: :on-click is a shorthand for phx-click phx-target. But :if is not a shorthand. But :show is kinda a shorthand, but it’s a shorthand for something that’s library-defined (is it display: none?)?
In the end, all these may be quite minor gripes, and not matter to most people. But those were my 5¢.
Hi @dmitriid! Thanks for the valuable 5¢.
I agree. That’s why we’re deprecating :for and discussing if we should do the same with :show.
As for :if, I’m not convinced yet. It seems it’s an exception that brings value as I haven’t found yet a Surface user that doesn’t like it (if you’re user, you’re the first one 
that came out). The reason is probably because it’s very handy and looks quite familiar as most of other solutions also provide it. So it’s a tough call and I’ll consider users’ feedback a lot for this one before considering removing it.
For now, there’s no plan to deprecate it based on that feedback. You can consider :if as just a shorthand for {#if}...{/if} when applied to a single node instead of a real flow-control construct. If you need latter, just go with {#if}/{#elseif}/{#else}
Hi @zimt28!
It will be possible to use stateless components in dead views as soon we have a the next LV version released. You can follow Use new `component/3` macro for stateless components · Issue #400 · surface-ui/surface · GitHub for updates.
