This is, in my professional opinion, where web development has derailed over the last decade (in general).
All of that sounds good, in theory.
In reality, you still have to transfer all of the data to the client so that it can work on it. The act of taking data and converting into to JSON so that it can be transferred up, loaded into the client and them moved around is actually less efficient than just transferring up what you need after trimming it down on the server (or better yet, in the database). The amount of work in generating HTML isn’t all that different from the amount of work in generating JSON.
The idea that transferring things up to be processed in the client is only viable when a lot of data has to be constantly reprocessed in the client, such as animations or live streaming data into a dashboard that will be updating and recalculating for display on multiple parts of the page.
For the case where you’re periodically updating one centrally viewed segment of the page, there is almost no benefit to the fat client approach. It’s overhead cruft with marginal benefit and usually involves the need for at least an additional hire. This is where LiveView / Drab fits. It allows to leave all of that on the server where it has to exist, because no matter what it has to exist there or you create a security issue, and provide a slightly more polished experience than raw HTML/CSS in the browser would give to a user. You still get to take full advantage of the power in your database and you send up the bare minimum of what you need. You gain a ton back in recovered network overhead. For all of those sites that are “open, do something, check something, close”…that is tremendously more efficient and a better overall experience for the end user.
For the other cases mentioned, the offline case, the electron case or the react native case…by all means use the frontend framework. There are a lot of other people, myself included, who are absolutely craving exactly what LiveView/Drab delivers…because so much of the other stuff is totally unnecessary for probably over 90% of the places where it’s used.
The other aspect of this setup that makes it so much cleaner is Elixir and Phoenix itself. With Rails or other frameworks you’d have an if statement in the controller checking to see if the request was made with AJAX or not and if it was, you’d handle it and send back JSON but if it wasn’t you’d handle it and either re-render the form with errors or you’d redirect with a flash message.
By doing this with channels, you completely separate the interaction experience so that the interactive aspects are isolated from channels and the non-interactive exist in the controller. It also fits perfectly with the “Phoenix is not your application” approach by encouraging business logic to be accessible from both locations rather than contained in either.
I can’t wait. I have every intention of diving into this code the day that @chrismccord releases it, even though it’s not for everybody or every use case.
