How Phoenix LiveView Works | Hacker News Reader

How Phoenix LiveView Works

poeticoding.com

I really enjoy working with Phoenix and Elixir in general, but LiveView never clicked for me. I decided to give it a try on a relatively small project, and while it blew me away that it was easy and fast to build things, I find that the code I ended up writing is so messy and tangled that I don't really have the motivation to touch it anymore.

This isn't necessarily an issue with LiveView in particular, but it's the only experience I've had with it.

no you're right, it takes an incredible amount of discipline to make pure LiveView code organized. I suspect Part of it is due to the "GenServers are dog's breakfast" problem that Dave Thomas complained about. I've settled on some patterns myself (https://www.youtube.com/watch?v=HA4h0cajgaA), but I'm still not 100% on them. I wonder if frameworks like Surface ameliorate this problem.

Dave Thomas' post and talk about this. He 1) criticizes the overuse of GenServers, 2) the boilerplate code and large directory structures created by tools like mix and 3) gives a few ideas to deal with these issues. Amazing talk.

https://pragdave.me/blog/2018/06/02/project-structure.html

Here is the talk, queued up: https://www.youtube.com/watch?v=6U7cLUygMeI&t=730s

Yeah, I don't agree with everything he says -- I don't think boilerplate is necessarily bad. Especially in Elixir where It's hard to explain but usually it's easy to find the meat of what you care about -- your eye (or search cursor) just lands on it. And I also think specifically the solutions he proposes are not that great. Having a common language and not inventing too many more DSLs has value, even if it sucks a bit. But a lot of that shit needed to be brought up.

Maybe I'm missing something here (tell me), but after being initially amazed by the architectural concepts, I tried demos of a similar tool (https://docs.stimulusreflex.com/) and was eventually disappointed by the result. Why? Because the resulting UX is not comparable with a SPA at all.

With a SPA, you instantly get a visual response when you click something (even if this response is a spinner) while with this kind of tool, there is a small bu weird delay (because of websockets) that makes the whole experience laggy, and pretty weird to me, especially after being used to SPAs.

I totally understand that the balance between the tasks to achieve and the end result is very good, but this techno does not look like a replacement of SPAs to me.

I tried the demos (e.g. https://expo.stimulusreflex.com/demos/todo), and indeed they feel laggy.

On the other hand, I think it is a failure of the UI, but not of the whole LiveView concept. UI elements could get an automatic visual indication of being "in progress" on the client side after being clicked, and I believe the feeling of lagginess should go away.

While I agree with that, I do not understand why this is quite so laggy. As we have different people here try and they all say it's laggy, irrespective of location (we are probably not all sitting in Portugal) and internet quality (maybe we all have slow internet though), there seems to be something wrong. But yes, add a spinner to indicate server communication and suddenly it'll look quite normal. SPA's that don't do that, with my connection, I often see the item appear but then get a server communication timeout after that which is, well, equal or worse to this.

It's a demo server? Go try Hey.com. Their email approach doesn't work for me, but the native app uses stimulus and it feels (felt? it's been a year) snappy.

Hey uses Hotwire (which Stimulus is a part of) they do not use Stimulus Reflex.

1) The only issue here is network latency, and if you're not crossing half of the world it is not that high (elixir/liveview itself does not take much time - like single digit milliseconds, maybe less)

2) it's possible to combine both approaches, using bits of javascript to fill in client-only animations etc.

We heavily debated going with StimulusReflex instead of LiveView because of the team’s existing familiarity with Rails. In our experience StimulusReflex doesn’t work because Rails isn’t fast enough. Phoenix is.

You're probably right. I'd like to see a demo of a something like https://todomvc.com/ made with it, and compare the feeling between a SPA and LiveView.

Normal HTTP request latency is much better in Phoenix that in Rails. You can't do much about the intervening network latency but I'd expect a LiveView app to be snappier.

Good practice seems to be the PETAL stack (https://thinkingelixir.com/petal-stack-in-elixir/) using Alpine.js to sprinkling in some client side UI stuff that doesn't need to go via the server.

LiveView isn't intended to replace SPAs. If you have a lot of UI interaction where the UI changes "shape" in response to user interaction then no you probably want JS. For a lot of things people are doing they don't need that though.

Implementing a form in LiveView is a use case that completely shines. You implement all your validation once on the server and use that same validation code (the ecto changeset stuff) to do your live UI messages in the client. It also doesn't matter if it takes 100ms for the text box to go red and say "password too short" in that use case. You can get a 'live' friendly and helpful interactive form with all the user feedback you want and it costs you barely more than the effort to do just the server side stuff, and without any risk of mismatching validation.

Phoenix creator here. Stimulus Reflex and most LiveView-like solutions do not perform diffing that LiveView does, so you are receiving the entire page/template for every change which adds to the overhead. You are correct that purely client-side interactions should be instant, and we promote keeping purely client-side interactions client-side. For any interaction that must otherwise make a trip to the server – saving a form, posting a message, fetching new results, etc, an SPA will not be any better. In fact, it will usually be slower because LiveView payloads are going to be better optimized than the best hand written JSON you could write for your SPA client/server contract. Likewise, we use the established websocket connection so there is no HTTP handshake, header parsing, authentication, etc for every interaction so LiveView can provide a better UX when round-trips are involved than SPAs. For client-side interactions, we have a number of UI features built-in that provide user feedback while awaiting an acknowledgment and tools like Alpine.js are fantastic when you have purely client-side interactions to perform like opening navs and controlled input formatting.

I wrote about UX considerations with LiveView here that addresses these points: https://dockyard.com/blog/2020/12/21/optimizing-user-experie...

Thanks for the explanations. This makes perfect sense that having an open WebSocket connection drastically speed up the exchanges between client and server.

However, I guess there is still a UX difference with SPAs when you go to a new page. Going to another page with a SPA is instantaneous, and user just waits for server-side data to be loaded, with data with spinners in between. But with Liveview, the client would need to wait for the server to render the whole new page, before displaying anything new (exactly like a standard MVC framework). And this specific behaviour can create a "laggy feeling" IMO. This will never be as fast as a SPA in this case. I think this can be disturbing, especially for websites used as mobile apps. In that case, users expect navigating between app pages without waiting at all, even if they are used to to wait for specific data to be loaded in that same page.

Please correct me if I'm wrong, but to me, it seems Liveview is perfectly suited for intensive data exchange on an open page (for example, the bitcoin example used in this video seems perfect), but not suited for apps with an intensive navigation between different pages, because that pages will require a round trip to the server to be rendered.

Still, I'm jealous there is no Liveview equivalent in Python, so that I would stop requiring the whole SPA toolchain as soon as I need some updates in my project.

Great explanation. LiveView is such a life changer for building fast and interactive interfaces without having to build a separate client-side application.

The previous episode is worth checking out at https://www.poeticoding.com/first-contact-with-phoenix-livev...

The site is rich with resources on Elixir & Phoenix & LiveView. If you want an introduction to LiveView, I would say this is a very good starting point.

Thanks. I wanted to get into Phoenix, I'll go back a bit in the playlist.

This is excellent, thank you for writing this. I’ve wanted to play with LiveView but haven’t had the time. But wanted to know exactly what’s happening (especially on “first paint”, others have written about the morphdom stuff)

I really don’t see any reason why we can’t embed LiveView widgets into existing SPAs as a method of transition. Looking at this lifecycle it seems entirely possible. Also it would make an amazing framework for embedding widgets on third party sites.

I know people say it has to be served from a fully rendered Phoenix page but I don’t see that limitation in any of the code.

Excited to play around with it.

To clarify, I'm just the poster, not the author :-)

I happen to have a very good time using LiveView in a number of scenarios, and found the article good enough to be shared.

I’ve tried .Net Blazor, Stimulus Reflex and Phoenix Livewire. Blazor is by far the closest as it allows you to run Native client-side code and server-side code.

The conceptual model didn’t work for me. Using client-side frameworks with json over the wire is a simple model. Ideally the server decides where things are rendered.

These are important tech innovations, however the missing piece is still WASM. Being able to write the full-stack in one language. A step further WASM enables is interoperability between languages. Being able to call a Python ML lib client-side from your JS/Ruby/C# would be a game changer.

Sadly, WASM for ruby and Python is not quite there yet.

Phoenix is great and Liveview looks great.

How is it different from reactive web views? Link below

https://youtu.be/ewpJ9EUAz5s

Is there any concerns to how LiveView will scale compared to just using “vanilla” Elixir/Phoenix?

It will scale just as well as any other stateful application built with Phoenix, such as one using Phoenix Channels, which we've shown can scale to millions of simultaneous connections. LiveView allows you to mark which data you want to hold in memory, and which are only required for rendering and can be discarded for only storing what you need. That said, memory is going to be higher than a non-stateful application, with all the usual caveats of more HTTP overhead, server interaction overhead, DB pressure, and such so the increase in memory comes as savings in other areas.

tldr; since we are built on top of the Phoenix channel primitive, it will have the same scaling characteristics.

https://www.phoenixframework.org/blog/the-road-to-2-million-...

Reply on news.ycombinator.com