Hi @cvkmohan!
Under the hood, since Surface is built on top of LiveView, it will always be a one-to-one mapping.
From the design perspective, however, I believe there are differences. The main one is that, since Surface provides a higher level declarative approach that standardizes the way you define components, it fosters splitting the view into more fine-grained components that will have a more predictable and safer way to compose with other components, especially through the use of slots.
In my experience, users tend to avoid creating components when they don’t have a standard way to declare their public interface (properties, exposed events, slots, etc.). They know it might be a pain to maintain or simply reuse a component in the future when they don’t remember exactly how it behaves or interacts with other components.
To remove or at least mitigate that hesitation, it’s imperative to provide a declarative API with at least a minimal set of compile-time checks that can give the user confidence to take a step further and start thinking about the whole view as a tree of reusable components instead of a set of opaque pieces of templates.
I’m confident LiveView will move in that direction too. When that happen (if that happen), the model will become more similar, consequently, the way we design components will also get closer or even the same.
