I am not thinking about the whole scope of the problem at once. That’s why it seems like I am contradicting myself.
Also I am posting here because people smarter and more experienced than me can give opinions about this. Perhaps nudge Phoenix to have this as first class citizen.
And, when I meant no JS, I meant no LiveView JS. If you have other js and stuff you should be able to.
I pointed out two other frameworks to look at. QWIK and Svelte Kit and see how they do it for static page and what they consider as a static page.
See how QWIK has resumability built in. And how it just sends enuf JS for small interactions, while still be statically rendered on server.
Static generated site doesn’t mean we forgo JavaScript entirely.
P.S. I am just posting here for discussion and what others are doing and if they are running into the issue of having to write in two different ways or coming up with work around like @soups’s necromancy approach to reuse LiveView paradigm.
That was mostly me brain dumping to myself at 2am so I wouldn’t take much of that as very considered. The new 1.7 templating stuff was still mostly not visible at that time which discounts some of my distaste with writing “traditional” phx controller-action-view pairs.
I haven’t measured, maybe someone smarter can, but how much memory is really held by a as-good-as-dead-view? If you use temporary assigns for the few things, you’re probably not holding that much state in memory vs a regular session? More than nil for a deadview but probably not enough to have to worry unless your “at scale”, where you’re probably already ruthlessly optimised where it counts anyway.
Looking at a random mostly-static, totally “unoptimised” LV in the dashboard, it’s using ~6kb, call it 10kb, if that’s the actual resident pressure then its only ~100mb per 10k concurrents which is fine? I’d love to have to deal with that kind of “problem”. Perhaps that is a naive extrapolation.
I also think it should be part of LiveView.
LiveView with long list → "DeadView"→ Browser back navigation to LiveView
I think this scenario is common enough.
I would love this to be part of LiveView. Especially when reloading and have the page jump back to the top can be particularly frustrating for development. I sometimes also reload pages sometimes during regular browsing, although I’m not too sure why I do this…
If you don’t connect from the client side, the content will be rendered just once, like a dead view. I also have live views that disconnect themselves and become dead views. You can also have a disconnected liveview to reconnect, however, it will have the flicker and scroll to top effect that @cmo mentioned.
When I want to create a dead view using LiveView tooling, instead of
use MyAppWeb, :live_view
I would use
use MyAppWeb, :dead_view
This would be defined alongside the other helpers in MyAppWeb, and would be similar to the :live_view helper except that it would attach an on_mount callback that 1) set an assign indicating that this should never try to connect, and 2) {:halt, socket} if connected?(socket) is ever true.
Then in whichever layout links app.js, include some meta tag indicating that it should not connect if the assign from 1) above is present. Update the socket connection logic in app.js to check for the presence of this tag before connecting.
This seems very doable! It may be something I try out to see how it feels in practice.
Guests (any visitor who isn’t a logged-in user) are served a separate JS file which doesn’t include the live socket, meaning that even live views are served as dead views to them (this is to save server resources), with some polyfills to handle Hooks and phx-click.
Some pages (mostly forms) that are only useful to guests are built as controllers which use live_render/2 to load the UI which is still built as LiveViews and Components.
Hello, just landed on this page because I was searching for topics like “any reason to not start with liveview” and “replace all deadviews with liveview”.
I just want to express the thought process, I recently learned about LV, great! love it!.
I learned about deadviews first though, which was also great and allowed me to learn all of the HEEX stuff without worrying about LV.
It’s true I don’t need sockets on every page, but on some pages I do, and on some pages I might in the future. Given that I can put static content in a LV but I can’t put live content in a deadview, I have to wonder… is it ok to do everything in a LV?
I also do not want to deal with the decision of “is this a LV or no?” every time I make a new page, nor do I want to go “oh this Deadview now needs a LV interaction, I need to port the entire controller!”, I want to pick one and stick with it, so I am going to pick LV for everything from now on and see how that turns out.
Thanks for the post and replies, I know I am not alone
