I recently made a similar move for most of the reasons you mentioned. I was previously working with nodejs and svelte over websockets.
I find the idea of LiveView really compelling and I think it’s impressive as a technology. Ultimately, I found that I wasn’t able to create the UX that I was looking for mainly around optimistic UI and navigating instantly. I made a proof of concept for optimistic UI but it felt clunky. If your apps are relatively simple and are shuttling data from forms to the backend then LiveView works nicely. Anything more akin to a true web app will require lots of work with JS hooks and JS commands to get a more interactive experience and avoid latency. As an aside, JS hooks need some DX love — I think the coming colocated hooks will help considerably here. So you’ll likely still be writing JS but without the conveniences you’re probably used to and you’ll also need to be aware of how they potentially interact with the state managed by the LiveView cycle.
In terms of productivity, there will be a learning curve. Some things will feel very familiar others quite foreign. But if you were writing mostly functional-style with js (not OOP) then a lot of things will click. If you like tailwind, then you’ll feel at home with css otherwise you’ll be fighting the defaults, though imo Phoenix should make tailwind opt-in rather than opt-out. To help accelerate UI components, I’d recommend checking out salad ui.
For now I’m pursuing Phoenix channels on the backend and SvelteKit SPA on the frontend. Though I think the addition of a few features in LiveView would make me reconsider in the future — namely, prefetching and a robust solution for true optimistic ui. I also have my eye on Hologram which I think could be an amazing DX without sacrificing UX but it’s not quite ready for prime time.
