So we are on the same page about Static being a bit on the narrow side. However, accounting for what can be added on top of Phoenix does feel like a stretch. With all respect, going with the stretch: I could add JS to conditionally connect the socket (as some do), so should we rename LiveView to MaybeLiveView? If you add React to a View, is it a LiveView? It certainly behaves as such.
The problem with View is that it’s human nature to use a contrasting term. View is the generic part in LiveView. Live being the type. So what’s the other type?
Regular imho does not seem to fit either. For many, LiveView is the regular type they use these days and the other View is for edge cases.
I am quite certain we won’t get a perfect name, but at least we can come up with something better than ‘DeadView’ (which would never had made it in a comparison) while still supporting the need for a contrasting name.
I propose that we conclude the naming debate with a straightforward process so this debate won’t be just another debate but has a conclusion for those seeking an alternative name without causing 50 variants all over the place.
Let’s invite concise, well-reasoned naming suggestions from anyone interested in contributing until March 14th.
Next, we can use a multi voting mechanism so people can express their top 5. March 21st.
Once we have a short list of viable alternatives, we can use a simple voting mechanism to select the name that best captures the distinction from LiveView. March 28th.
Then simply present the result and call the winning name. After, we will see what happens. Nobody ever voted for DeadView but it spread nonetheless so I have hope it’s a matter of providing an alternative name for those not willing to call it DeadView.
I know that I and others have stumbled upon the name DeadView a few times when we wanted to mention non-Live and wasted cycles by thinking “should do better”. The reason this thread is this long is simply to have all options considered and giving everyone a chance to participate.
Hope to once and for all address the issue some have and move on.
I will not, and that’s the point. If you set up some committee, some voting mechanism, maybe an online survey and then only people who are actually interested in policing words that are not even in official use will take part in your survey, you risk this being used as a proof of community wants to change something that doesn’t need changing because it doesn’t exist.
In the context of web development, the other type is the standard. I can default to using LiveView myself while holding this knowledge of the wider context. So I think “standard view” works for those who wish to avoid “dead”.
“Still” as a noun immediately connects to a stillborn (baby) in my mind, and not just because of my having seen “DeadView”. (Though that’s a factor. ) If the concern with DeadView is that it’s too negative, StillView would not make any sense to me.
If this were a wiki, that would track with me. But a forum is a forum in which people can be heard, and I think most expect that their posts generally remain as they intended.
Those who are already familiar with “DeadView” may search the forum for that term.
I think you’ve made the point about “dead”, and received some well-considered replies. I expect that its use will somewhat subside without making it a whole thing.
In the past a few of such topics were opened, just didn’t know about them.
All came to half a conclusion: would be nice to have something else but nobody made the conclusive call. As a result I -and others as you see in this thread- don’t know which name to use instead so we unhappily fallback to using DeadView, enforcing it further.
What if I decided to use StillView unknowing of the negative connotation it bares for others? Or it’s called 5 different things in one thread?
So this time I hope the result is not only debate (which some consider negative) but a name to be used by those seeking a (part of the) community shared alternative name.
I think it will be nice if the “new” name is closer to the equivalent functionality in other frameworks. Like suggested above, non-LiveViews are the V in MVC and so I think “View” is the best candidate. Calling it a View also removes any negative connotation (it’s not deprecated, it’s a perfectly valid solution for variety of use cases, etc).
In turn a LiveView then translates to a View + something extra.
You all are light years ahead of me when it comes to Phoenix Elixir, but I wanted to add a data point.
I haven’t posted questions for awhile because I’ve been using AI which is heavily reliant on this forum for its answers. I’m mentioning this to share the fact that terminology used in the Elixir Forum gets fed into AI tools and picked up by newer users (and intermediate users like myself). I’m not sure if it would make a huge impact to replace previous posts with the newer term, but I just wanted to mention this as a user who relies heavily on AI assistance.
So I did a quick search on You.com using GPT-4o and it gave me this:
A Dead View is a traditional, static view in Phoenix. It renders HTML on the server and sends it to the client, but there is no persistent connection or real-time interactivity.
I then asked it common terms used for views that are not live views and it gave me this answer:
The most common term used for views that are not LiveViews in Phoenix is “controller-rendered views” or simply “regular views”. These views are rendered using the traditional Phoenix MVC (Model-View-Controller) pattern, where the controller processes the request, fetches data, and renders a template to generate a static HTML response. This is in contrast to LiveViews , which are stateful and interactive, relying on WebSocket connections for real-time updates.
“The beginning of wisdom is to call things by their proper name.”
― Confucius
I must say, the term DeadView did certainly introduce a confusion when I first encountered it somewhere and the reference implied wasn’t immediately obvious to me. The problem wasn’t that it is used but rather that it was not used in the official docs
To me, it feels totally fine to have View and LiveView but if the community wants to rename View to something else, maybe consider making a reference to that rename occurrence distinctively obvious and well documented to avoid panic attacks
Using one type over the other isn’t even a standard nowadays from what I’ve seen and thus I see no “perfect” new name for the original View
I’d really like getting an endorsed name for non-LiveViews. It helps a lot when googling for stuff, and when talking to other developers. I care less what the name actually is.
Just calling the non-live one just View doesn’t quite do the trick for me. It’s like having “LargeCat” and “SmallCat”, but for some reason referring to “LargeCat” as just “Cat” in everyday language. They’re distinct, and none of them are any “more cat” than the other . (</end of already halting cat analogy>)
I get easily confused, more so than some people I think. When you are talking about DeadViews and LiveViews, what specifically do you mean?
In the current Phoenix docs there’s this:
However, most commonly controllers invoke custom modules called views.
Now, when invoking render/3, a controller named MyAppWeb.UserController will invoke MyAppWeb.UserHTML and MyAppWeb.UserJSON respectively when rendering each format.
In this particular case the “View” the docs are talking about is the *HTML module. Normally when I think about DeadView vs LiveView I think about the “whole thing”. This makes it even weirder because now I have to say “a DeadView View” when I talk about the *HTML module
I lean towards something similar to what @olivermt suggested. Maybe OneShot View, even though it’s a bit wordy. My thinking is that the LiveView keeps a live websocket connection, whereas with the OneShot View you very much render and forget (from a server side p.o.v.). That naming kinda reflects their difference in behavior. I don’t love this suggestion myself, but it’s the best I can think of…and I like it more than DeadView
I’m positive that this has been asked a million times before, but I can’t find any good details about it - would it be possible to somehow, to some extent, unify how DeadViews and LiveViews are written? If anyone has a pointer to a forum post or something that deals with this I’d love to read that!
One of the few things I dislike about Phoenix is that I have to make the choice between LiveView and DeadView when I start creating a new page, and it’s a bit of work “switching” from a DeadView to a LiveView later on once I realize that I need it. I also need to understand and remember both the DeadView and LiveView way of doing certain things. There’s also the fact that when I’m writing helper functions I need to think about a lot more things like “am I receiving a conn or a socket here”, to be able to support both DeadView and LiveView. My ideal Phoenix incarnation would only have View, and it would be most similar to what we currently call LiveView
Could we have a LiveView that could be told to not perform the websocket connection for example? (just as a silly idea). I’m sure a lot of people have considered the plausability of this…and I’d love to read more about it!
Thanks for bringing up the issue @BartOtten. I think it’s definitely one worth fixing. As a dev who’s relatively new to Phoenix it took me waaaay longer than I’d like to admit before I had worked through the naming confusion and understood what was what in the Elixir/Phoenix world
I actually like it this way. My applications are either 95%+ pure LiveView or 95%+ pure View; my brain does not work well if I have to mix and match on the fly. So, I take some time to make a call before writing the first line of code. I consider it time well spent.
I completely get what you mean about taking the time to decide if the view should be live or not before going ahead with the implementation. I do the exact same thing, and usually it works well.
However, I have been found guilty of being too lazy to “promote” a view to being Live, because of added functionality / requirement changes. Instead I’ve hacked on a form with a POST, felt a bit of shame, and moved on
I have a couple of pages like that, because even though they made sense as View with the initial requirements, I would 100% rewrite them using LiveView now knowing how they evolved.
I am not sure you do. I meant to keep the whole application pure View or pure LiveView; not just individual pages.
I don’t see anything wrong with old school form with POST, if it work the same way everywhere in your application. In UI design, consistency trump flashiness. If the user input does not pass validation, you still can re-render the form and pointing out the problem using plain View, so no functionality is lost.
