It is a lot of interests in this field, based on my discussions with my friends since XX century 
I’ve been exploring this field for ages, first I’ve found promising was Nagare, then Volt. Then I tried to build the similar thing myself the on top of Rails, but what scared me, was concurrency and threads in Ruby. Phoenix+Channels was an answer to such issues, and this is how Drab begun.
I remember Volt! And Opal! And Ruby Fire! And all the excitement they generated! 
The interest in Volt waned after Phoenix was announced/started to gain traction - I know for me that’s when I lost interest in it anyway.
Things could well have been very different in the Ruby world if DHH had dropped coffeescript for Opal and RubyMotion had been made OpenSource - but that’s a topic for another thread (or another forum) perhaps 
My understanding of LiveView is to emulate the Elm architecture where the browser is responsible for displaying the view (HTML/CSS) and sending events to the server. While the server mutates the state in response to these events, re-renders the view and pushes it to the browser to display. The simplicity comes from the fact that state is held and rendered by the server with the browser displaying the rendered view and emitting events.
I can see this approach will fit well for certain types of web applications that are somewhere between mostly static content with some dynamic content and full featured SPAs. I’m at least looking forward to trying it out to see how it works in reality and exactly where it might be be used.
While I can empathize with your points, we as developers can get overly involved with our own short term comfort (and “coolness”; Programmers know the benefit of everything and the tradeoffs of nothing.) - sometimes to the detriment of our users and our own long term interests.
which tells me that there is a lot of interest in this type of library.
Yes, but it’s direct association with Phoenix also muddies the waters more.
My assumption is the @grych had his own valid use case for Drab - because he knew the constraints he was working against. He was generous enough to share his efforts via open source with others in a similar position and further develop it as a mature package. It is there for those wanted it and who where willing to go to the additional effort to make it work for their circumstances.
LiveView being part of Phoenix may have quite a different effect.
Lets remember Brunch shall we? Has absolutely nothing to with Phoenix. It’s there just for asset management. Something to push neophytes in a more progressive direction to use modular JavaScript rather than drowning in a swamp of legacy-style jQuery code.
What happened? Brunch was constantly mistaken to be an integral part of Phoenix - despite constant assertations to the contrary.
LiveView is a legitimate extension to Phoenix but now it even becomes more involved on the client side beyond channels. Anyone in this topic knows it’s optional. But from the outside it could be easily judged as yet another weird way (i.e. non-mainstream) of doing web applications.
“We are a React shop; we’ve heard Phoenix does this LiveView thing for the client so it’s not really relevant to us.”
I will admit that there is a real hole when comes to basic web applications that were historically created with jQuery - something to go together with the EEx aspect of Phoenix - but I don’t think LiveView is the solution for that space (maybe there will be some minimal JS library from Matt Frisbie for Professional JavaScript for Web Developers, 4th Edition - but that seems too much to hope for).
@peerreynders I suspect you have some experience into how the pendulum shifts back and forth in this industry and might remember some dumb terminals and green screen apps in the past. Those kept all the state on the server and the server told the client what to display. Granted the dumb terminals were typically in a LAN or a private network managed by the company rather than the open internet, but the concept is similar. The real question to me in this case is how much the public internet changes those green screen approaches (now that it’s feasible to have stateful connections).
It’s not part of Phoenix, which I thought was pretty clear in the keynote. Granted, the fact that Chris is the one promoting it has an effect, but I expect it can remain distinct.
This is true, we are taking the react model (or elm architecture) and placing it on the server.
This is the exact model we take on LiveView.
So let me preface by saying, are client apps increasingly necessary as the clients become more powerful? Absolutely. That said, do the majority of applications require this complexity for the UX the developers are after? I don’t think so– unless folks are after the SPA usecaes I mentioned in my talk. With solutions like LiveView I think a lot of folks can avoid the complexity and still get the UX they want with way less effort, which I imagine is why this is an exciting way to writing applications for many of us.
I don’t know about the ignorance to HTML/CSS point, but I think in general a large part of the webbev community has reached prematurely for client frameworks for any kind of rich interaction. I think a lot of these frameworks like react are great to “sprinkle” in for rich features, but once react/ember/elm/et al is in place, then it becomes increasingly tempting to adopt your point of view, where the separation of client ↔ server is the True Model and the natural path of web development. The issue is we’ve been running this experiment for years now with client-side apps, and so far from what I see is the best folks served by this added complexities are consultancies who get to bill and maintain all thus churning complexity. Who here has had the privilege of upgrading or maintaining Angular 1 for example? So you absolutely can produce incredible client applications with the great available frameworks we have today, but the cost we’ve taken on to make it happen has been enormous and I think folks are more aware of this than ever. It makes sense for some apps, but I know a lot of folks who look back and certainly find it not worth it in retrospect.
I see where you’re coming from, but I view it differently. I’ll break it down in detail when I get some time.
If you aren’t targeting offline support, which the vast majority of us aren’t even if we are building SPA’s, then this is what we do already today. Wether we’re flinging JSON over or HTML it’s the same interaction on the wire. We can debate if patching the DOM from fragments on the server is a valid approach or not, but we’re all flinging bits over the network all the time. I built Phoenix to build real-time apps, so wether it’s phoenix.js with channels or LiveView, we’re pretty great at flinging those bits 