Daniel Roth

SE Radio 458: Daniel Roth on Blazor

Daniel Roth, program manager at Microsoft discusses Blazor a technology from dotnet to build interactive UIs. Host Priyanka Raghavan quizzed Daniel on the need for Blazor and how it compares with other client side rendering technologies like Angular and React. Daniel deep dived into the different components of Razor including Razor pages, how blazor works with web assembly ,signalR for communication and Blazor’s adherence to open web standards . Daniel also highlighted the different IDEs, debugging support and remote code debugging with VS code. The host also quizzed Daniel on Identity and access management and support from the Blazor framework to guard against XSS attacks. Lastly the segment focuses on community support for Blazor including open source support, community meetups to support adoption and future roadmap.

This episode sponsored by O’Reilly.

Related Links


Transcript brought to you by IEEE Software
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].

Intro 00:00:00 This is software engineering radio, the podcast for professional developers on the [email protected] se radio is brought to you by the computer society. Well, as your belief, software magazine online at, keeping your teams on top of the latest tech developments is a monumental challenge. Helping them get answers to urgent problems they face daily is even harder. That’s why 66% of all fortune 100 companies count on O’Reilly online. Learning at O’Reilly. Your teams will get live courses, tons of resources, interactive scenarios, and sandboxes, and fast answers to their pressing questions. See what O’Reilly online learning can do for your teams. Visit O’Riley dot com for a demo.

Priyanka Raghavan 00:00:47 Welcome to software engineering radio, and I’m your host Priyanka Raghavan in conversation with Daniel rot today, we’re going to be exploring blazer a technology from dark net to build interactive UAS. Daniel is a program manager on at Microsoft, and he’s been at Microsoft for several years and worked in different parts of dark net, right from windows communication foundation XAML. And then before moving on to, he’s also given many tech talks and featured in a number of podcasts. So if you Google him, you’ll find a lot of stuff online. So welcome to the show, Daniel,

Daniel Roth 00:01:27 Thank you very much. It’s great to be here.

Priyanka Raghavan 00:01:29 Is there anything else you would like listeners to know about yourself before we jump into blazer?

Daniel Roth 00:01:34 Wow. I just really enjoy working I’ve been doing that my entire career at Microsoft. It’s been a lot of fun, particularly in these recent years, watching dotnet go from being a windows specific technology closed source to being open source. Cross-platform handling pretty much any workload you can think of web games, desktop, mobile, I guess like say I’m a pretty big dotnet fan.

Priyanka Raghavan 00:02:00 That’s great because we’re going to quiz you a lot on that because we’ve done fewer episodes on the soft engineering radio. So we hope to do more on that front. Okay. So the first question I want to ask you is obviously I and looked up blazer before the show. And then the thing that struck me was the one line of Jed that Liza lets you build interactive web DWIs using C-sharp instead of JavaScript. So why did the darknet community feel this need?

Daniel Roth 00:02:32 That’s a, that’s a great question. So, we’ve had ways to build web apps that I would call server rendered for a long time with And then more recently with core with a server rendered web app, it’s kind of like the classic web application. You put your code on a server, a request comes in that code generates responses to those requests, usually HTML, maybe some Jason or other data. And those get sent back down to do the browser. But if you wanted to do anything client side, like have code run in the browser on the, on the user’s machine, then all the only way historically that you could do that was using JavaScript and JavaScript is great. Like it’s really amazing to see how JavaScript has evolved and progressed over the years. But if you’re developer and you’re used to working with the C sharp and the dot-net ecosystem, it can be a lot of complexity to have to bridge those two different development worlds, the JavaScript ecosystem with its languages, its tools, its frameworks, and then also whatever you’re using on the server.

Daniel Roth 00:03:37 And in my case, it’s natural and it’s frameworks and tools and so forth. I often compare it to like speaking multiple human spoken languages. Like I speak English, obviously having to learn another language. I mean, I know a little Portuguese, I can say like, hello, and where’s the bathroom in Portuguese, but I’m certainly not fluent in it. If, if I have my choice, I’d rather speak and write. And the, my, my, my native tongue for is kind of like my, my native tongue. So Blazer’s goal was to make it so that you could reuse your dotnet skills, your dotnet code, your, your tools and your knowledge to build full stack web apps with, just to basically write it entirely in your developer native town.

Priyanka Raghavan 00:04:21 Okay. That’s great. Actually, I was thinking more in terms of there’s lots of dissatisfaction with JavaScript as well. In fact, I did an episode, my second episode, I recorded with James Smith it’s episode 4 61, where they talk about how, you know, you could ship software with bugs. And he actually came up with the statistics, which he said that the, I asked him, is there any one language where you have a lot of bugs? And he said, JavaScript. So I thought, well, that is one of the reasons why the darknet community felt that need,

Daniel Roth 00:04:54 I think there are bugs everywhere. Like we’re all honest with ourselves. We all know that all, all software has, has bugs and different languages and platforms. They have different strengths and different sweet spots. Like I said, I think there there’s a lot. That’s good about JavaScript, particularly with modern JavaScript. I do remember, you know, years ago when I first started looking at JavaScript and I will admit that 10 years ago, maybe I was a bit horrified with some of the limitations of JavaScript, like function, scope, variables, everything was in the global namespace, all the, all the classic problems, but JavaScript has come a long way since then. A lot of the modern JavaScript standards have addressed really a lot of those issues. The ecosystem is huge. There’s, there’s a lot of JavaScript code that gets written and a lot of great apps that are written in that world.

Daniel Roth 00:05:41 So Blazer’s goal is not to get rid of JavaScript. There’s still, I think, plenty of places where you will write JavaScript and that’s perfectly fine in my mind. It’s the goal is to give you options like with the front end web development, historically, you only had one option. You had to write JavaScript if you, if you had a different tool or a different library that worked great. If you were writing a native application like a desktop app or a server app, you had all these options available to you, Python, PHP, Ruby, go, you know, Ross, whatever you wanted to use, you could use it unless it’s the browser. That’s just gotta be JavaScript with laser. I think we’re trying to start to open up more of that development world for front end web development so that you have those choices. You can use the right tool.

Daniel Roth 00:06:29 That makes sense for your particular scenario. And I think for many dotnet developers, you know, C sharps, what they love to write and they would love to, they can be more productive by being able to write and Don it in C sharp on the client. Some cases you may still want to use JavaScript. Like I said, there’s a lot of libraries Blaser actually has, um, features where you can do JavaScript, interop, where you, if you want to call into some JavaScripts, like reuse existing library, call into some very specific browser API, well, you can do that. And then you can call back from JavaScript into, So they actually can work together and they compliment compliment each other in that way.

Priyanka Raghavan 00:07:06 Okay. So I was actually going to ask you that if you could work with JavaScript, so you’ve covered that. That’s great. So as you said, there’s this thriving ecosystem for languages like react. There’s also several component sharing things on bit and get hub. And this also makes react sort of universal language for web iOS, Android windows. So if you were to, you know, sort of say like three reasons, why someone should somebody like a C sharp developer should choose C for the front end should go for Liza instead of react. Is there anything that comes to mind? Yeah,

Daniel Roth 00:07:44 Sure. Well, I mean, first of all, I would say that Blazer’s heavily inspired by react. If you’re familiar with react and you come to blazer, you’ll probably look at blazer and be like, huh, this, this kind of looks like react, except instead of JavaScript, I’m writing C sharp and you know, strongly type classes and all those things, the main benefits that you’ll get, I mean, the first one is going to be like, if you’re already and you’ve got that to those skills and that code that you just want to reuse blaze is going to make a lot of sense because now your devs can operate across the stack. They can work on the backend if you’re using dotnet for their backend. And then they can also leverage their skills on the front end as well. We talked to a lot of customers that they say that just results in tremendous cost savings.

Daniel Roth 00:08:26 Like there’s like a company called the postage. That’s a new startup that handles end of life concerns like managing your documents and your accounts so that after you pass away, your family members have access to those things during a very stressful time in their lives. And they wrote their entire web application using laser and their backend is all using rebuilt, using dotnet as well. They use the same engineers across the stack and they they’re super happy. They, they, they basically say that they were able to cut their development in half. So that’s that’s the first one is just getting the full stack benefit. We’re and C-sharp. And when you’re using dotnet particularly on the server, the performance benefits are just tremendous, is just super fast. There’s a public open source benchmark called tech and power that tries to compare all of the server stacks on the planet against each other with a consistent set of benchmarks is right up there at the top with some of these really a somewhat more esoteric native implementations compared to node it’s you’re.

Daniel Roth 00:09:30 I think you’re going to see multiple times improved performance in terms of like throughput with a dotnet server base stack. And if you’re going to be using dotnet on the server, why not use it on the client as well? And then I guess for the third reason, I would pick just the, the stability and maturity of the platform when you’re working with dotnet, you’re going to be using the dotnet core libraries like these base class libraries of API APIs that Donna just gives to you. You don’t have to go searching for a whole lot of different packages and ecosystem options because the platform just gives you a lot of those, those API APIs, right out of the box in a very consistent and stable way. Like they don’t, they don’t change. We maintain a very high compatibility bar. So as you move from dotnet version to dotnet version, those API APIs, they’re still, they’re still the same. And you can, can just use them. You get great tooling with visual studio, you get C sharp and the latest C sharp features. I think C sharp is a fantastic language. Lots of innovation coming, and C sharp page C sharp nine. And now in the future of C-sharp 10, I think. Yeah. I think you’ll find you get quite a bit of productivity, performance and skills reuse. Those are the things that come to mind.

Priyanka Raghavan 00:10:42 Okay. So then the last question before we actually jump into the specifics of laser was, uh, technologies that come out of Microsoft at always perceived as working on one platform. Can you talk a little bit about that with Liza that’s changing or changed?

Daniel Roth 00:10:58 Oh yeah. And it’s not just blazer, like all I was talking about that. Uh, actually earlier on that I was just so much fun to see how far Donna has come. Don ed is fully open source, the entire stack. You can build it top to bottom. You know, it ships in different Linux distributions like red hat. It does. Cross-platform Donnette runs on windows. You can develop a windows on Mac, on Linux. You can deploy applications, Android and iOS and watches and TVs and all sorts of devices. It’s not a windows only product by any stretch of the imagination it’s free to use, which is just fantastic. So yeah, it’s, it’s a very different world for Microsoft. And I have to admit it’s a lot more fun to work that way. Like being able to be open and transparent with our open source projects, blazer is just part So it gets all those same characteristics, blazer as open source. You it’s cross-platform, and it’s actually based completely on open web standards. There’s nothing we do in blazer that isn’t just using the web. We use web assembly, we use WebSockets HTML CSS. It runs in any modern web browser. You don’t need any like proprietary plug-ins or special bits in order to make it work. It’s just open web tech, but open source software that runs cross-platform.

Priyanka Raghavan 00:12:16 Okay. Super. So let’s now jump into different components of blazer. So over the weekend I tried blazer before the interview. So one of the things I did see, yeah. The, one of the things I did see was the reason pages. So I think that’s the first thing I’d like you to talk about. So what are the pages?

Daniel Roth 00:12:37 Yeah. So razor is, are, you can think of it as our templating engine for web platform. A razor is how you can generate markup like HTML markup dynamically with like C-sharp based logic. There are lots of templating engines out there as razor just happens to be the one we use, but it’s, I would say it goes kind of a step beyond your typical templating engine. It’s a very deep melding of C-sharp and markup together. Like you just write normal C-sharp code intermixed with your markup, and there’s a razor compiler that will then turn that into a dotnet class, a C sharp class, which then encapsulates that rendering logic that you’ve just authored. But it’s a really pretty seamless how you transition back and forth between HTML and CSS. It has a very light syntax for doing those transfers. And you can just write normal imperative logic around your markup, what you do. If you want to have a loop, you just write a for each loop and then have markup inside of that for each loop. If you want to have a conditional, you just write an F check like you would in any normal C-sharp file. And I think that’s really convenient as opposed to other models where you have like template engine specific syntaxes for those constructs with razor, it’s really just C-sharp. And then you write markup where you want to generate it.

Priyanka Raghavan 00:13:53 Yeah, I do agree that it was pretty quick to start up for me. Think it just took me about 10 minutes to write the simple hello world type of program.

Daniel Roth 00:14:02 Oh, that’s, that’s certainly been the goal, like getting fried and blazer. We try really, really hard to make that as easy as possible. You should be able to go to a, which is the homepage for Glazer specifically and get an app running really, really fast. If you can’t let me know. Cause we’d love to fix that. We want to get you up and running and yeah, about five, 10 minutes. And have you feel productive with great, not just with getting the app running, but also with great tooling. Like as you edit your razor files, if you’re using visual studio code or visual studio or visual studio for Mac, you should have fantastic IntelliSense helping you out every step of the way. Yeah. We try to get you going fast

Priyanka Raghavan 00:14:41 In the literature. There’s a lot of emphasis on how laser ties in with the web assembly. So I want you to just explain what by assembly is for our listeners and then how

Daniel Roth 00:14:51 It fits in with pizza. Yeah, yeah. This, this all ties into, well, how, how does this even work? Like how do you suddenly code that runs in a browser? That’s never been a thing before. So web assembly is an open web standard. It’s basically a byte code format for the web. Historically browsers could only run JavaScript. Well, that’s no longer true. They can run JavaScript and they can also run this low level by code format called WebAssembly. And the idea is that if you can take code and you can compile it to WebAssembly, that code can now run in any browser on any platform at near native speeds. Like it’s very close to the format that JavaScript uses from getting from like native to getting to native instructions. Like it’s almost there. So it’s very, very fast. It has very deterministic performance originally with WebAssembly the focus was on like C and C plus plus fairly low level languages and turning that into WebAssembly.

Daniel Roth 00:15:50 And there are tool chains that let you take your, you know, your native libraries, turn them into WebAssembly and now run them on the web. And people have built all sorts of really cool applications you’re doing just that like AutoCAD is, uh, you know, it’s like 3d rendering software for like industrial design. They took their core rendering engine and it was written in native code and they compiled it to WebAssembly and built AutoCAD web. So you can like do AutoCAD on a, in a browser, which is just mind blowing. So what we did is we took Danette and we said, well, Donna had has a runtime. That’s the piece that actually executes your dotnet code on the device. That’s written in NATO code. Let’s turn that into a web assembly. And then if you can download that with your app, you now have a way to run normal dotnet code like normal dotnet assemblies, this isn’t code translation.

Daniel Roth 00:16:39 We’re not taking your C sharp and turning it into JavaScript. You just take a normal DLL and you download it in the browser with this WebAssembly implementation of a dotnet runtime and execute dotnet code directly in the browser using that runtime. So that’s, that’s how we use web assembly with blazer. That’s not the only way blazer apps can run. We call that blazer. WebAssembly the other way they can run is used over a web socket. So we call this model blazer server and blazer server. You take your code and you keep it actually still on the server. So your blazer components and your logic are still on the server, but it sets up a real time connection with the browser. And then the UI events that happen in the browser. We have a little bit of infrastructure JavaScript that pumps those to the server. They get dispatched to your components, your components run, they render and then blazer figures out exactly which parts of the Dom needs to change.

Daniel Roth 00:17:34 And it serializes, those changes back down to the browser and applies them. So in that model, you’re kind of treating the browser almost like a thin client, like a, almost like a, like a terminal pumping all the UI events, the server, and sending down UI updates on that real time channel. Laser can operate in either way, you can do blazers. So we’ll call that plays or server, or you can do blazer WebAssembly regardless. You still write your code the same, like the way you write your UI components doesn’t change. And you can actually decide which way do you want to host them. Do you want to host to this component on the server and run it over a web socket? No problem. If you want to run it client side in the browser on top of WebAssembly, you can do that too. So both models are supported.

Priyanka Raghavan 00:18:14 Okay, interesting. So I was reading about this thing called signal art for the UI updates. Is this what you’re referencing?

Daniel Roth 00:18:22 Yeah. The way we manage that web socket connection in a blazer server app is using the signal. Our framework signal R is a real time web framework for doing two way communication with, uh, with a client app, including with, with browsers in a browser, it will use typically a web socket underneath the covers. And it just gives you a really convenient framework API for sending messages back and forth across that web socket, we use signal are in blazer server in order to handle all the UI events being sent to the server and all the UI updates being pushed back from the server. You can use signal are though independently of blazer. Like if you just want to push stock ticker updates or have like a real-time chat app, those are, those are scenarios where you would use signal are. And one of the really fun scenario is this, the pair of signal are also with the laser WebAssembly in that set up.

Daniel Roth 00:19:17 You can now use signal client in the browser. Historically you would have to use signal RS, JavaScript client in for your browser, part of the logic and on the server, you would have signal code for setting up the hub and dealing with messages and so forth. So you had to bridge JavaScript to use signal arm with a browser in the past, but we plays a WebAssembly. You can just on both sides and you can do an entire real-time application just using C-sharp. We have a really nice sample on the site that shows how to do that.

Priyanka Raghavan 00:19:49 This is great. A lot to take in. So I have to ask you about, see also reusability, you did sort of touch upon this, but just to reiterate, like, how does it work with the existing dotnet frameworks and how do you deal with code sharing and library sharing in pleaser? Yes.

Daniel Roth 00:20:06 Yeah. Yeah. That’s the beautiful thing. And particularly with the most recent release of dotnet and dotnet five, the laser apps can use any library that leverages any of the dotnet five surface area. So you take normal dotnet five assemblies, and you can just reference them from your blazer apps and they, and they just work. So this is really convenient for code sharing. You can have a, like a shared class library that you reference from both your server project and from your client project, you can put like model types in there, validation, logic, anything you don’t want to write twice. And it’s literally the same assembly that you’re using on both sides of the wire. The one restriction there that I would call out is that when you’re running a blazer WebAssembly app, you need to remember that that code is running in the normal browser security sandbox, the same security sandbox that JavaScript runs in.

Daniel Roth 00:20:56 So you can do anything that JavaScript can do, but you can’t do any more. You don’t get any special doors to access the underlying machine. You can’t go mess around with the file system. Those browsers won’t let you do that. You can’t open arbitrary network connections cause browsers won’t let you do that. So if you try to use an API in a blazer web assembly app that isn’t supported within that browser security sandbox, you will get a platform not supported exception. And we do have a tooling analyzers that will look at your code and even inspect the API APIs that your code is using and let you know and say like, oh, Hey, by the way, you’re trying to do like a console read line from a browser. That’s not a thing you can’t do that. Maybe you should try something else when you’re running on web assembly. And you can add then like, uh, conditionals and checks to say, when running on web assembly, I want to do something different here.

Priyanka Raghavan 00:21:44 Okay. I like the way the conversation is going, because I feel like you’re, you are able to read what I’m going to ask next. You’re like a clairvoyant or something. Cause I can see, because I wanted to ask you about the tooling that you would require to say. For example, I find this debugging in modern browsers, like something which is not very trivial. I like all the advantages of a high level language, but when something goes wrong, you know, I often find it, there is a difficulty to try to find out what is happening under the hood. So are there any specific, special tools, like the ones that you mentioned right now to find out, for example, dependencies or like, you know, dependency, graphs, et cetera. So

Daniel Roth 00:22:24 With blazer and your debugging experience is going to be based on the normal Danette debugger, especially if you’re doing a blazer server application because your blazer server code is running on the same runtime. And then in the same process that all of your or core web code is running in the interesting bit is when you’re running on web assembly, if you have your code running in the browser on a, on a WebAssembly based runtime, like how do you debug that code when it’s in the browser? Like normally when you’re debugging code in the browser while you’re debunking JavaScript. So you’ll like F 12 and, you know, use the browser dev tools to look at that script code. But browser dev tools don’t know anything about and C sharp. So we provide a tooling experience for debugging your dotnet code on WebAssembly, where we created a, like the bucking proxy that can sit between the browser dev tools and the browser.

Daniel Roth 00:23:16 And we just use the normal JavaScript debugging protocol, but we augmented with Donnette specific concepts. So you can actually like go into the browser dev tools and there’s a special gesture you do first just to set it up, but once you’ve done it, you can then debug your C sharp code using the browser dev tools from within the browser. Like, you’ll see, you’ll see sharp. You can hit break points. You can step through it. The same experience is also available from visual studio. Like if you F five of blazer WebAssembly app, it will feel like a normal dotnet debugging experience. Like you’ll hit break points, you’ll be able to see vocals and all that stuff, but it’s doing some pretty fancy magic to make that work. It’s talking to the browser through this above proxy, and it’s actually using the JavaScript debugging protocol in order to do that.

Daniel Roth 00:23:58 So we try to give you the normal done it to bugging experience. When you’re trying to bug your code, you mentioned dependencies. So in the, with dependencies in blazer, on and on in general, you’re, you’re dealing with assemblies, you’re dealing with new gift packages. So tools that you can use, there are visual studio will give you, uh, a great view of all the packages that your app is referencing. You can look at the entire graph, see which libraries you’re pulling in typically with a dotnet project, that graph isn’t quite as extensive as you might expect with like a JavaScript app. NPM packages tend to be much more finer grained, and you tend to get a lot more of them with dotnet because the platform provides so much. You tend to have a smaller set of assembly libraries that you’re looking at, but still, if you’re running a big app, that list can get significant. And there’s nice tools in middle studio to help you look at that
Speaker 1 00:24:47 At O’Reilly we know your tech teams need quick answers to their most urgent questions. They need to stay on top of new tech developments. They need a safe place to learn the technologies, your company adopts, and they need it all 24 7. Well, they can get it all at O’Reilly dot com with O’Reilly online learning, your team gets live online courses, tons of resources, safe, interactive scenarios, and sandboxes and fast answers to their most pressing questions, visit O’Reilly dot com and request a demo

Priyanka Raghavan 00:25:18 For the development. So I was on vs code. And then of course you’ve also got visual studio. Is there any other ideas that you recommend?

Daniel Roth 00:25:27 So we also have visual studio for Mac that’s like the visual studio equivalent on a Mac. It has like a, you know, a graphical, uh, gooey based IDE with, you know, full debugging experience and so forth. So that’s another option. Those are the ones that we provide blazer. And Don though, isn’t really tied to any particular editor. There are other third party IDs and tools out there that you can use feel free to use. Whatever makes you happy. If you like coding and VIM, you can code your plays or rap in them. If you like using Emacs, or if you like using sublime, like those are all totally fine. We try really hard to make sure the core development experience has a great CLI a great command line interface. So you should be able to do everything that you need to do with just the dotnet SDK CLI and whatever text editor you want to use. But I think you’ll like visual studio. If you give it a try. I mean, visual studio code is free and visual studio has a free edition on the community edition on windows. So those are really great options. If you’re looking for a tool to build your tonic code with,

Priyanka Raghavan 00:26:27 Okay. Also I installed vs code and it was pretty easy to use. And the other thing I noticed was also, they had this remote code development. So I was going to ask you, um, I didn’t really like peek into it, but would it be possible for someone to run a Docker container with laser in it and then to remote debugging?

Daniel Roth 00:26:47 Yeah, we’re working on, especially for blazer. WebAssembly, that’s very interesting scenario to work out with Docker. So we do absolutely support running dotnet code in a, in a Docker container, in a remote process. And we can set up the, remote debugging end points in that process so that we can do remote debugging from the host machine. So that it’s already a thing. The thing that we’re building now as well, if you want it to bug your blazer WebAssembly app, the thing that’s in the Docker container is probably just like a server that’s hosting your blazer web assembly app. And then the blazer WebAssembly app is going to get downloaded to your browser. And that browser is actually back on your host machine. Okay. And now I want to debug the WebAssembly code that came from the Docker container, but it’s back on my host machine.

Daniel Roth 00:27:33 How do I do that? And so setting up the D R blazer WebAssembly debug proxy, so that it’s correctly pointing at that browser and biting that code as something that we’re enabling right now, it should be available with Dianetics, which we’re shipping later this year. And I think some of the tooling is, has started to make its way into visual studio code. I’ll have to check to see if it’s already shipped there, but I believe it, I know that dev worked for it was, was being checked in earlier this month, the web assembly story, there’s a bit of a, still a work in progress, but it should be coming soon.

Priyanka Raghavan 00:28:03 So I guess probably now we could switch into some of the other areas like performance and securities. So you did all agree, mention that pleaser is faster than a lot of the other technologies out there, like for example, node. But if I were to ask you a specific scenario, I was just thinking about this, like, suppose your app is hosted on C in the U S and you have a user like me, who’s in India. And can you talk us a little bit about the latency? How would you handle user interactions?

Daniel Roth 00:28:32 Yeah, sure. One clarification is blazer and note aren’t really comparable. We know it is a, like a server stack. You would probably compare node to like core in world or thing. That’s your server, that’s handling requests. core is just blazingly fast. And I think you’ll find that it performs very well when compared to node the laser is just a UI framework. Like it’s a UI component model that you can then host in on the web. So when you’re talking about Blaser performance, you probably more interested in things like, well, how fast does my app load in the browser? Like, how big is it? How much, how long does it take to download this blazer app and get it running once it’s running? How fast do my components execute and, and render pixels to the screen and how fast can I do like CPU intensive workloads?

Daniel Roth 00:29:22 So for download size, laser server is very lightweight to download because most of your code is staying on the server. You’re only downloading just enough JavaScript to set up the signal arc connection back to the server. So those load very, very fast, very lightweight to get going, and they support server-side pre rendering of the app out of the box. What does that mean? Well, instead of waiting for the signal, our connection to be set up and to get the first batch of rendering Dom updates from the server, a blazer server app can actually just go ahead and run your components for that first request. Like when the H milk, when the HTML is initially requested, it can just say, I can just give you that HTML right now, because all the components are here. I’ll just run them right away, give you the HTML. And then now you’ve got that.

Daniel Roth 00:30:08 We’ll set up the signal, our connection in the background to set up interactivity. So they load almost instantaneously. Laser WebAssembly apps are larger because you’re having to bring a WebAssembly net runtime with your app default blazer WebAssembly app, when it’s published and been trimmed down. Like we have a trimming where we will link out all of the unused dotnet code. And then we can, we do a pre compression also of the application when you’ve done the full publishing of a laser web assembly. It’s about two, two mags, total. That includes everything like boots that bootstrap is in there that runtime your libraries on your application itself. That’s a little bit, if you’re like a JavaScript dev, you might be like, ah, I can Trecia my, my JavaScript have to like kilobytes and yeah, that’s, that’s true. You, if you’re really care about every kilobyte of data that you’re downloading plays, or WebAssembly might not be the best option for you.

Daniel Roth 00:31:06 But when we talked to a lot of customers, they’re like, you know, I, as soon as I download my first image, like I’m already on a megabyte or after I’ve done any significant amount of development with my angular app or whatever, and the more I’m in the megabyte range as well, often I’m running line of business apps with a great network connection. So this is, this is perfectly fine. That size doesn’t bother me at all. But if you, if you were very sensitive to size plays or WebAssembly, it might not be your best choice. That’s the load time story. Laser web assembly will be a little bit bigger. We do also support pre rendering with blazer WebAssembly. So you can do a trick where you render the components on the server first and then show the pixels, and then we’ll download the WebAssembly runtime and all the bits in the background.

Daniel Roth 00:31:44 And that can help with the perceived low time performance for the actual runtime execution of the app. When your components are running, Glazer does a very clever Dom diffing algorithm to figure out what did your components just change and how much do I actually need to change in the live Dom? And so that’s how it blazer keeps the rendering performance fast. It’s doing it very minimal updates to the Dom by keeping track of what was rendered previously and what was just rendered and figuring out the diff. So it’s pretty clever when it comes to UI rendering, when you’re trying to execute just like CPU intensive code, like let’s say you were trying to, I don’t know, write a Ray tracer or do some crunch over it. Just a ton of data. You want to do that in the browser right now with blazer WebAssembly that’s not going to be particularly fast.

Daniel Roth 00:32:33 And the reason is that the runtime that we built in WebAssembly is a dotnet aisle interpreter. There’s no jet like normally when you code will on the fly, compile that code into native instructions, which gives you great performance in WebAssembly. There’s not really a way to do that yet. So we’re just interpreting your code. That means it will run significantly slower than you would expect. Dotnet code to normally run and will often run slower than JavaScript code as well. JavaScript is actually quite fast. A lot of work has been done to optimize Java script. So if you’re doing really CPU intensive stuff plays, or WebAssembly might be problematic, you might want to offload that work back to the server, like behind an API call, or maybe even use some JavaScript interrupts to speed up those code paths that said we’ve been doing a lot of work to speed it up in dotnet five, which we just shipped in November, laser WebAssembly.

Daniel Roth 00:33:27 We’ve got like a two to three times per boost over what we had originally shipped with the first release of blazer web assembly in may of 2019. So quite a bit faster. And dotnet five in dotted, six we’re expecting even more significant perf performance improvements in the island interpreter. And then we’re also going to add ahead of time compilation support. That’s the ability to take your dotnet code and just turn it all into WebAssembly. So there’s no dotnet interpretation that needs to happen. It’ll just run as web assembly in the browser, and that will get you back almost all of the performance that you would expect from a dotnet runtime, even though those there’s no jet, that’s something that we’re working on for dotnet six, and we should have previews of WebAssembly AOT ahead of time compilation in the next few months. And then one of the next stop at six preview updates.

Priyanka Raghavan 00:34:18 I’m switching gears to maybe security right now. How does Liza and things like identity and access management?

Daniel Roth 00:34:25 Yeah, so blazer has built in support for authentication and for authorization you can use, we have a built an identity solution in core that we call core identity, where you can store a username and password securely and manage user profiles and, you know, whole identity suite. So you can use that with blazer and do normal authentication when you’re running laser web assembly in the browser, you know, you’re operating as a client app and we support open ID connect based authentication flows from a blazer WebAssembly app. Do you want to do that with like our Azure hosted identity solutions, like Azure active directory, you can, you can use those that we have built in templates for handling that. And then we provide a whole bunch of components for handling authorization, like page based authorization components for showing particular parts of the UI when the user is authorized and when they’re not. And then on the backend, you’re protecting everything using a core standard set of security features. So we actually have a out of the box security story for pretty much all of your authentication and authorization needs.

Priyanka Raghavan 00:35:29 Okay, perfect. So one of the big attacks vectors for UI is a cross site scripting vulnerability. So is there any specific support that you provide for extra setbacks?

Daniel Roth 00:35:44 Yeah, so we do the, when we rendering HTML from anything that you do in razor, like razors, how we typically are going to generate HTML in a dotnet web application, blazer included when you’re rendering HTML, we’re very careful to H fill and code everything so that you’re not accidentally injecting, you know, scripts and other unexpected markup into your pages. There are of course ways to just generate HTML and the RA, but they’re highly discouraged. And when you do that, you got you, that’s when you gotta be careful that you’re sanitizing all of your user inputs and that you’re not accidentally putting some malicious code into your page, but by default, we follow all the standard security practices for mitigating cross site scripting, including H and coding content as it gets rendered at the page.

Priyanka Raghavan 00:36:26 Okay. Okay. Great. Like even in terms of tooling with the IDs, do you have any support, like as your code that tells you, Hey, you’re doing something wrong? Is there any sort of support that way?

Daniel Roth 00:36:37 I don’t, nothing comes to mind in terms of like visual studio tooling, because most of it, I believe is handled at the framework layer. When you render your component, you’ll write HTML markup, and you’ll you go, you can have C-sharp logic in there to say, you know, here I’d like to render the user’s username or here I’d like to render this particular field. And you do that by interfacing with your C-sharp code. And it’s at those points that the framework will just handle making sure that that code is HTML encoded the sanitization you’re already protected from that, in that case, it doesn’t mean you shouldn’t still sanitize all the user inputs. You absolutely should. Just in case, you know, they, they managed to make it into someplace that the framework isn’t protecting you from by the fault, but from the most common, like cross-site scripting issues, the framework will, we’ll just help you out there without any having to really do anything.

Priyanka Raghavan 00:37:24 Okay. So I’d now like to move into a little bit more on the community and support for laser. Before I go into that, I was chatting with a lot of friends before coming for this interview. And, uh, I have some silver light developer friends who asked me what the, what the future for blazer was because they were working on it and then Microsoft just shut it down. So they were like, ask that.

Daniel Roth 00:37:50 Yeah, yeah. We get that question a lot on the blazer too. I mean, it kind of looks a little silver light ish, right? Like it’s in the browser, silver lights kind of did that, but I would say there’s really significant differences between what we’re doing with laser and what we’ve had done with Silverlight they’re really completely different. So the first thing is that, like I said, blazer is based just on open web technologies. There’s nothing proprietary about it. There’s no plugin that you need in order to get a blazer app to run. Whereas with Silverlight, there was like, you needed a very specific Microsoft provided plugin to get your silver light app to work. So that was problematic with Silverlight, right? Like not only was the plugin proprietary, but as the application platforms evolved plugins less and less viable, like if you wanted to run an a, on a phone while there was no plug in there, so now you can’t even, you can’t run yourself a light up on in that environment.

Daniel Roth 00:38:43 What blazer you don’t have that issue. Like everything in blazer is, is open web tech. It’s also open source. So the code is there for anyone to see and use people really. I think some people would still really like us to open source of light. I don’t think we ever did. And so that means you’re kind of stuck through it with several lines. Although there is an option that, that that’s worth mentioning that there’s a open source effort where they they’ve taken the same runtime that we use for, for blazer. WebAssembly the same WebAssembly runs on. We built there’s a community effort called open silver to rebuild Silverlight on top of that, of that runtime. So if you’re a Silverlight dev, you might want to go check out open silver, and maybe that’s something that might be interesting to you. It’s, it’s basically using the same blazer tech underneath the covers, which is pretty cool blazers, not, it doesn’t require any plugins.

Daniel Roth 00:39:29 It’s just the web and the web has, has staying power, right? Like the web web’s not going, going away. I would also in terms of commitment, I would point to the things that we’re wanting to do with laser. We actually have, we’re investing more in blazer and not, not less. We have some pretty exciting stuff planned for, for dotnet six. I’m happy to go through and on, like I said, the code is also open source. So even if Microsoft were to decide at some point that they don’t want to do this laser thing anymore, well, anyone can take the blazer code and run with it, build it. It’s a open source project part of the dotnet foundation. So it has that safety net as well.

Priyanka Raghavan 00:40:06 So the future is C4.

Daniel Roth 00:40:09 I think. So, I mean, software is, is a, is a fickle space, right? Things, things do change, and we all know that right. Today’s show. Have you ever worked in the JavaScript world? Like today’s hot technology is, comes yesterday. It goes out in the trash. I think within that, we tried to build technologies that are gonna last for a long time. I think plays has got a bright future.

Priyanka Raghavan 00:40:28 Can you talk a little bit about the community support for blazer as it’s open source and free? What are the kinds of contributions you see? And in terms of numbers, I think I saw somewhere a hundred thousand contribution, always his contributions on the site. I don’t know if it’s for the or pleaser.

Daniel Roth 00:40:45 Yeah. That’s that’s for all of Donna, like, cause all I’ve done that is open source now. And it’s Donna is actually one of the fastest high velocity open source projects on GitHub. It has a very active community. So we get community contributions across the stack in blazer. Yes. But in AceNet core and in the Don at runtime itself, we get tons of great community contributions to help make the product better. I was just talking to one of my engineers earlier this week where one of our community members I think was Ben Adams had done some work on the JavaScript framework files that come with a blazer app that the pieces that make plays or work and had done some web pack magic to shrink down the size of those files by another like 30% or something amazing. And that was just done from the community. So it was, it was great that anyone in the community can go [email protected] code all the way down to the CLR runtime itself. Look at it, build it, submit, pull requests, contributions. We get a lot of community help just from people trying out our previews and submitting issues. Just letting us know about features and giving feedback with bug bug reports and feature requests. So yeah, we’re really excited with the way that open source has evolved.

Priyanka Raghavan 00:41:57 So do you also have like communities where you’re standardizing wage to do things and coding standards and things like that? Do you have to have that kind of what you see as special interest groups for these things like that?

Daniel Roth 00:42:10 I’m sure there are, like, we try to facilitate the Don and open source ecosystem through the dotnet foundation, which is an independent organization. That’s job is just to make Don and open source. Great. It’s very similar to foundations and other other communities. So they’ll do things like help sponsor local meetups, like local dotnet user groups that get together and talk and get up to date on the latest features and talk about problems that they’re having with building dotnet apps and so forth. We help lives in the pandemic era. It’s hard for those groups to get together. So we, we help them live stream their content so that people can from all over the world, honestly can, can join those user groups and see what people are talking about and learn together. They help open source projects with infrastructure concerns for building their dotnet projects, getting them appropriately signed and doing all the appropriate build infrastructure for getting their apps going.

Daniel Roth 00:43:01 And also just ensuring longevity of open source projects as owners we lose interest or, or become longer available to work on a particular, uh, projects, making sure that there’s someone else that can step in and that ownership continues. And those projects continue being managed and maintained for like specialty groups. I know I’m trying to think if there’s any specific groups and when we, we have, we have a great friendly regular conference now called dotnet comp for,, which happens on almost a monthly basis. Now it was used to be a yearly event, sort of like as a conference, where we would talk about all the new features coming in the next versions of, But now they started doing these focused dotnet con some very specific topics like in February. I think we’re doing one on a windows development, specifically like windows, desktop development. We’ve done Donna comps focused on blazer in the past and mobile developments in the variety of other topics, microservices. And those are all again, free live-streamed people ask questions on Twitter and get answers. There’s lots of community talks that are given in those conferences. So that’s another forum where the dominant community gets together, learns talks about their issues and gains expertise.

Priyanka Raghavan 00:44:17 Okay. Okay. So are there any good resources that you would like listeners to look up after this podcast for Liza that I should mention it. I mentioned it in the show notes, but it would be good if you could point out.

Daniel Roth 00:44:32 Yeah, definitely go to That’s the blades or homepage and that’s where you can get started and find the links to the documentation. You’ll be able to build your first place or app, hopefully in just a few short minutes, other good resources that I would recommend. We have, we do have a online blazer workshop that you can work your way through a self-paced workshop. That’s at AKA Ms. Slash plays our workshop. You’ll build like a whole pizza store application using using Glaser So that’s a really great way to ramp up your laser skills on the Donnette website. There’s lots of other good resources as well. You might want to check out the Don at live TV page, which has all sorts of people live streaming, various content about dotnet not just blazer, but for, uh, technologies, uh, across the stack. That’s another great place.

Daniel Roth 00:45:18 If you prefer watching video stream, instead of reading, I would also keep a watch on that blog. Actually. That’s another great place. When we, when we announced new releases, those all come through our dotnet bot blog on the, on the Microsoft dev blocks. We just recently announced the first preview of dotnet six. And we’re hard at work on the dotnet six release, including a bunch of new stuff for blazer, things that are coming. Just to give you a tease. We’re working on support for hot reload, for a blazer so that we can update your running blazer application with code changes while it’s running, without having to restart the app or even refresh the browser. So you get a very fast and fluid dev development experience. So hot reloads on the slate. I already mentioned WebAssembly ahead of time compilation, that’s coming to blazer web assembly and dotnet six.

Daniel Roth 00:46:08 So your laser WebAssembly apps will be significantly faster. We’re starting to now expand blazer beyond the web and take it into the world of native application development. Often, if you’re a web developer, the web is great and the web platform does everything you need it to do. Except when it doesn’t like, if you need to actually access some native device functionality, you might need to move beyond just what the web platform offers, but maybe you still want to leverage your web development skills and your blazer code and your blazer skills. We’re going to enable blazer hybrid app development. And dotnet six where you can take your blazer code embedded in like a native desktop app or a native mobile app where use your existing blazer components use HTML UCSFs to define your UI, but your components run natively on the machine. So they have access to all the native capabilities of the device through normal dotnet API APIs and running on a, you know, a runtime. So it’s just, it it’s fast something that’s also coming in the dotnet six timeframe. It will be based on the new dotnet multi-platform app UI story, which has a new way coming in, done at six to build cross-platform user interfaces across mobile and desktop windows, Mac, Android iOS, the blazer hybrid story is being built on top of that. Dotnet multi-platform app UI infrastructure, which is also coming in done in six.

Priyanka Raghavan 00:47:36 Okay. That’s probably one of the things I forgot to ask. So that’s good that you mentioned that here. Okay. This is great. Where can listeners find you Daniel or would it be on Twitter or LinkedIn?

Daniel Roth 00:47:48 I’m on Twitter. I’m on GitHub. This is a Dan Roth, 27 on the 27th. Dan Roth don’t know why it was just the number that was available. Feel free to find me either on Twitter, on get hub down off 27.

Priyanka Raghavan 00:48:01 Thank you so much for coming to the show. I really enjoyed the conversation. I hope you did too.

Daniel Roth 00:48:06 Thank you so much. It was great talking to you. Okay.

Priyanka Raghavan 00:48:09 This is Priyanka Raghavan for software engineering radio.
Outro 00:48:14 Thanks for listening to se radio an educational program brought to you by either police software magazine or more about the podcast, including other episodes, visit our [email protected]. To provide feedback. You can comment on each episode on the website or reach us on LinkedIn, Facebook, Twitter, or through our slack [email protected]. You can also email [email protected], this and all other episodes of se radio is licensed under creative commons license 2.5. Thanks for listening.

[End of Audio]

SE Radio theme: “Broken Reality” by Kevin MacLeod ( — Licensed under Creative Commons: By Attribution 3.0)

Join the discussion

More from this show