I’m sure @chrismccord is taking some time for a good reason. I’m as impatient as you (I would love to stop using JS in many use cases), but If there will be many changes to the API, people will start hating LiveView for the wrong reasons.
matreyes
snake117
I agree with this. I would rather @chrismccord take his time and release a solid prototype that has strong potential over something that is either broken or comes across as a toy and won’t be taken seriously. This could very well be a huge selling point for Elixir/Phoenix (hopefully not too far down the road).
chrismccord
Creator of Phoenix
typesend
onelesd
Exadra37
Maybe @chrismccord will suprise us in this conference https://lonestarelixir.com/2019 with an announcement of liveview???
mindok
sandergroen
joerichsen
AstonJ
Some more info from @jackmarchant’s blog post 
Phoenix LiveView
Although it had already been announced (but not released yet), Phoenix LiveView was presented to the audience at Lonestar ElixirConf with a promise from Chris McCord to be released as early as the end of the month but at least in the coming months.
Chris spoke about the motivations for building LiveView and stressed the goal of delaying the inevitable single page application path for as long as possible. How long that is will be determined after release when people have had time to use it.
I am personally quite optimistic about it and although I’m happy to keep writing JavaScript on the frontend whenever I need to, it will make building prototype apps to showcase Elixir’s real-time capabilities much easier.
The conceptual programming model for LiveView is very similar to that of React and other JavaScript libraries, in that each component has a parent-child relationship, with the default behaviour that if a child component fails, it can be restarted back to its last known state. It is in this way they behave like children in a supervision tree. The similarities between frontend view libraries like React and Elixir/Erlang supervision Trees is a topic I have written about before.
10