In his interview with Nick Chapsas (https://youtu.be/2uLGXe95kTo?si=uhErSaWoCbe87fl1&t=3552), Daniel Roth mentioned that he sees the auto render-monde as his personal "last resort" mode.
Hearing him saying this surprised me, because the Blazor team hyped up the auto render-mode so much when it was initially released! Roth mentions that he would avoid this mode because he "would have to think about both the concerns of Blazor Server and Blazor WebAssembly". But I'm not sure I'm seeing why this is such a problem. In auto mode, the Blazor Server concerns are only relevant the first time a user accesses the site and does not have the WebAssembly runtime downloaded. On subsequent visits/refreshes, only the WebAssembly concerns are relevant. It seems to me that for apps that have a lot of interactivity, and for which we don't want to delay the use of this interactivity by users (until the WASM runtime is downloaded), the auto render-mode is the best choice (if we don't want to use the pure Server mode to avoid the annoying SignalR disconnection issues).
But is there something I am missing? Should the auto-render mode truly be a last resort, like Roth says, even in a scenario like the one I described? If so, why?
While it may have been initially hyped a little, I agree totally with Dan's comment. Shortly after Net 8 arrived I did some experimenting with it and came to the same conclusion Dan expressed. Here's my commentary from Dec 2023 - https://shauncurtis.github.io/Posts/Mongrel-Blazor.html.
Any page may be Server rendered. An <F5> will cause the Weather page to reload. Every page, every object, every service [often the sticky bit] needs to work in both Server and WASM mode. On a larger project that's potentially a lot of complexity [you don't need].