Surface vs LiveView

1. AFAIK there should be none as Surface is mostly just compiler with some helper functions. This mean that it produces iovec the same as “regular” compiler.
2. I do not use Surface right now, so I cannot tell.
3. There should be no problems, as Surface component is still LV Component. In the same vain as Phoenix controller is still just a Plug and you can mix these as you please.

I recently added Surface to one of our LiveView apps and didn’t face any challenges. As @hauleth mentioned, Surface is only a compiler so the underlying components are LiveViews and your controller code doesn’t need to change at all.

That said, there is a useful @data macro for assigns that you could use. Since it’s pretty early days, you may find yourself building some components yourself (we have a custom table, panel and buttons).

I am not entirely sure how I feel about having part of the app in pure LiveView and part of it in Surface. I have decided to pause the migration and wait for the upcoming Phoenix.Component (EDIT).

There is a big change coming with Liveview 0.16 with a new Html engine.

https://github.com/phoenixframework/phoenix_live_view/blob/master/CHANGELOG.md

Some rewrite will be needed to support the new syntax.

Also the reason I paused. I would rather move to the canonical solution.

My understanding is that a Phoenix.Component can be used in both LiveView and eex templates although I can’t seem to recall where I picked this up.

Correct! And Surface will likely just use Phoenix.Component too, so everything should be using the same abstractions.

Yes. It will use Phoenix.Component for sure. Using the same abstractions means you’ll be able to write components using Surface or HEEx and use them in any LV project. There are still some features we need to bring to LV itself to make that become a reality but we’re already working on it and we hope we can get there soon.

First of all thanks for Surface - it massively eased my path into LiveView because of the familiarity of components & Bulma.

Given Phoenix.Component, what would you say will become Surface’s USP? Why would one choose it over the built-ins? (Curious, not rude!)

Surface is built upon LiveView, so it is not Surface vs LiveView, but really Surface vs leex. The biggest benefit to me is that Surface is more curated; it nudges you onto the right track without taking away functionality. leex is very powerful, but there are too many ways to shoot yourself in the foot.

Thanks everyone for the great answers. I’m definitely going to try out Surface now.

cheers

Dave

In addition to what @derek-zhou said, Surface comes with a lot of features that Phoenix Live View does not support (yet?). Here is a non-exhaustive list of these features:

• Declarative properties with prop, slot, data
• Multiple slots that are placeholders declared by a component that you can fill up with custom content. Imagine a Card component with a header and a footer slots https://surface-ui.org/slots
• built-in directives: :if, :show, … https://surface-ui.org/template_syntax#directives
• Control flow management: if/elseif/else, for/else, case/match ! https://surface-ui.org/template_syntax#blocks

• Event always linked to the component and not to the parent live view https://surface-ui.org/events#pass-event-through-an-event-property
• Tagged expression, ...attrs, ...props, … (For example <MyComponent active={@active} /> could be rewrited to <MyComponent {=@active} />) https://surface-ui.org/template_syntax#tagged-expressions
• Compile-time checking
• Context Management: Surface
• Colocated Hook js file
• …

Feel free to look at https://surface-ui.org or join the Surface slack channel for more info