Whenever I see examples of LiveView being used it all works seamlessly but the UI always looks very simple, like basic forms, links and buttons. How does one build more custom/complex UI controls with it?
I guess it depends what you mean by "complex ui controls".
You can add "hooks" that attach to any normal element. Those hooks have access to push/pull data/events down the socket, so you can basically set up listeners on any element to trigger what would be your normal REST calls. In that respect you can hook your <canvas> into integrating with a liveview process, but obviously it wont receive any DOM difffing etc. If your entire UI is in a canvas, you're probably better off using another UI framework - but perhaps you would still benefit from having a "live process" on the server with a socket, especially if you have any kind of chrome around it. It can simplify lots of stuff in general such as long running tasks, not having to think about a REST API, etc.
People also integrate directly with React/Svelt/Vue/etc though I dont have personal experience with doing that.
I have a reasonably complex LiveView app that has a complex UI, but they're still forms in the end, if only dressed up. Mostly its composed of "function components" (static-y bits of mark up) or "live components" (things that have some internal state, that I want to separate [sic] from the main process).
Thanks for the detailed response. I took a look at a post where react was still used and driven by server-side state using liveview hooks which looked quite interesting.
Frontend components are frontend, so until JavaScript is the only viable option, the answer is yes.
LiveView is a channel to pass data back and forth between backend and frontend in a very performant and size-effective way, that hides all the complexity involved, making it astonishingly simple to get started.
You can incrementally add client side only UI elements as you need - and if you want to use something more complex there are escape hatches which let you use your frontend framework of choice which can then hook into the LiveView process across the socket.
thats pretty much what happens when backend developers write UI, they mostly care about some ephemeral performance (hoping that their ui will get 1k RPS or something) while performance of existing tools (vue/react/svelte/remix/solid) is already absolutely enough even for heavy cases like high interval trading
This seems like a weird criticism. The motivation for people to switch to LiveView usually doesn't have much to do with performance. Instead it's about removing a whole class of work around client-server interaction. It offers the ability to have a server-powered UI be dynamic without any custom JS, to easily push content from the server to the client when something is updated, stuff like that.
You can add "hooks" that attach to any normal element. Those hooks have access to push/pull data/events down the socket, so you can basically set up listeners on any element to trigger what would be your normal REST calls. In that respect you can hook your <canvas> into integrating with a liveview process, but obviously it wont receive any DOM difffing etc. If your entire UI is in a canvas, you're probably better off using another UI framework - but perhaps you would still benefit from having a "live process" on the server with a socket, especially if you have any kind of chrome around it. It can simplify lots of stuff in general such as long running tasks, not having to think about a REST API, etc.
People also integrate directly with React/Svelt/Vue/etc though I dont have personal experience with doing that.
I have a reasonably complex LiveView app that has a complex UI, but they're still forms in the end, if only dressed up. Mostly its composed of "function components" (static-y bits of mark up) or "live components" (things that have some internal state, that I want to separate [sic] from the main process).