Not completely. It works for the case @benwilson512 explained. But there’s another usecase assign_new helps with, which you cannot split appart with connected?/1. If you use nested LVs and they’re connected then assign_new allows sharing assigns from the root LV to children, so e.g. a current user is only fetched once and not for each individual LV.
That sharing (and not refetching) is the reason assign_new needs a callback to be passed.
Did not know that, interesting 
… Do you have any idea why it works like that?
I thought about using skeletons (placeholders) for the static mount of the page before, but it makes more sense now if we can’t avoid hitting the database twice on mount. It’s a good idea @sodapopcan, but I’d have to think more about in the future to see what are the downsides (for this particular use-case I mean).
By the way, it seems assign_async can potentially introduce something similar to an island architecture in the future if I understood it correctly, where things are fetched independently. For this scenario I presented might not be that useful, but I can think of others where it could be, that’s great 
.
Even if this is a little bit off the main point, this was fun, thanks 
.
This is one of the examples that came to mind, but I’d love to see if we have other helpful patterns in the community as well. I personally think that it would be great if we had some room to create other helpers that allow us to write more concise code in LVs for cases like the ones I mentioned.
They’re just straight up different connections from the client browser. When the browser first goes to say http://example.com/page it does an HTTP GET request. To respond to this GET request Phoenix does the static render to return static HTML. The static render is done at this point, and the Elixir process that handled it has come and gone. The HTML contains the CSS and Javascript links, which the browser also then loads and runs (assuming the browser is setup to run javascript).
The Javascript includes your Phoenix LiveViewJS code, which then connects and opens a websocket connection to the server. It’s then over this websocket connection that the second render occurs to establish the actual connected live socket.
