This is amazing!! Congratulations! 🎉 Thanks so much for sharing. Would love to know more. Please drop me an email at mail@patrickgod.com. Take care, Patrick
To your question, I think I'm even more confused now I built a blazor server app in dotnet 6. And the "server has disconnected" error was such a bad user experience I moved to a hosted wasm app with grpc For my very data driven app, I still can't wrap my head around where streaming fits in, if at all into this model. If I assume that annoying Signal R / disconnected after a timeout thing still happens - what's the right architecture for dotnet 8 / wasm / streaming / etc A video on this would be really useful
I am definitely a little confused by all the new options. I appreciate your videos and hope to see more. Currently, I have a .net 7 WASM app (hosted separate, not .net hosted) with a normal web api. I like this set up a lot, the only downside is the initial load time of the app.... I am curious what is the best option for people like me? What if I want my entire app to be WASM but maybe just the landing page be server generated so people don't see the loading, is this possible?
I'm exactly in the same situation and, furthermore, I wonder if all the controllers added to the Server project are also downloaded to the client or is that the case only for the razor components?
Thanks for these videos, they are really helpful. I find that on the counter page (on the initial visit to the page), with Auto Render or Wasm render there’s a small delay with the button actually working until it’s finished downloading everything, which is annoying. I think the flexibility with the options is great, it will just take some getting used to having your components split over 2 projects. Also is there an easy way to switch SSR off, so it works like the older WASM template and not do a trip to the server for the page?
Hi Patrick, imho you do not need to add the HttpClient to the server project as it does not issue any Http requests (it would just send the requests to itself anyway ;-). Otherwise great stuff :-)
Yes, please please please create a tutorial on .Net 8 to replicate the .Net 7 WASM... I am fighting ( and losing ) against .Net 8 and my API calls fail.. Dependency Injection fails.. MudBlazor is a pain.. I feel lost. I love your videos and would truly benefit from more help. Thanks!
I don't really like it, it adds unnecessary complexity to the project and it looks messy. We'll have to give them time to sort everything out, since although double rendering is great, everything it entails doesn't seem worth it.
These different rendering modes are confusing (and will lead to confusion). Perhaps I am missing something, but if the goal was for Blazor to be more applicable for 'websites' then I think they need a similar/but different stack - don't try to be a kitchen sink. SPA needs are different and WASM (albeit slow to load at first) is fantastic for SPAs - why are two versions are we trying to step away from that?
At start I was confused as well, then I found out what was so confusing after playing with it, its that there isnt a clear way to differentiate between server- and client-calls. The .NET team hasnt provided us with a clear solution for us yet and it might be that the community has to come up with a good practice. - By default, components use the *Static render mode*. The component renders to the response stream and interactivity isn't enabled. *Effect*: code runs- and renders on server, but without interactivity. - The *Server render mode* renders the component interactively from the server using Blazor Server. User interactions are handled over a real-time connection with the browser. *Effect*: code runs- and renders on server, with interactivity (with prerender). - The *WebAssembly render mode* renders the component interactively on the client using Blazor WebAssembly. The .NET runtime and app bundle are downloaded and cached when the WebAssembly component is initially rendered. Components using the WebAssembly render mode must be built from a separate client project that sets up the Blazor WebAssembly host. *Effect*: component calls api endpoint and renders after as usual wasm. - The *Auto render mode* determines how to render the component at runtime. The component is initially rendered server-side with interactivity using the Blazor Server hosting model. The .NET runtime and app bundle are downloaded to the client in the background and cached so that they can be used on future visits. Components using the automatic render mode must be built from a separate client project that sets up the Blazor WebAssembly host. *Effect*: if you use AutoRenderMode, the page loads twice, once on server render (with prerender) and once on wasm render; 2 calls in total. Source: learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0
Yes, I had a thought on all of this, and my conclusion is that I will stick with a pure progressive web assembly app. It is the best option for my use case. All of this should have been done on a none LTS release because it looks like a job done on the rush and some changes are going to come. It looks like also that Microsoft is pushing its signar R stuff. I want to use the CPU of the client, not paying money to Microsoft and by the way, it's not ecologist behaviour. With AOT the main drawback (decompiling your code) of web assembly is removed.
Patrick, you could have just placed any shared library stuff into the client (you didn't need a 3rd project). It is references by the server anyway, so anything there will be available in both WebAssembly and Server.
That's what I came by to say. The intention of the template is that models that need to be shared with the client just go in the client project and they are automatically available to the host project too. Of course, you can still make a 3rd "shared" project if you would like, but there's no actual need for it anymore. Simplifies things a bit.
Hi Patrick, I don’t know if you see this, your videos helped me finish my Bachelor’s Project and then get a job at Microsoft. Thanks a lot
this is awesome!
This is amazing!! Congratulations! 🎉 Thanks so much for sharing. Would love to know more. Please drop me an email at mail@patrickgod.com. Take care, Patrick
To your question, I think I'm even more confused now
I built a blazor server app in dotnet 6. And the "server has disconnected" error was such a bad user experience I moved to a hosted wasm app with grpc
For my very data driven app, I still can't wrap my head around where streaming fits in, if at all into this model.
If I assume that annoying Signal R / disconnected after a timeout thing still happens - what's the right architecture for dotnet 8 / wasm / streaming / etc
A video on this would be really useful
I am definitely a little confused by all the new options. I appreciate your videos and hope to see more. Currently, I have a .net 7 WASM app (hosted separate, not .net hosted) with a normal web api. I like this set up a lot, the only downside is the initial load time of the app.... I am curious what is the best option for people like me?
What if I want my entire app to be WASM but maybe just the landing page be server generated so people don't see the loading, is this possible?
I'm exactly in the same situation and, furthermore, I wonder if all the controllers added to the Server project are also downloaded to the client or is that the case only for the razor components?
Same problem, question, thought.
Me too.
I didn't know it, but I needed it. Thanks Patrick!
Thanks gave a good overview :)
Thanks for these videos, they are really helpful. I find that on the counter page (on the initial visit to the page), with Auto Render or Wasm render there’s a small delay with the button actually working until it’s finished downloading everything, which is annoying. I think the flexibility with the options is great, it will just take some getting used to having your components split over 2 projects. Also is there an easy way to switch SSR off, so it works like the older WASM template and not do a trip to the server for the page?
Hi Patrick, imho you do not need to add the HttpClient to the server project as it does not issue any Http requests (it would just send the requests to itself anyway ;-). Otherwise great stuff :-)
Yes, please please please create a tutorial on .Net 8 to replicate the .Net 7 WASM... I am fighting ( and losing ) against .Net 8 and my API calls fail.. Dependency Injection fails.. MudBlazor is a pain.. I feel lost. I love your videos and would truly benefit from more help. Thanks!
Great stuff Patrick, was going to suggest you do this video when I watched the crud video last night
It would have been good if you upgraded one of your .net 7 wasm web hosted apps to .net 8
I don't really like it, it adds unnecessary complexity to the project and it looks messy. We'll have to give them time to sort everything out, since although double rendering is great, everything it entails doesn't seem worth it.
These different rendering modes are confusing (and will lead to confusion). Perhaps I am missing something, but if the goal was for Blazor to be more applicable for 'websites' then I think they need a similar/but different stack - don't try to be a kitchen sink. SPA needs are different and WASM (albeit slow to load at first) is fantastic for SPAs - why are two versions are we trying to step away from that?
At start I was confused as well, then I found out what was so confusing after playing with it, its that there isnt a clear way to differentiate between server- and client-calls. The .NET team hasnt provided us with a clear solution for us yet and it might be that the community has to come up with a good practice.
- By default, components use the *Static render mode*. The component renders to the response stream and interactivity isn't enabled.
*Effect*: code runs- and renders on server, but without interactivity.
- The *Server render mode* renders the component interactively from the server using Blazor Server. User interactions are handled over a real-time connection with the browser.
*Effect*: code runs- and renders on server, with interactivity (with prerender).
- The *WebAssembly render mode* renders the component interactively on the client using Blazor WebAssembly. The .NET runtime and app bundle are downloaded and cached when the WebAssembly component is initially rendered. Components using the WebAssembly render mode must be built from a separate client project that sets up the Blazor WebAssembly host.
*Effect*: component calls api endpoint and renders after as usual wasm.
- The *Auto render mode* determines how to render the component at runtime. The component is initially rendered server-side with interactivity using the Blazor Server hosting model. The .NET runtime and app bundle are downloaded to the client in the background and cached so that they can be used on future visits. Components using the automatic render mode must be built from a separate client project that sets up the Blazor WebAssembly host.
*Effect*: if you use AutoRenderMode, the page loads twice, once on server render (with prerender) and once on wasm render; 2 calls in total.
Source: learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-8.0
Yes, I had a thought on all of this, and my conclusion is that I will stick with a pure progressive web assembly app. It is the best option for my use case. All of this should have been done on a none LTS release because it looks like a job done on the rush and some changes are going to come.
It looks like also that Microsoft is pushing its signar R stuff. I want to use the CPU of the client, not paying money to Microsoft and by the way, it's not ecologist behaviour.
With AOT the main drawback (decompiling your code) of web assembly is removed.
Patrick, you could have just placed any shared library stuff into the client (you didn't need a 3rd project). It is references by the server anyway, so anything there will be available in both WebAssembly and Server.
That's what I came by to say. The intention of the template is that models that need to be shared with the client just go in the client project and they are automatically available to the host project too. Of course, you can still make a 3rd "shared" project if you would like, but there's no actual need for it anymore. Simplifies things a bit.
It makes me confused. why I should put some of components in client project and others in server project. after while it will be make me angry :))