Good exploration but a better approach, in my opinion, is using a web component. It can be integrated with LiveView better and also forms and so on. Nowadays there’s a myriad of browser APIs which are easy to use from a web component.

Absolutely! Web components + Lit (+ a couple of extra directives) and there’s nothing you can’t do.
We’ve just started switching from Alpine to web components and it’s a bliss!

I see.

As a general pattern they promote parent → child communication via properties and child to parent via custom events. However, the former is only applicable when the composition is done within the web components themselves.

In our case (LiveView, where composition is achieved with LiveComponents) my take is the communication between web components need to be designed differently. First, if LiveView is the source of ultimate/eventual truth for the state that is also present server-side, for that part the rendering (or push_event) should have the last say at all levels of nesting. As for a pure client-side state and the communication thereof, the pattern is more like this:

• parent → children: custom event on window with the children listening
• child → parent: el.closest( ‘my-parent-web-component’).gimmeWhatIWant() // way faster than custom events

The principal difference is in the underlying intent. Generally, web components are meant to be reusable, universal and isolated which is why they promote loose coupling. In our case with LiveView, where we use web components within a predetermined DOM hierarchy within which they role is to implement the client-side state and behavior, we only need resort to events so we can benefit from their mechanics and no longer to promote a loose coupling (unless, of course, a particular web component is truly generic).