I agree. I might do it. Just, please help me to decide on name.
VueLive - I think it has the same problem
LiveVuejs - my personal favourite. That suffix should make it distinguishable and keep that nice “vibe”
some other reasonable options..? 
Jskalc
1
arcanemachine
VueLive is a step in the right direction, but I agree that it’s also confusing.
There’s no rush on picking a name. I find that if you give these things a bit of time, something will pop into your head when you’re doing the dishes or something like that.
Maybe something like LiveInterVue? As in “LiveView with Vue Interop”.
VueJsLive is also an option. A little awkward but gets the point across pretty well IMO. It’s Vue.js, but Live.
I’ll see if I can think of anything else. I don’t want to be the guy who only brings up problems and offers no solutions. But this one is tough because the names are like, the same. 
1
KP123
arcanemachine
derek-zhou
katafrakt
I seem to be in a minority that thinks that this name is fine. We have LiveSvelte, I’m sure we will soon have LiveReact, LiveSolid, LiveQwik and whatnot. It will hurt the discoverability of this one project and the phonetic similarity is less of a problem when the distinction in written text is clear.
12
KP123
Another thing to consider is the fact that this project started as a fork of LiveSvelte. I’m unsure how much it’s deviated since the fork, but if there is still a sizable chunk of the original code remaining you could team up with @woutdp and extract the core as a new library, LiveSPA, which is just an integration tool for JS frontends. Then in the docs you can have an Integrating with Svelte, Integrating with Vue, Integrating with … and drop the LiveFramework names altogether. I’m unsure if it’s possible but having one place in the docs to go to learn how to add any framework would be great as the docs are very scattered as is.
Elixir is pretty dynamic. You could have the real core in LiveSPA. The Vue specific changes you’ve made in LiveSPA.Vue and the Svelte specific config in LiveSPA.Svelte
2
woutdp
I’d like to have a single interface for these kinds of libraries, but we’d have to make sure it’s the correct abstraction. LiveVue does some things different from LiveSvelte, for example it uses Vite instead of Esbuild. So the setup wouldn’t be the same.
I’m more in favor of manually converging the libraries. LiveSvelte can learn from LiveVue. For example, maybe it would be an idea of having both an Esbuild (which I picked since it’s closer to the documentation Elixir and the default setup you get with a Phoenix project) and a Vite setup which is a bit more modern as a build tool in the frontend world.
What I’m trying to say is that even though the libraries are a solution to the same problem, their implementation (and future other potential frameworks) might have completely different ways of solving things. Currently I don’t see how a shared library might make things easier for users and for maintainers. But a manual convergence of the libraries does make sense, and if enough frameworks get implemented and we see certain patterns that are always the same, then it might make sense to do it at that point.
2
sodapopcan
KP123
Perhaps the Meteor community could provide some guidance. They’ve had multi-framework integration for almost a decade
1