Chris McCord
7 HN recommenders · recommended in 10 months, 2020–2025
17:55 · 237K views · Apr 22, 2020
Phoenix creator Chris McCord builds a real-time Twitter-style app live with Phoenix LiveView 1.5 in about 15 minutes. It shows interactive, real-time updates without writing JavaScript.
HN points people to it as the demo that shows why LiveView and Elixir are worth a look.
13 comments from Hacker News
> But I'm wondering if it brings enough other advantages that I shouldn't view it that simplistically. So to start with, Phoenix LiveView really is a game changer, you should have a look at Elixir just for that. This is the talk which really bluffed me when I first saw it: this video . For the other upsides, I like a little bit better the way everything is architectured in Phoenix, there's much less magic and it's easier to follow the data flow and what is going on.
My favorite talk is the Live View twitter demo on my case: this video . Never before I've been so bluffed by a new technology, he's building a small twitter clone in 20min with live reload, browser sync and everything, this would take days with any other traditional tech I know.
I think the "talk" by Chris McCord should apply here "Build a real-time Twitter clone in 15 minutes with LiveView and Phoenix 1.5", while not really a talk this year was special and the demo completely blew my mind. it's available here: this video
Liveview solves the "write a fully dynamic and interactive application with next to zero Javascript that you need to write by hand" or, if you will, "server-driven UI apps". And it's hard to overstate, but to also properly explain, how important this is and how it feels like magic when you do it. Because it lets you tap into everything Elixr (and Erlang VM) have to offer on the backend without ever having to think of "how the hell do I bring all that to the client". My use-cases are: a big chunk of data is being processed, and while its being processed regular updates are sent over PubSub. Most actions a user initiates are long-ish-running and their updates are also sent over PubSub. Things that other users are doing are sent over PubSub and possibly need to be reflected in the UI. In "traditional" JS-on-the-client-whatever-on-the-server model you have a plethora of questions of how to get that to UI: which endpoints to query, which updates to send over the wire, the formats, the frequence, authorisation, auth... With LiveView your "client" is an Elixir view living on the server which just updates the view based on those PubSubs (or timers, or Kafka streams, or user-initiated actions, or...) and LiveView takes care of upating the DOM/HTML in the browser. "Build a real-time Twitter clone in 15 minutes with LiveView and Phoenix 1.5" will give a good overview of this: this video [1] Built-in in Phoenix, [LINK]
Even with tooling getting better, you're still faced with creating an API to the backend that has a high chance of your frontend being the only ever consumer of it. You're also faced with duplicating logic on both front and backends in many scenarios (though of course this can be mitigated with a node backend? I don't know... I've never used node). As for latency, this is over websockets. It becomes a problem if you are connecting to a server across the ocean but otherwise, it's incredibly fast and feels just as snappy as JS. I actually also haven't used Stimulus Reflex, just Phoenix LiveView so I'm not sure if they are exactly the same, but the TL;DR is that they are sending VERY tiny payloads over websockets. This video explains it well (though it's also a demo of LiveView): this video