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.
.