It led to a lot of confusion for me when I started working with Phoenix, so personally I think it’s worth fixing.
I guess it’s one of those things that might matter to some people but not others. As long as it matters to a decent percentage of the users I think it’s worth fixing.
Aha, yup…I misunderstood.
I actually considered that approach a few times - “should I make every page a LiveView page, even though only 10% of them needs to be?”. In the end that felt a bit wasteful (unnecessary ws connections etc), but perhaps thats still the best way to approach it? Thanks for sharing your approach, much appreciated.
I guess my many years with Python have made me internalize There should be one-- and preferably only one --obvious way to do it quite a bit, and that Phoenix could do better here. I feel like I’ve gone off topic though, and that and I am starting to hijack the thread with this discussion, so I’ll stop here.
My thought process is as follows:
I could also go on about the odd hangs up people have around sending “too much data” over websockets.
Buuuuut, I would love if the controller+view/LiveView could be unified. I’ve thought about this a lot but it’s not such a straightforward problem to solve (or perhaps I just have a skill issue 
). In LiveView we eschew the action attribute for a phx-submit. This, of course, won’t work with the plain old web. Contrast this to Rails’ Hotwire that has an actually PWA story—you can just make a straight up 90s style web app and then enhance it with Hotwire. This is great! …except that essentially all modern apps don’t cater to people with JS disabled and Hotwire’s programming model isn’t nearly as simple as LiveView’s.
Oh! Perhaps you could let me know if I should be using pip or pip3 or anaconda or conda or virtualenv or pyenv or mycobracondaenvpy2.3 what? 
You are right, there are more important things. But this one I encountered one time too many times and I know others have too.
And practicing debate and community driven decision is best done with something small. Like unofficial wording. Next up: ‘let’ in ‘for comprehensions’
Love to see the contributions over the weekend (l)
Haha, touche! The Python ecosystem is indeed a hot mess when it comes to certain things, escpecially around tooling.
The language itself is far better though imo. However, that’s most likely just me being completely blind to all inconsistencies and idiosyncrasies because I’ve been using it for so long 
That’s an awesome explanation of your thought process when deciding, thanks a bunch!
I should probably be less wary of choosing LiveView, because like you said, in most cases it doesn’t really matter if I cause an extra “unneccessary” WS connection.
I have to admit though - 9 times out of 10 I run the same code path in mount/3 regardless if the socket is connected?/1 or not…so just as an approximation I tend to think that “1 requests has the cost of 2” (double db queries etc). I know i could implement a “skeleton state” on the initial render, but I’m just too lazy to do that!
The proposal you linked to looks super interesting! Having something like that (cancellable live views) would really improve LV imo.
I’ll probably stick to OneShotViews for high traffic, 100% static pages like high traffic landing pages, but go LiveView on most everything else. I’ve probably been trying to avoid LV a bit too much for my own good. Thanks for making me realise that!
And re Python, you should obviously just use “uv”! Don’t ask me again in six months time though, because my answer will likely have changed by then
Just call it a View. If you want to emphasise it’s not a LiveView, then plain old View (POV) as is sometime used with plain old java object (POJO) plain old ruby object (PORO)
