Hacker News Reader

Comment by dmitriid | Hacker News Reader

There’s a big caveat: all state is on server which will bite you (in terms of RAM) if you’re not careful.

A small thread including my own experience here: https://twitter.com/dmitriid/status/1153586545426862080 It’s fairly obvious, but is worth mentioning.

View on HN

Check out our "temporary assign" documentation – you only hold on to the state you need. That said, you are right that a LV application will necessarily use more memory than a stateless JSON API, but there is more nuance to the story. A LiveView application will use less resources under application operation than a single page app, for example:

- because LiveViews are stateful, we don't have to refetch/reload the state we need on every "request". Things like current_user, current organization, preferences, etc. So what we lose in memory load, we gain in reduced DB and system load, caching strategies, etc

- because LiveViews are stateful with change-tracking, we actually can send less data than the best hand-written SPA/JSON application you could write. So what we lose in memory load, we gain in reduced latency and overall data on the wire.

Direct link to data-on-the-wire example from my keynote for those curious: https://youtu.be/txk4WAlabvI?t=873

Not only that, but a lot of the state is essentially the same for many/all users/connections and can be shared.

Let's say in a chat app with a Redux setup I'd maintain channel users, messages, own profile details etc. in the app's own local state. With LiveView I'd only need to store the user specific stuff in this user's own state. Some of which I'd store in the socket.assigns of Phoenix Channels subscriptions even now with a conventional Redux setup.

Reply on news.ycombinator.com