Apr 25, 2020
2 mins read
LiveView is server centric. You no longer have to worry about managing both client and server to keep things in sync. LiveView automatically updates the client as changes happen on the server.
A refreshing approach to web development with rich, real-time server-rendered HTML. The demo is impressive. The Elixir code is pleasant to read and easy to understand (React Admin, I’m looking at you). The framework maintains an open socket, which may seem like a bad idea, although I wouldn’t bet against it, as it manages to reduces the request payloads compared to GraphQl or your run-off-the-mill web REST-ish API. It may be an issue with weaker network connections. At least today.
In the last two decades, we’ve witnessed the downfall of fat clients, followed by a switch towards server side rendering of feature-poor static HTML (and a severe loss of productivity as I recall), handcrafted AJAX requests, much improved by jQuery for better or worse, leading to the current state of affairs, where backend and frontend development are two separated things. It is what it is and it is what we have, it’s nice, but is it an efficient software development paradigm? I doubt it very much.
We have seen our share of cool "building a clone of Twitter in 15 minutes" demos, and they always beg the questions: 1. how does the framework/lib/language perform beyond a toy application, with complex business logic, access rights, multi-tenancy, composite views, and sometimes running under a fair load of user requests? 2. Will the techology stick and be supported 1 year from now?
It is hard to answer before the stack in question has been battle-tested. I wouldn’t build a business critical system based on anything too new and shiny, but why not a small side application? Worse case scenario, since LiveView does not seem to require a steep learning curve, you are unlikely to loose that much of your time.
Discovered via @melvynhills