We've built many production apps using LiveView. It has some limitations inherent to its design, namely the need to have a semi-reliable WebSocket connection to be able to effectively use the app, but with this tradeoff come a number of advantages:
- code generation makes for an extremely productive experience that makes standing up an actually-useful application very fast
- Elixir is a great language, especially for the web, and using it to render the frontend feels like having the full power of the language plus the simplicity of HTML (with little/no writing JavaScript)
- it's extremely efficient since only tiny changes are sent over the WebSocket when data is updated on the server
- you're already using WebSockets, so adding any kind of real-time functionality is very easy (chat, notifications, game state)
Because of the separation of concerns by convention (i.e. keeping business logic in Contexts), it's also a very viable pathway to build a webapp using LiveView first, and serve an API once you need other types of clients (native apps, API consumers) with minimal changes. Ecto is also great to use for validations, and having that available for "frontend" code is a pleasure. It's also great to be able to have backend and frontend tests in Elixir.
We've hit some bugs and gotchas over the years leading up to this 1.0 release, but it has long felt like a stable, well-built library that keeps our codebases simple and maintainable, which lets you move fast.
Congratulations to Chris, Jose, and all the other wonderful contributors!
Thanks! Love to hear it! Note that LiveView also fully works on the LongPoll transport (which is enabled by default), and we have automatic fallback to longpoll support if websocket fails for whatever reason. So even in the case of obscure websocket issues (like some "corporate proxies" doing weird things like allowing the 101 websocket upgrade then just dropping things into the ether), things should be good. In my experience 1-2% of traffic seems to have websocket issues today for the production apps I work on.
To your point though, LiveView indeed requires a semi reliable connection for reasonable UX, but there is a ton of nuance to this topic that is usually missed from the discussions. Apps should more or less degrade similarly to SPA's that are going to the server. For robust UX on unreliable connections you need offline/local-first SPAs, and in my experience the vast majority of SPAs do not handle this. Failing that, most SPA frameworks seem to place the optimistic UI/rollback concerns on the developer. In fact most degrade quite poorly on bad connections. It goes against folks intuition, but even with degraded connections LiveView does better than people imagine because we have the existing connection established and don't need to go through the overheard of reestablishing things, and our payloads are generally smaller.
Need is such a strong word. I use LV mainly over long polling at the moment, only drawback is the whining about the client being unable to establish a WebSocket connection in the JS console.
We've hit some bugs and gotchas over the years leading up to this 1.0 release, but it has long felt like a stable, well-built library that keeps our codebases simple and maintainable, which lets you move fast.
Congratulations to Chris, Jose, and all the other wonderful contributors!