Blazor: Modern Web development with .NET and WebAssembly

Play Blazor: Modern Web development with .NET and WebAssembly
Sign in to queue


Client-side web development has long been the sole domain of JavaScript. WebAssembly is poised to change that by opening up the web to the full ecosystem of languages, frameworks, and tools. Blazor is an experimental project to bring .NET to the Web via WebAssembly. In this session you'll see how Blazor enables full stack web apps using C# with no code transpilation or plugins – just open web standards. 







The Discussion

  • User profile image
    Ben Hayat

    My question/concern regarding Server-side model that Dan showed at the end which will be part of ASP.Net Core 3.

    Note: When we run apps on the client side we get to use the client's computer/device resources (CPU, Memory and etc). So suppose we have a native Mobile app or even a SPA on browser (JS or Blazor in client), as user is using the app, the client's device is executing the codes and when it needs data, that's where the server's CPU/Memory gets activated to provide data. In this model, you could have 1000 clients and an average server can serve them, when they need data.

    But with the server-side Blazor model, that means for 1000 clients being active, the server has to maintain 1000 client's sessions and codes and memory. We're back again into the same problem we faced with ASP MVC. Although the Blazor Server-side model has a lot less data traveling between client and server, which is better than MVC model, but the server can quickly get bogged down, as client numbers go up.

    Is my concern valid?

  • User profile image
    Ben Hayat

    After research Angular, React and Vue, my conclusion was to go with Vue as the cleanest, easiest and smallest framework.
    It was designed very intelligently and you can see how it covers the best of other products.

    Blazor team, should seriously look into Vue in depth as so much has already been designed and is working.

    Another point to Blazor team, is to make sure code spliting and component lazy loading is supported for L A R G E apps.

  • User profile image
    Goran Halvarsson

    Great presentation!!
    I have to disagree with previous comment. Blazor is a HUGE step forward, even the server side part.
    No more page requests, it's all real-time using signalR. This will probably replace mvc and core.mvc.

  • User profile image

    Wow! awesome!

    I love it and damm sure every C# developer will like it, now no need to run other JS frameworks.

    Thanks Daniel!

  • User profile image
    rod macdonald

    Well I'm gettin' kinda confused. I thought the whole point of Blazor was to enable other languages and not just JavaScript to be used for the development of PWAs running client side via WebAssembly. But here we are talking about Razor Components and writing against Web API, and then using SignalR (still reliant JavaScript) which to me sounds a bit potty, all this in the hope that a hitherto unknown version of .NET can work server side and be switchable to client side WebAssembly. I wish I could buy into that.

  • User profile image

    @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.

  • User profile image

    @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).

    Lazy Loading of app areas isn't supported yet, but it is on our backlog to add:

  • User profile image

    @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.

  • User profile image

    @danroth27: Great presentation. This is what we're looking for. Thank you.

  • User profile image

    Pretty good presentation Dan!

    I haven't put my hands on Blazor until I finished watching this video. It's fantastic the way that we now can develop in the client side by using(in my case my prefer language) C#.

    I'm  so excited with this project!!

    Thank you :)

  • User profile image
    rod macdonald

    Many thanks for your response Daniel, appreciated, and apologies for my frustration. Have felt for a long time that MS could overcome the loss to the mobile space by focusing not on backend stuff in VS but really coming up with a UI solution for apps. That is of course why Blazor and WebAssembly are so exciting as you point out. Putting object graphs to one side, I believe .NET Core should embrace HTML and .NET Framework embrace XAML, with considerable overlap (they could become one thing). If a UI could be remoted or the OS was just a UI rendering engine - maybe the world becomes just a screen - AKA Windows.

  • User profile image

    Hi, Many thanks. i have one question. How to use identity server 4 in blazor? is it possible? do you have any lesson of blazor and identity server 4?

    Thank you very much.

  • User profile image
    Theodore Zographos

    Excellent presentation, Dan.

    I was wondering, in the case of server-side Blazor, how does the scaling-out (i.e. multiple back-end servers behind a load balancer) work? Are you using some sort of out-of-the-box backplane (e.g. service bus) to allow for communication between the servers?

    Also, do you have any metrics regarding the performance of the DOM "delta" and "patch" on the client? In the "increasing counter" example in your presentation it seemed fairly instantaneous. How would it behave on a much larger DOM with more elements needing update?

    Finally, what happens with the state information on the server if the client-server Signal-R channel is broken?

    This is a very promising technology. Keep up the good work,

  • User profile image
    Brad Wood

    Finally a modern solution that includes makes server-side and client-side code cohesive! I'm sure WebAssembly will propel other languages/frameworks similarly, but this is awesome for .Net developers.

  • User profile image

    A great and simple solution for web application programming with c#

  • User profile image
    The Nerd


Add Your 2 Cents