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.
