Surface vs LiveView

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

Until we have a declarative API for LV (which we’re already working on), if you want compile-time checks and use features like named slots or context, you need to define a module as vanilla function components do not provide any metadata required for those features.

So my take for now is to define modules for larger components with many of props/data/slots (where compile-time checks are more valuable) and vanilla function components for either private or smaller/simpler components.

Regarding slots, the next version of Surface will replace its original custom slot implementation for the recently introduced built-in slots, so this is not going to be an issue anymore and as soon as we have a unified declarative API, there will be no more limitations as all metadata we need for most (or maybe all) of the other features will also be available.

Generally speaking compiling a module with 100 functions will be faster than compiling 100 modules with one function each. This is very easy to verify yourself and you can try locally. The multiple modules version is 80-90% slower in my quick experiment. And if we are talking about a project, each module is likely a separate file, so there are more disk reads, more mtime checks, etc.

That said, I don’t think folks should generally be worried about creating modules and files. But if most of your modules are single file functions, it may be that you are having the wrong abstraction.