I’ll also add an advantage of assign_async not discussed yet here, which should be part of your decision process, is error isolation. We use processes in Elixir for concurrency and/or isolation. assign_async is the same. It’s great for concurrent async ops, but also equally great for isolation operations that may fail, where you want to reflect the failure in the UI while allowing the rest of the UI to remain functional. For example, communicating with an external resource that can be overloaded, offline, etc. In the discussed case, your primary DB itself being down or overloaded is unlikely to be a graceful failure mode.

This is a silly premise for the same reason that simply wrapping all your Elixir code in Task.async because “concurrency good” is silly.

The team should refocus on conversations that matter

As with any code when load/perforamance is concerned, first make it work, then make it fast, if necessary. Are you measuring load in any of the discussed scenarios? Without measurements everything is a guess, and it’s almost definitely fine as is, given the team’s overly broad stance. Keep in mind the “double render” scenario is only for the initial visit or hard refresh. Live navigation after the initial will not incur additional dead renders. LiveView being stateful also reduces DB load for all the interactions because you don’t have to hit the DB to rebuild/reauth for every interaction like a traditional app. So the double render trade is nuanced because you’re reducing load in other scenarios.

tldr; If you have data fetching in mount that strains the DB or is latent enough to harm UX, then absolutely defer loading with assign_async, but doing so as a matter of course is silly

Yes sorry if I came across a little hash, but I am also going for a bit of “come on folks, lets focus on what matters” wrt to the team discussions. My follow up on the considerations for assign_async is really what folks should focus on. In Elixir when we consider task, we should ask:

• Do I need concurrency?
• Do I need isolation?

If the answer isn’t obviously yes to either of these, we move on. It’s the same consideration for assign_async. You want concurrency when you don’t want to block on concurrent or potentially long operations, and you want isolation when you don’t want a crash in one process to take you out. Sometimes you need one of the two, and sometimes both.

The issue of double render is way down on the list of reasons you’d considering offloading async work. Also not discussed is if you have queries that are so expensive that an occasional double mount can overload the app, you’re likely already reaching for caching solutions, in which case the double mount is lessened by the cache. And caching has its own set of tradeoffs, so like my first post, make it work, then (cache) if necessary. Only measuring will tell you if it’s necessary.