Sometimes you focus really hard on a problem, you spend all your mental juices and then you need a break, a recharge. Something light, trivial, but close to heart. Something like naming conventions. So you jump into an active discussion in the community about such trivialities. A worthy distraction I would say; it beats tik tok in any case. 
5 Likes
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.
2 Likes
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.
1 Like
My thought process is as follows:
- Do I care if my users have JS disabled? If so, LiveView is out, but I’m probably just making a fun 90s era static page, so whatever.
- Does this page need to manipulate the (http) session? If so, LiveView is out (although apparently there is work being done to work around this! It’s been linked on this forum but I’m having trouble finding the link)
- Does this page need make requests that can change its state? Is so, then LiveView is in! At this point the only reason it would be out are because of reasons that would have made me not choose LiveView as a viable solution in the first place, eg, client-side JS is key, I have users all over the globe but can’t afford to distribute my app (although… if you have global users and can’t afford that you have bigger problems)
- Is the page completely static? If so, LiveView is probably still in! Why? Because as @derek-zhou mentioned, consistency is king. Also, are open WS connections really that wasteful? Technically sure, a bit, but that’s so micro-optimization-y. No React developer has ever considered that they’re forcing some poor schmuck to use up their battery downloading MBs of JS just to click “back” immediately. Is it really that bad if someone has a WS connection open for the 11 seconds they are skimming your About page? But also, this proposal is gaining some traction!
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? 
3 Likes
You missed the memo on uv? It is not even written in python but in rust.
Joke aside, I never really picked up Python precisely because I disagree with that motto. There should be only one way to do it, after I eliminated all the other ways myself.
I should mention these quotes from Dr Dlacc 
5 Likes
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
1 Like
PlainView
LiveView
… Maybe?
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)
9 Likes
While I do agree with the fact that DeadView might not be the best term to be used in conversations I don’t really agree with the notion that Views and LiveView are terms at the same level of abstraction (as in: both being cats).
LiveViews are not a subset or category of views, where the other half would be called [Something]View – and somehow wouldn’t fit the live prefix.
Rather LiveViews – as a alternative to controllers – make views live by wrapping a live’ying shell around an underlying view. Both controllers and LiveViews use views as a component to their working. With the introduction of heex that became even more apparent as the implementation detail of needing to support change tracking got baked into the default way of building html views on phoenix.
Imo to the decrement of clear separation LV happened to also really early on start embedding the view layer of phoenix into LV modules to enable co-located templates. At the time it made sense given LV needed it’s own separate templates anyways (see change tracking), but it muddied the fact that views are still a separate layer and LiveView not really being a type of view.
This can still be made explicit though by doing the following in a LiveView to mimic how controllers would commonly reference the views they use.
@impl Phoenix.LiveView
def render(assigns), do: MyAppWeb.BlogHTML.index(assigns)
Change tracking is also the reason for Phoenix.Component (see no namespacing to liveview) being developed within the phoenix_live_view library. Without that implementation detail it, together with heex, would likely have been part of phoenix_html, given they’re related to building html views no matter if used by a controller or liveview in the end.
So TLDR: LiveViews are not called views for being a subset of views, but because it being a technology to make views live updating.
3 Likes
I think you’re very close to pin-pointing the core issue here that LiveViews are not part of the same MVC infrastructure and stack as the regular views.
It gets even more complicated as LiveViews can be rendered inside traditional Views, and both can render Phoenix Components internally.
This means there are multiple ways of doing things depending on which route you choose: with Phoenix controllers or LiveViews.
I understand why is that but from the simplicity standpoint it would be less confusing also in the language aspect if we had one way of doing things.
Maybe it’s time to abandon the MVC paradigm and/or integrate Phoenix Controller functionality with Phoenix LiveView functionality into one solution.
2 Likes
Just like you can iframe another controller rendering another view. Maybe I never grasped “traditional MVC” enough, but to me a view layer is about translating data to a response format like HTML. That’s no different between LiveView or a controller.
Very interesting point - I never thought about it that way…but if I do, things start making a lot more sense! I think you really nailed it with:
LiveViews are not called views for being a subset of views, but because it being a technology to make views live updating.
I scoured Elixiforum and Reddit to see what people were already calling it and this is some of what I found (names for non-live views):
- Controller + Template
- Stateless View
- Client/Server
- DeadView
- View
The one that resonates the most with me of those is Stateless View. Reason being that it ties in nicely with the (well known?) fact that “HTTP is a stateless protocol”, so it kinda sets the expectation that this thing has a simple request/response cycle without any fancy icing on top.
I think the naming matters less the more accustomed you become to the ecosystem. I’ve been doing Phoenix for about 2-3 years now, so it doesn’t bother me any more. However, I do remember having big issues knowing what to google when I tried to figure out the difference between the two options, simply because people used all sorts of different terms for the non-live views.
2 Likes
I think “view” part of LiveView is a little more hidden. I think Phoenix’s MVC initially (and probably still) threw a lot of people—at least who came from Rails—because it had an actual “proper” view layer that was different from templates instead of conflating the two. In LiveView, the view layer is less tangible and any custom view logic usually ends up in the form of private functions (be they formatters or components).
TL;DR, you’re absolutely right that LiveViews are not subsets of views. I often end up calling them controllers depending on the context of the discussion.
1 Like
Not sure if it was mentioned, but to me dead is something that was alive but is not anymore. In this context, even the DeadView term seems to be not correct.
4 Likes
I read this late last night and forgot but yes, you caught me—I was totally trying to “quote” this
“Have you tried doing this as a non-LiveView” feels 100% fine; I’m not sure why it needs a name in the first place, so creating a NEW name and trying to police it feels like an anti pattern.
3 Likes
This is a non-issue for me since “DeadView” having a negative connotation is a completely subjective matter… As @sodapopcan mentioned it already perfectly describes what would be the opposite of a “LiveView”, it’s fine to have symmetry.
IMO, I think it’s just fine to use it, and the fact we have collectively adopted it as an informal term shows me that it’s intuitive enough. Also, even if the docs don’t necessarily adopt that terminology, quite frankly, I do think there are more productive ways to spend our collective energy.
I 100% agree with this and overall (this might sound a bit harsh) I don’t think these discussions usually end up being that productive because it’s a hypothetical problem that doesn’t really affect anyone!? (I’d have to see actual proof that this is an actual adoption issue before changing opinions).
My recommendation is that if you don’t like the term, you can personally refrain from using it because the chances to find a “better” alternative that everyone agrees on are slim to none 
.
4 Likes
