[dns_snek]

Could you elaborate? I don't see many similarities between those and LiveView.

The difference between traditional technologies that render HTML server-side and LiveView, is a persistent connection to the server which allows it to re-render templates in response to server-side events and patch client-side HTML without writing any Javascript.

[pjmlp]

Mostly based on WebSockets and Server Push.

As one example of such approaches, .NET has SignalR since 2013.

And WebForms could use designer tooling since 2001, and then there was ASP.NET AJAX Control Toolkit.

[dns_snek]

Not quite, I'd say that SignalR is comparable to Phoenix Channels. It's a communication protocol that can use different transport protocols, Websockets being one of them.

LiveView builds on top of Phoenix Sockets. When the page is loaded for the first time, it starts a lightweight server-side process on the BEAM VM. This long-lived process renders the HTML template (which can consist of multiple SPA-style components) and keeps all of the relevant "props" (called assigns) in-memory.

Every time a new event is received, either client-side (e.g. button click) or server-side (typically via a PubSub subscription), that long-running process will update its assigns (props) to reflect the new state. The framework then intelligently re-renders parts of the HTML template which depend on those modified assigns, and sends a minimal HTML diff to the client.

All of this can be done without writing any custom JS. Basic client-side events are usually set up with special HTML attributes like `phx-click=my_custom_event` and automatically wired up by LiveView JS bundle to be received by that long-running process.

[pdimitar]

But it doesn't have the BEAM VM. The runtime matters a lot, and LiveView wouldn't work as well if it wasn't running under the BEAM.

[jddj]

This isn't particularly convincing, as the pattern -- loosely: keep a websocket open and keep the formerly clientside app state serverside while passing events and pushing diffs -- seems to appear successfully outside of the BEAM vm. For example, blazor serverside (.net) and laravel livewire (php).

I haven't checked but I'm sure there will be a python one too

[pdimitar]

You are not convinced because you don't know the details. But I am not paid to advocate or to even try to convince. You've been informed now -- from here on it's on you as to whether to remain biased or to expand your horizons.

[jddj]

I've written elixir apps, also read Armstrong's thesis, etc etc. Beam is undoubtedly an excellent piece of engineering.

I don't want to engage more than that, as the horizons comment seems bizarre in the context of the thread

[pdimitar]

No need to get defensive. Your comment came across as curmudgeon-y and biased, I called you out for it, you could have agreed to disagree which I would respect. But no, you had to go out of your way to try and strike.

Well, OK. But HN is not the place for that and I refuse to engage further.

[pjmlp]

Tomato, Tomato, it has another VM.

[pdimitar]

It's your right to delude yourself that the runtime does not matter. That's not a discussion I am willing to have though, especially when exactly 100% of my 22+ years of programming experience have demonstrated, time and again, that the runtime inevitably ends up making a lot of difference (sometimes all the difference even).

Or, when you don't have a runtime -- as is the case with Rust, kinda sorta I mean because technically `tokio` can be classified as a runtime -- then you rely on a stricter compiler.

Both strategies work pretty well.

I am not shitting on C# / .NET, they are solid as hell. But some things the BEAM VM just does better and everyone who worked with old-school VMs (in my case the JVM) and the BEAM VM can tell you that.

But again, you do you, think what you will. ¯\_(ツ)_/¯

[OJFord]

This saying really doesn't work in writing, I just read ..err.. 'tomato, tomato'