I have tried it. In-fact, I’m working on a library called “Phoenuxt”; which combines LiveView with Nuxt.js.
Personally, I think the browser side of LiveView took the wrong approach. I would have liked to see two separate JS libraries; where the channel communication and DOM interaction were decoupled. This would create a more modular and less opinionated approach. In its current state, I don’t think it’s a practical replacement for an SPA (particularly an SSR SPA).
Additionally, for LiveView (and Elixir by extension) to gain adoption, I feel it will be important to be able to progressively swap out portions of a site with LiveView. Having opinionated UI/DOM interaction will make that difficult.
The approach I took with Phoenuxt was to create a JS socket channel library (uses the same channel as the regular LiveView logic), and a separate Nuxt.js component. The idea being that what LiveView calls a “view” in JS is now a Vue.js component. This means hot swapping, CSS chunking / code splitting, and even leveraging Vue’s component scripting for the LiveView hooks. It also means using VDOM instead of morphdom. It also means leveraging Vue’s transition logic between views, and leveraging Vue’s router logic for push state. The LiveView data is assigned to the Vue component’s props, allowing you to write Vue.js in your LiveView template! All this is abstracted away, and the backend is unchanged.
I haven’t released this yet to the public, but it’s my personal opinion that something like this will be necessary once we all get past the initial honeymoon phase of LiveView. There are a lot of modern web app considerations that need to be addressed, but it’s my personal opinion that it is totally doable.