LiveView's readiness

I don’t have direct answer, but in my experience, tons of packages in elixir world are in 0.x versions and stay there often “forever”. Because they simply work and there’s no need for major change anymore. I had the same perceptions as you, but it seems to be just different way of looking at things here.

I think that’s simply the lack of motivation to commit to a long-term stable API once most of the initial bug reports and feature additions are completed.

Hello,
I’m already using it in production for a small trello application. I would say that, after your tests, if you think it would fit your needs, just go ahead and use it
The api has already had some time to get matured and if it changes, just adapt. Would be the same anyway going from a V1 to a V2 of some other libraries…

I am developing an MVP with Live View, but before I full commit to use it for production I will be doing some real world testing.

So before you go ahead try to use your app in commute journeys and see how it behaves in the real world with real world bad connectivity.

Also bear in mind that your users may not have devices so performant like yours, therefore if you have old devices use them instead for your real word test.

Also, be aware of the Socket issues in the real world. Sockets don’t work everywhere, like in corporate proxies/firewalls. Also it seems to have issues with fallback to longpoll hover http, thus rendering your app useless for your users if they fall in this issues.

To be clear, I think these issues are temporary, I don’t think there is anything about it that is intrinsically tied to websockets. I just think there is a bug in the retry logic that isn’t respecting attempts to disconnect from the websocket and reconnect via long polling.

Temporary for your use case, not for the use case in the post I linked, where it never worked out, because it was dealing with corporate environments, that normally make use of Firewall and Proxy’s, just like where I work.

Just to be clear the corporate world is a different world from what the majority the developers are used to work in, including the core developers of many of the tools we use day to day, thus it’s perfectly understandably that this tools lack the mechanisms to deal with this very tight secure environments.

Back to the socket issues, even if temporary, the app will be unusable during that time, and that can be enough to put a new user off of your app or to make current users to look for alternatives.

So in the end of the day what matters its users retention, because without users an app is dead

I’m referring to the issues where socket.disconnect() doesn’t work. That is clearly a bug, which means it’s clearly temporary. Websockets being blocked in corporate environments is a reality we have to deal with for sure though.

Thanks for the clarification. So yes I agree that’s indeed a bug.

That’s a pretty good point, yeah. I’m just a little bit confused about live view, because I hear many people saying that they run it in production, and others who warn about putting it in production.

For me. Just because something is run in production doesn’t mean it is production ready. There are trade-offs you need to consider adopting something early on.

You should be prepared that there will be bugs and when those bugs are fixed the new version likely comes with breaking changes to the API, meaning more work to get running. You may also have to prepare yourself that the project goes nowhere and is abandoned (not saying this is likely to happen with liveview, just more a general reflection) and you have to either take up stewardship yourself or change technology.

Production ready for me means good documentation, stable APIs, some sort of guarantee of longevity (which sort of ties into the stable APIs) and clear upgrade paths from earlier versions.

LiveView can be run in production but in my opinion is not production ready yet