The following is a post I was involved with while working at Headspring (now Accenture).
If you missed our Blazor webinar—well, you can watch it any time here: Getting Started with Blazor. But we’ve also compiled our answers to the myriad of questions we received from our viewers. Because Blazor’s such a new technology, people are super curious about it. See what our presenters—software guru Glenn Burnside and software consultant Kevin Ackerman—had to say about topics ranging from Blazor’s setup to its relation to other technologies, and how it impacts both end-users and development teams.
Q: Do you think a Blazor will be a good competitor to some of the more currently used common JavaScript frameworks?
Glenn: I don’t know that I would call it a competitor as such. But I think that there’s a big market for a lot of front end application frameworks. So where we think that this can be really well-suited is if you have a development team that’s primarily a dotnet shop and you maybe don’t, have as many specialized roles on your team between front-end and back-end developers. Because this lets you bring one common language, one common runtime, to bear on both sides of the equation–server and client. What we’re really interested in, and again, it’s really early days right now, but what we’re really trying to evaluate is what is the total time that it takes to build features in a rich single-page application model. And by utilizing something like this where we can bring homogenous languages across client and server, does that actually increase the throughput and the quality of what the team’s able to build or not? Because we’ve definitely seen as front-end richness has grown that the cost of building those kinds of applications has risen with it. Even though we’re not necessarily getting more features done, but we’ve got people now, and especially in the business world, that have a much richer expectation of what a web app should be like.
Q: Are people just getting started with Blazor comparing it to Silverlight?
Glenn: Yes that’s the elephant in the room, it’s that comparison. And there’s no getting around that or denying it for, for sure. I think the big difference and the reason why we’re not going to watch a repeat of what happened with Silverlight is that when we’re working here and targeting WebAssembly for running, there is no plugin required. So there’s nothing additional that has to be added to or extended on the browser for these applications to run. To users of them, this is just a native application. There’s no difference between what we’re building here and building anywhere else. And so I think that’s one of the big differences.
Silverlight actually was on a pretty good adoption trajectory at the time it was originally released. A big part of what killed it, ultimately, was the rise of mobile platforms starting in 2007 and Silverlight’s inability to be used on those platforms because you had to add an extension into the browser. Obviously, that wasn’t supported on Android devices and iOS devices.
Q: You’re talking about being really excited about this, but what are the potential downsides?
Glenn: So, especially on a WebAssembly version where everything is running in the client, you are going to see a slightly larger initial payload. They’re doing some very aggressive things on stripping unused code out before they compile down to those final DLLs. And they’re doing a lot of minifying of that codebase. But your initial download could still be in the one-to-two megabyte range. That can be an issue, especially if you’re going to be deploying into targets that are really far away geographically and dealing with the latency of that.
Right now, there is a nominal performance tax, if you will, versus some of the native libraries. And that’s because right now in this initial version, the dotnet runtime is actually doing Git compilation and then running that, basically hosted inside the WebAssembly engine. It’s not necessarily doing direct to native WebAssembly pre-compilation of the bite code.
Q: What browsers does Blazor run on?
Glenn: In terms of browser compatibility, this runs on all modern browsers–and I say modern browsers meaning Evergreen, Chrome, Microsoft, Edge Chromium edition, Safari, Android, iOS, and Firefox. So as long as you’re not targeting Internet Explorer and older browser versions you’re good. I believe even the prior Edge version that wasn’t running on the Chrome engine would also support this.
So as long as you’re targeting a modern browser environment, you’re okay on compatibility and it works across platforms. You can also host it because it’s .NET Core, you can actually on the server-side host it both Windows and Linux as well.
Q: Can Blazor use an existing Razor .NET Core app? The goal being to start using it without rewriting the entire UI.
Glenn: Yes, absolutely. So it’s actually really, really easy to do that and you can either do it server-side or client-side where you can actually put that as a sub-unit inside your main app.
There are a few changes you make in the app settings properties on how you set up the middleware pipeline to direct to the routing endpoint. And then you can just start. Most of the time when we’re doing WebAssembly, the client-side piece of that actually ends up being hosted as a starting payload inside the backend, which is just a web API point.
So, yeah, absolutely, really easy to merge that in and start with a hybrid zone.
Q: What would be an easy way to pass objects from Blazor to JavaScript running on the page?
Kevin: That would depend on your scenario, but there’s an interop method. So if you’re actually trying to call a JavaScript method with your C# objects, it’s really easy. You just pass it the method name and pass it your object, and it’ll serialize it to a JavaScript object. there are definitely ways to do it, it would just depend on the specifics of your case.
Glenn: Yeah, I think that the interop story is still developing there, but just knowing that we have the JSRuntime class to use to invoke javascript functions is really valuable because obviously the JavaScript piece of web programming isn’t just going to disappear, poof, overnight.
Q: Can you integrate Blazor with legacy ASP.NET, not .NET Core?
Glenn: No. I mean, you can integrate in the sense that they can both be hosted side-by-side, but Blazor requires .NET Core. Those libraries are not going to be compatible with legacy ASP .NET, which doesn’t run on .NET Core.
Q: What’s the update story for a Blazor app? Both client and server. With shared code, this could potentially be an issue.
Glenn: So this is asking about if you’re trying to update the client-side and the server-side separately. It’s kind of like, in any app, when you’ve got a rich front-end piece and you’ve got a back-end API, what’s the story with keeping them tied together? Is that exacerbated because you’ve got these shared components between them? What do you think, Kevin?
Kevin: The only part that’s tied between them is that DLL for your shared project, and mostly that’s used for API model and things like that. So I think the upgrade story would more or less be that your shared project is going to be that shared piece that you need to upgrade alongside both applications where necessary. And if that’s a problem, you can also have multiple shared projects. You could actually have a part of it that you upgrade, a part of it that you don’t.
Glenn: I think with the way we’ve looked at this really is, we talk about the front end and the back end, but really those two pieces probably should almost always be on the same release cycle. Wouldn’t you agree, Kevin, in these scenarios?
Kevin: Yeah. Ideally. If you start having a larger application, you might have to look at that more, but ideally, if you can just keep the front and back end in sync, it would make it easier.
Q: If you have a client-side Blazor app and then we make changes and we redeploy, do users have to clear their cache or anything like that, or will they able to basically just receive that new payload and update?
Glenn: The page refresh model on that will actually pick that up for end-users. This is almost like if you have JavaScript code. If I have a piece of JavaScript code in my front-end today and that changes, the clients are picking those up automatically, as long as you’ve got your cash header set correctly and that sort of thing.
And it’s a very similar situation here. So this is not an install or a desktop app scenario that we’re talking about. This is all going to be managed behind the scenes for the end-users.
Q: How do you avoid users bypassing authentication in Blazor WebAssembly?
Kevin: That’s on your backend. You’re actually just running a regular API server. So you have all the authentication options available to you that you would for any web API server project. On the front end, you can reuse some of that off code that’s determining whether or not you can make requests or what you can request, what resources you can access, what you can do with them.
You can actually reuse that model on the front end and backend. And because we’re ensuring that we’re always validating it on the backend, we’re always authenticating on the backend. Even if you have a malicious client, they won’t be able to access server resources that they’re not allowed to.
Glenn: Yeah. I think that’s a common theme that we keep coming back to. Architecturally, we’re really still designing our systems the same way we do today, where we’ve got rich dynamic code that’s running in the browser. You know, today it’s mostly JavaScript, Angular. React and it’s communicating to the server via an API. So you’ve got to secure that back end and you’re going to have to manage how the client makes those requests over HTTP to the server to be authenticated. The only difference now is that that client-side code is .NET-based and C# sharp-based.
But we’re still communicating via HTTP client calls, we’re still making those asynchronous calls and getting JSON payloads back. So architecturally, all those same concerns are in place for security, like you said, for repeated validation, for cache-management. None of that really goes away.
Kevin: You’re looking at the same story for the client’s side: the same concerns around any client code is code that can be accessed by the client, that can be manipulated by the clients. Which is why it’s important that the projects are divided in those three parts, so that you’re only shipping client-side code to the client. But other than that, it’s the same story as Angular or React or any front-end framework you’re using.
Q: What about support for server-side, pre-rendering?
Kevin: Server-side prerendering is a good use case for Blazor Server, if that’s important. There are also some mixed-used techniques where you can pre-render the initial payload using Blazor Server, and then rely on client-side rendering with WebAssembly. That takes a little more up-front work and might not be valuable enough for some use cases, especially if you’re dealing with internal business apps where the initial one-time load isn’t that large.
There are ways to do client-side Blazor with server-side pre-rendering, but there are some downsides of rendering the page on the server, and then again on the client. (See this blog post, for example: Pre-rendering a client-side Blazor application)
Q: Is Blazor WebAssembly currently supporting GRPC?
Kevin: I don’t think so. I mean, that’s a separate technology. You can use GRPC to make requests or you can use HTTP or raw TCP. As far as I’m aware, anything you can run as server code on the client, you’d be able to use. I don’t think I’ve seen any examples of that yet, but that doesn’t mean that they’re not out there.
Glenn: And I expect we’ll start to see more of that GRPC adoption cause we’re starting to see that pick up more in general in the .NET space. And obviously you’ve got potential there for higher throughput, lower latency, smaller payloads, less bandwidth. Overdoing full HTTP and JSON objects, especially when you’re really just targeting the backend API for your particular application.
Q: How do you debug in Blazor WebAssembly since it’s running in the browser?
Kevin: So the WebAssembly does support debugging. You are sending symbol information down. That is an evolving story still, I’m not sure where it’s landed at the moment. The other thing is if you have any issues with the client-side debugging, you can switch over to server-side and now everything’s running on your server and it’s just regular C# code at that point.
Q: How does Blazor relate to MVC? Or is it a separate technology?
Glenn: Yeah, so, at this point, I think I’d say it’s a separate technology. ASP.NET MVC has kind of evolved: It went through the split to MVC and API, and then we got the newer version with an ASP.NET Core using Razor Pages.
Which was really kind of the next evolution of that. So I think the story here is this is all still using the Razor rendering engine, and it’s still using Razor Pages and Razor components as the primary user interface definition model. But ultimately what we’re doing, especially with the WebAssembly version, is we’re defining all of those components, but running them inside the browser.
And so again, the back-end is just a web API project. Just like you would build any other web API project in ASP.NET Core at this point. So, related technology, but not quite the same as MVC. What do you think, Kevin? Anything you want to add to that?
Kevin: Just on the web API side of it, not necessarily MVC, but it’s still going to be very familiar. You’re receiving requests, you’re handling it, you’re returning a response. But yeah, the view side of it is moved over to the client, and so that’s going to be a little bit different. But you’re still working with Razor Pages, so it’ll still be a pretty familiar experience.
Glenn: Yeah, I think we all found it was pretty easy to get started and wrap our heads around it. It wasn’t too big a shift in our programming mindset. It was more just about where the code ran.
Q: In getting started with Blazor, it looks like it’s mostly based on components for UI. What about non-visual components, like custom timers or logical data sets, etc.?
Glenn: So actually, I think that’s the great thing. This is one of the things that’s really exciting to me about this, because you’re absolutely right, it is primarily about UI. But it’s all .NET code. So, at any point, you’ve got access to anything that you want to write in C sharp, non-visual, and you can use dependency injection on the client-side code to have it pushed into your UI components and run for you.
Kevin: Yeah, that got me thinking. I don’t actually have any totally non-visible components, but you can see here, if we just took this piece out of it, it’s not going to render anything. So you can have non-visual elements.
You can use cascading parameters, which I don’t think we have time to talk about here, but you can use something like that to pass information down. So, for instance, the form component itself is actually a non-visual component. You don’t see the form, you’d just see the form fields, but the form ties them all together.
So, you definitely can have non-visual components and you could even have one that doesn’t show anything and then later in your application, it does. So that it doesn’t make a distinction between the visual and non-visual, but you can definitely make both.
Q: What about non-visual components that trigger events?
Glenn: I don’t know about that one. I think at that point, you could write it as a Razor Page. It just doesn’t render anything. And then when something else happens, that triggers an event, and it could cause something to get rendered or send off a message to another one of the components in the render context to be able to fire up and run.
So I think there’s a ton of opportunity for those things out there. And, certainly, a lot of the major component vendors like Telerik and ComponentOne are starting to ship out Blazor libraries that run both server-side and client-side.
Kevin: I just wanted to show—I’m not sure exactly what we’re talking about, triggering events, but you can create a div that doesn’t show, you can have any of the JavaScript typically that you’d have on click, on load—all those different things.
And then you can actually have it handle the method. You could have a, message down here that’s just public void DoSomething.
And now I can have it set, like on page load. So you could have a component like that and it will run this code in here. You can have multiple methods on it. You can use any of the JavaScript events. I hope that covers the question.