@Ben Hayat: Blazor is really made up of two parts: a WebAssembly based .NET runtime and a component-based web UI framework. The Blazor component model (Razor Components)will be integrated into ASP.NET Core 3.0 along with the ability to run components on the server ("server-side Blazor"). In parallel we will continue to work on the WebAssembly support for .NET and support for running Blazor client-side in the browser, but we expect it to take a bit longer. Regardless of whether you are running Blazor on the server or the client we are keeping the component model the same. This means you should be able to switch from one hosting model to the other, as shown in the Blazor .NET Conf session here: https://youtu.be/61qmX5eAPwI?t=54m56s
@rod macdonald: The goal is still to enable full stack web development with .NET. Blazor is really made up of two parts: a component-based web UI framework, and a .NET runtime based on WebAssembly. Up until recently we've been saying all of Blazor is experimental. The news here is that we are moving forward with shipping the web UI part and we will ship it in a way that you can use both on the server and the client. That's progress! For server apps you can use the Blazor app model with an existing .NET runtime that you can already use: .NET Core. For client-side apps we will continue to work on the .NET support for WebAssembly and we hope to ship it once it's ready.
@Ben Hayat: We are taking inspiration from all the popular JS frameworks (React, Angular, Vue, Aurelia, etc), while also making the framework idiomatic .NET (not just a straight port of an existing thing).
@Ben Hayat: Correct, using the Blazor on the server does mean maintaining an active connection per client and using server resources to manage that session. Obviously this model can't support offline scenarios and network latency is a concern.
The server-side model does have a number of advantages. It has much lower demands on the client, better startup time, and the normal .NET ecosystem and tooling just works. You can find a more complete discussion on the tradeoffs with the server-side Blazor model in the Blazor 0.5.1 announcement post in the "What is server-side Blazor?" section.
The server-side Blazor model is not a replacement for a full client-side solution. Building a full client-side solution is still our goal. We think of server-side Blazor as on the way to a client-side solution. We can make progress on the Blazor component model while the WebAssembly based .NET runtime matures. By keeping the Blazor component model the same regardless of whether you are running server-side or client-side you should have the flexibility to decide which hosting model works best for you.
@Goran @AdSharma Unfortunately the default config scheme for Kestrel was pulled out of the ASP.NET Core 2.0 release after this video was recorded. Instead you will need to configure Kestrel in code, or bind Kestrel to configuration yourself.
Support for individual user accounts with the Web API template in VS is not available yet. We are still looking at providing a supported on premise offering for token issuance in addition to providing integration with Azure AD B2C.
@Stilgar Yeah, I get where you are coming from. Why not just follow the spec, right? Pragmatically though we are hearing from a lot of frustrated Web API developers that want to see JSON when testing with the browser. It's actually a top Web API question on StackOverflow. There is precedence for doing this in other platforms - RoR has pretty much the exact same behavior that we are adopting. So, it's a tradeoff. The good news is that if you really don't like this new default behavior you can turn it off by setting RespectBrowserAcceptHeader on your MvcOptions.
@BeingDev You will need both your wwwroot and approot to publish to IIS and they should be siblings in your website folder. The wwwroot folder should be configured as the physical path for your website. Also, make sure you use the x64 bit version of DNX when you publish as this is required by IIS. We plan to add tooling in the future to make this easier.