What concerns me is that this time around Amazon/Google/Microsoft are pushing (currently) the other way, increasing complexity on the client-side for integrating data from a variety of network sources while LiveView is going in the opposite direction (without being necessarily “disruptive”). The business case to push state to the client is compelling because they don’t have to pay for the client - they have to pay for the server Phoenix runs on. Again “holistically” there are many use cases where “Phoenix-on-the-server” is a more effective solution - but I’m not sure that it is that easy to make an a priori case for it.
My point is not to criticize your effort … I was just hoping that someone could clue me in on what the excitement is all about. We already have PWAs, SPAs, etc. besides “old school web pages”. We constantly talk about “JS framework fatigue” - what about “101-ways of doing a web application fatigue”? Yes, try new things but we can we truly let go of some of the other approaches if we adopt this one? I somehow doubt it.
but I think in general a large part of the webdev community has reached prematurely for client frameworks for any kind of rich interaction.
No doubt - but I think to a large part that was because of the perception that adopting some random JS framework would be the path to some kind of front end nirvana - HTML/CSS is tedious stuff, throwing a JS framework and Bootstrap at it doesn’t change that.
Whether we’re flinging JSON over or HTML it’s the same interaction on the wire.
Mmmm…
Not all interactions on the page that change the appearance of the page need to involve the server - however I imagine with server-based rendering everything needs to go through the server which is a lot more chatty and more prone to stuttering (the network connection is likely the weakest link) than an application implementing a protocol that prefers much coarser grained data interactions - an approach which I wouldn’t equate with targeting “offline support”.
Now LiveView wouldn’t be pushing as many packets as something like a live streaming game server - but still.
We can debate if patching the DOM from fragments on the server is a valid approach or not
Even if you supply a functional equivalent of an “X Server on the browser” - it will still be yet another way of implementing a web application - only this one is locked entirely to Phoenix ecosystem.
Reducing server cost by lets say 85% by being able to ditch most node.js express servers for Phoenix would be a much more straight forward argument for driving adoption.
Anyway, just my perspective …
