 Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green and this episode is part one of what winds up being a two-parter on Blazor which is an experimental technology that could revolutionize the web development world. I had Sam Bazoo and Ed Charbonneau here a few weeks back. They were here for the Visual Studio Live Conference which was on Microsoft campus. I taped a bunch of episodes with them and they wanted to do an episode on Blazor. Unfortunately, I had a conflict and Dimitri wasn't available. So I left them alone in the studio. They were so excited they spoke for an hour so we're going to cut that in half. This is the first half of them explaining to us what Blazor is. Hello and welcome to VS Toolbox Show. My name is Sam Bazoo. Robert Green is busy so I'm filling in for the day. And with me I have Ed Charbonneau and we can talk about something very exciting especially in the ASP.NET land with Blazor and WebAssembly, right? Yep, so I'm a huge fan of Blazor right now. It's an experiment that's being worked on by the ASP.NET team, Daniel Roth and Steve Sanderson. They're working hard experimenting with this new framework. So I'm happy to have the opportunity to come on Visual Studio Toolbox and kind of share that story with everyone. Awesome, tell us more about. So my name's Ed Charbonneau. I'm a developer advocate with progress or you may know them as Tellerik. Sam here is a developer advocate at Progress as well, co-worker of mine and we've kind of invaded the Visual Studio Toolbox episode here to talk about Blazor. So I am an author, I do some writing. I have a podcast called Eat Sleep Code. And if anybody ever wants to reach out and get in touch just give me a shout at on Twitter. Okay, all right, so let's dive in. What's the hoopla? Sounds like there's some very sharp minds behind this at Microsoft and other places. Tell us more. So as a web developer that specializes in C-Sharp, one thing that I've always wanted to have is the ability to write C-Sharp and create client-side applications using it. Okay, so to kind of back up, so with ASP.NET, is it entirely server-side? We can do some things client-side, right? But it's all in JavaScript. Right now, if you want to write an application that's running in the browser, you're gonna have to leverage JavaScript. But there's some new things that have come around with web assembly, which is a way of natively writing code for your browser that it understands using web standards. It's a byte code format. So it's similar to an assembly language, but it runs natively inside the browser and the browser understands it. So we're starting to step away from the days where JavaScript rules the browser only and we're allowing some new things into the ecosystem. Okay, so from what I understand, like every browser has a JavaScript engine, right, V8 or Chakra or WebKit, and it's these engines that run JavaScript natively in the browser client-side. So now we're saying there is something more that the browser can run, and that's the web standard that you talked about. Yeah, and I want to point out this is a web standard because we've tried some things like this before. And well, things have changed. Things have changed. So maybe to back up, so I'm actually a big fan of Silverlight back from the days. Flash was a plug-in and sure it had some vulnerabilities. I think Steve Jobs kind of wrote a scathing letter one time to say, so essentially when you run Flash on Safari, it makes your tiny iPad heat up and that's not something Steve liked. So he essentially kind of killed the plug-ins model and along with it like we never said Silverlight is done, but we just kind of stopped talking about it and maybe the plug-ins model just didn't scale for the web. So now we're saying we're not going to do plug-ins. This is different. No, no plug-ins. And don't get me wrong, these were things that were necessary at the time and people were doing with the best tools that they could to build amazing applications. I'm sure there's some just phenomenal Silverlight applications out there that people have built, but now's the time to start moving on to something else. We're going to drop all those plugins and just use things that the browser understands natively. Yeah, with Silverlight though, I mean, it wasn't just the plug-ins model. Like people who did Silverlight, we just enjoyed the dev experience, the rich ecosystem, the data binding with C-Sharp and Xamarin and I think as developers, all of those skills, I mean, they move forward with be it UWP, be it WPF or Xamarin Forms. So you can build cross-platform apps with the same skill sets. Absolutely. We're just trying to see how we can bring that dev module back the ease of using Visual Studio and C-Sharp, but do it differently in the browser, right? So how so? So let's start off with no web assembly. How does the browser work without it? So normally we feed the browser HTML and JavaScript pages, those things go through a parsing and then they're kind of pre-compiled. They're turned into a JavaScript tree and the JavaScript engine inside the browser interprets that into a bytecode. So it gets jit-compiled, turns into bytecode and then things happen within the browser. So that's kind of where web assembly happens. What they've done is think of this kind of like, for lack of a better term, a dependency inversion of control, right? So we have this part of our browser that understands this bytecode. What if we took that part of the browser and exposed that to where developers could target it? So this is web assembly. So we can target this bytecode now and give that to our browser and our browser understands how to execute that bytecode. So when we do that, we open up that input to things like C++, Rust, Go, and our favorite C-Sharp. Okay, so now you're talking about like higher level programming languages and able to write things that we're gonna compile down. Maybe not compile as maybe not the right word, but bring it down to that low level assembly ish code which the browser can execute on its own. Yeah, and there's one more clarification to make here. This isn't bytecode that would run on your machine. So this isn't something that's gonna get loose and have security issues and, for example, a library that you send down isn't gonna be able to access your system registry or run natively on your Windows desktop. Okay, so it is still running in the browser shells, so to speak. It's very much sandboxed. And the bytecode is only gonna be understood by the browser. It's not something that's used outside of the web. So why should I trust web assembly? Is this like a standard that the web community has accepted? Absolutely, so this is a web standard. It's in all the evergreen browsers. And then also if you have another browser that's say maybe on a mobile device, there's some manufacturers that like to ship their own web browsers and those don't always have standards that are up to what we expect. There are polyfills that can polyfill in web assembly. So it will be compatible with those as well. All right, so you mentioned like modern browsers. So is that like Edge, Safari, Chrome, all of their latest bits will support web assembly? Yeah, so when we say something like an evergreen browser, that's one that doesn't have a hard version number that we're tracking. Auto updates. For example, like IE789 or Edge. You're always on the latest version. Okay, so Apple is on board with this. Okay, Edge, Safari, Chrome, those Firefox, the big ones that many of the users use, those are the ones that you would expect to have the native use of web assembly. And then the other ones, like I said, the polyfill works. There's a little bit of performance gap, obviously with that type of approach, but at least your app works. Okay, all right. So this is where Blazor enters the picture. Now there's a couple modes of how Blazor can run. One of those is very new. So we'll talk about that in just a little bit. But what I want to focus on right now is the experience where you're developing for the browser, the client. And you're running the application on the client. There is an opportunity to run it on the server and this diagram doesn't quite fit that model. So right now we're talking client side. Why Blazor, what's with the name? So the Blazor name came from Razor. So we're gonna use Razor to create our markup for our application. And then the Blazor part of it comes from the... Is running it in the browser? Yeah, in the browser. So browser, Razor, Blazor. I see, I see, okay. So like Razor is the syntax that we use to build ASP.NET applications, be it MVC or ASP.NET Core. You're saying we're gonna use the same syntax, but it's gonna just run client side in the browser. Yeah, so if we look at the diagram here, what happens is, remember that model we had before, we're gonna feed the browser HTML and JavaScript only. Now we're using the Blazor framework. And the Blazor framework, it renders those C-sharp, or sorry, the Razor CS HTML files. Those get turned into HTML, which the browser understands. Then we take Mono. So Mono, the runtime that can target multiple platforms, they're now targeting the browser. Okay, so this is Mono under the covers. And Mono, as we know, that's not a new thing. I mean, Mono's been around since .NET has been around. So it's the port of .NET to other platforms. And that's how Xamarin apps run today on iOS, Android and other platforms. You're saying we will use Mono to bring your C-sharp down to WebAssembly? Yes, so Mono is compiled to run on WebAssembly. And then Blazor is a framework that sits on top of that. Now Blazor is able to take and load your DLLs directly into Mono. And Mono is running those in an interpreter into the browser. Okay, so it is being interpreted at runtime now, but eventually you might have a little more static compilation, make things a little more faster. So right now, this is the way it's happening. There are, I've spoke with Daniel Roth and there are ideas around maybe collapsing the stack at a final compilation stage where all of your application gets compiled into WebAssembly directly. So when it loads into the browser, it's at native speeds and there's nothing inhibiting that direct pipeline into the browser. Now, the way this works now, this is a great development experience because when we compile, we're compiling it to DLLs and then Mono is handling that WebAssembly interpretation for us. So the compilation time is very short. If we were to take our entire application and compile it, that compilation time would take quite a bit of time and our development process would be slow. So this is a very fast way to iterate on an application and build it and then in the future we may have that longer compilation to get the final package tightened up and ready to send down to our users. Okay, now I see blazer.js and Mono.js, what are those? So those are kind of intermediate layers for the browser to help do things like JS interops. So we have a JavaScript interop layer. So there are things that WebAssembly doesn't support yet. So there might be times where we need to fall back on JavaScript. So we can actually talk to JavaScript from within WebAssembly. So from .NET code you're gonna call JavaScript and back and forth? Correct, so we can actually do that bidirectionally. We can call JavaScript modules and functions from within Blazer and then we can also from JavaScript invoke .NET functions. So that's one reason those two JavaScript files are there. The other part is just loading the application up. So the Mono.js takes and loads bootstraps up the Blazer assemblies and then Blazer has those interop layers and communicates down through Mono.js into those interops directly. So we've got a nice stack workflow here that we can build some pretty interesting applications already. Now it's worth saying that Blazer is an experimental project still. Sure, for now. We're in release 0.5.1 as of recording. The first 0.1 release was just in March. So it's only six months old. It's a baby. It's got a lot of growing to do. But I hear it's come a long way. It's come quite a long way. They are making some good investments in producing this experiment. And it's nice to have this experimental phase because they're able to think outside the box, do some creative experimentation with it and not have to worry so much about breaking changes at the moment. And the community gets to weigh in. We developers get to try it out and see what works and where the pain points are. So back on this diagram, this is all client side, right? This is absolutely all client side. And Blazer, it can run out of process. So we don't need to necessarily be tied to WebAssembly. We can do it on the server. And we'll get into a project. This is actually something that shipped in 0.5.1. This is very, very important. Where we can run the framework on the server side. So we don't have to compile it down and then send it into the mono WebAssembly runtime. We can use the regular .NET runtime on the server. And then what we're gonna do is open up a SignalR hub and communicate across the hub to your browser and do diffs between the browser and the updates that we need to send. We'll get into that more. We don't want to get too much going on at once. Let's lock in the client side first. So client side, we've got our Blazer framework running on top of mono. We're able to load DLLs directly into the browser. Which is something very new and unexpected that. Then it's curious. Yeah, we'll pull up the network traffic here and take a look and see what's happening. So what exactly are you shipping from the server side when you do Blazer apps? All of it. We're shipping DLLs down to the browser and the browser is able to understand how to run those DLLs thanks to the mono runtime. Okay. And hopefully we are doing some work with linkers and some tree shaking. So we are shipping only what we need on the client side. That is stuff that is in the works that's coming. Yes. So right now we're shipping down full assemblies. But soon we hope that Steve and his team will come up with a way to create smaller DLLs and ship those across the wire. Yeah. All right, let's see this. So before we get started, we'll talk a little bit about the Blazer framework itself. It has a lot of those things you expect out of a single page application framework or a spa framework. It has a virtual DOM. So DOM manipulation is a very taxing effort. So things like jQuery that directly go in and modify, manipulate the document object model in the browser, those things are sometimes pretty inefficient. So Blazer has its own shadow DOM similar to other spa frameworks like Angular and React. This almost sounds like a very spa client side framework with some of the features like routing and layouts and dependence injection. So we interact with this virtual DOM and then Blazer does diffing between the actual DOM and the virtual DOM. So it's only changing what it needs to change rather than repainting that entire DOM within the browser. Gotcha. So we have efficiency there. We have a component model. It's a very model view model type thing. This is something that developers from other .NET frameworks would appreciate. Things like UWP and WPF and Silverlight. It's not identical but it has some similar type of ceremony. This is what we liked about Silverlight development. This is the ease of doing data binding and XAML tools, the ecosystem. And if you're saying we can bring some of it back, then yeah, let's do it. We have some layout capabilities in there as well. Dependency injection on the box, something that we'd expect from a modern .NET framework. So we have that as well. We have routing that's very easy, follows that razor pages type of construct where we open up a page and have an at page attribute and we'll show some of that in a moment. And then again, the JavaScript interrupt is part of this as well. So we'll show that too. So let's jump straight into Visual Studio. Now I have some tooling that I have to install. If you wanna install this tooling, you go to blazer.net and just follow the step-by-step instructions there and you'll have the same tooling that I'm showing now. So in Visual Studio, I have a file new project experience for this and I am gonna click on the ASP.NET Core web application project template and we'll just do okay here to spin up a new project. And notice I have three new projects in here. I have a Blazer, Blazer, ASP.NET Core hosted and Blazer server side. So let's dig into these really quick. So before you do that, this has to be ASP.NET Core 2.1 release and forward? Yes. Okay. As of now, so as of recording, that's what it is. And Visual Studio 15.7 or eight. And those instructions again are on blazer.net. You'll find those there. They may be updated after this video airs. So make sure you keep an eye there but you do need to install these. You're not gonna come out of the box in your normal.net installation. So our first project, think of this Blazer app is a client side only template. So if you were to do this in say just normal JavaScript terms, it would be HTML, CSS, JavaScript. Static files you run on your client only, okay? So we're not talking about server interaction. You can still have server interactions but you do that through web APIs and things like that. They're not included in this project. Sure. The next one over is the Blazer ASP.NET Core hosted. I like to call this the full stack template. So this has the previous project template but it also includes ASP.NET Core and some web API endpoints that we can hit. So that's kind of like your backend then for your app. Yeah and ASP.NET is actually hosting the application as well. With the first example, you don't even really need a host. You just need somewhere to stick your files and it's just stuff the browser understands so it can pick it up and run it. Just like in HTML, JavaScript, CSS project, you could put it on GitHub, Pages and host it there. Any FTP server and just put it on and run. Exactly, Azure storage. You can host your application from using that format. The second one here though, this actually has ASP.NET Core hosting the application for you. It also has web API endpoint for you to be able to hit and it also has a concept of code sharing. Remember we're using the same language now on the browser client and the server. So that's interesting. So folks doing Node.js, we are used to doing like JavaScript front and back and now we can do C sharp front and back essentially, right? Absolutely. So that's where that one sits. This is a brand new project. So this is where I kind of talked about it a little bit earlier. This is a server side model. No web assembly involved where the Blazor framework sits on the server as an application and the server connects through web sockets down to the browser using SignalR. Okay. Those packets with SignalR are sent through a binary transfer. So it's actually taking the diff from your updates, your interactions and sending that up to the server. The server then processes the changes in Blazor and then Blazor knows the diffs to make, sends that down the wire in a binary packet and then the SignalR client picks it up and replaces what it needs to in the browser. Interesting. So it's a very interesting approach to doing this type of development. Yeah and if you talk about like server side now you're kind of in Node.js territory and you can kind of think about what this might mean for electron.js apps maybe that run on the desktop but we'll get to that but then this is interesting that we can actually host Blazor outside of the web browser's process and just do it all on the server or desktop. Yeah so it's kind of extending that UI thread across the wire instead of doing it right there in the browser on the client. So let's actually jump into this first Blazor template so we can actually show some code and how this stuff is structured. So I'm gonna spin this up, file a new project, look in our solution explorer, see what we get. Some of these things may seem very familiar out of the box because they follow conventions that we already use in ASP.NET development. In particular, this looks familiar if you do any razor pages so you don't have the model view controller pipeline you have pages, right? Absolutely. And that's where you render things from. So we'll start top down, we have our WW root. So this is just like you would find normally this is static resources for our application. We go into pages, like you said, razor pages, same idea here. We have all of the features of our application. People like to talk about apps and features now, like we wanna have our, in this case, our component feature and our fetch data feature and we can dive into those files here in just a moment. And then our shared libraries, our shared views. Same concept is ASP.NET, we have things like templates in our main layout and even we can even have a view imports file to do those global using statements and bring in component libraries and things like that. And another familiar concept is the startup and program.cs files that you find in .NET Core projects. Those are the things that bootstrap your application and configure dependency injection and all of those great things. So let's give this guy a run. We'll get this started and kick it off in the browser and then we'll go look at the code behind it and see how this works. So you're running this in IS Express but you just said it may not need any of that. We don't really need to do all that. We could host this on GitHub pages if we wanted to. These are all static files that we're using here. So we get our Hello World app. We have a couple features here. We have our counter component. We can click and increment a counter. You're not coming back to the server. So no, there is no server. We're not doing any data transfer across anything right now. We have a fetch data but it's all being handled locally. So we're just grabbing a JSON file and just pumping the data into the application. So we're grabbing that static JSON file. It's not coming from web service or anything at this point. So right now it kinda looks like an average application but let's see how it's built. So let's dive into some of the features here. Let's open the counter component or the counter page. You'll notice right away this is the razor syntax. It's a .cshtml file and it uses very familiar conventions. It does, yes. At the very top we have our router. So page is at the counter endpoint. So if we go to counter in our browser that's where we end up. And that routing is built in. Now routing is built into the framework. So now we have just simple HTML here. We have our header tag and then we have our current count and then we're using razor here to display a value of current count. Sure. We have a button to click and then we have a vent binding to the on click event. And then we have a function block here that has our functionality for this page. So there's our current count that's being bound up here. And we have our event handler for the increment. So when you say add functions, like that's C sharp, right? Yeah, this is razor and everything inside of this block is C sharp code. Yeah, yeah. So there's no JavaScript at all on this page. And when we click the button it invokes this increment count function and it's data bound to this current count value. So that's the view that we see here when we click this button. So we're able to do that with very little code. It's all, there's no post backs going to the server. It's all being handled locally on the client in a very easy to understand fashion. Okay. So if you go back to the browser for a second, so you said this is, it has a shadow DOM but there is a DOM out there. So if you right click, you will actually see HTML. Yeah, absolutely. So those C sharp or CSHTML files are being rendered out into the browser. So you'd see your bootstrap rows and your links and your buttons and all those good things. Let's actually jump over to our network tab while we're in here and just do something interesting. Let's do empty cache and reload. And when this comes down across the wire notice that we're actually sending DLL files from the server. Little scary. So, yeah, let's see. These all get loaded in through web assembly and our application spins up and it's all client side. Okay. So we're actually running these DLLs locally on the client. That's very interesting. You're literally shipping .NET DLLs to the browser. Absolutely. And letting it figure it out at runtime. And if you look at the sizes, this is where you're saying it'll get better. Like we'll ship smaller and smaller as we go. Yeah, yeah. Right now you can see that we're shipping the .NET standard DLL, MS Core Lib and all these things as a whole across the wire. I would imagine I'm not on the dev team just for clarification. But I've had discussions with Daniel Roth, the PM on the team and he's adamant about making these things smaller and more compact when they go across the wire. Sure. So let's jump back into code again. We'll take a quick look at the fetch data. This is the view that if we click fetch data here, we have a little bit of a grid showing some data that's coming in. The first thing I wanna point out again, we have routing and then underneath routing, we have this at inject declaration up here. So this is actually calling out to the dependency injection system and it's asking for the HTTP client that's registered in dependency injection. So that's gonna get resolved. And then down in the code of this page, you'll see we use that HTTP client to go to a file on local storage. Okay. So you're not going anywhere, it's just a JSON that you're loading. But you could go across the network if you wanted to. Absolutely. We could make requests to back end services and all those type of things. And we're doing it in a familiar.net way. We're using HTTP client and doing a get JSON async to pull in a object type of an array of weather forecasts. So there's JSON binding that's happening automatically in here. So we don't need to even worry about those type of things. And then there's our weather forecast object right there. So we're getting these values and just mapping those values from the JSON into this object. And then we iterate over those in the view. So at this point is this, would you say these are views or would you say these are components? So these are both actually. So we have the concept of a page here. We're using this at page directive with the routing. But I could actually come into my home or my index and let's wipe this component out for a moment. And I can come in here and type encounter. Notice the nice IntelliSense come up and we'll close that tag. And I'll come back to my browser and refresh. And let's go home and wait for it to refresh. We're getting a message. I'm actually in debug mode. So let's actually run this a different way. Let's do a control F5. So we'll run without debugging. So we can refresh this experience. Now remember this is an experimental project. So the debugging experience right now is a little lackluster. There's some work being done to make debugging available in the browser. We can actually at current state set break points. In C-sharp? In the browser we can set break points. We'll look at that in a few moments because I don't want to get too off track. So we'll be able, at some point we'll be able to debug C-sharp code in Chrome or IE. Wow, okay. At current state it's not quite there but it's getting there. So back to talking about the components. Do you have the counter? Taking that entire page, use it as a component. I see. So. And that's not something you were able to do at all in ASP.NET MVC or Core or Razer. That's correct. This is a new component. Literally a component. So this is kind of like in some ways like Angular and React. You're just literally plopping a component down into a page. Absolutely. Very similar concept to those things. You could say it was inspired by or borrowed from those which those things were inspired by and borrowed from things like WPF. Oh absolutely. We rediscovered the same problem so we're not over again. So let's have a little fun with the counter component that we have. We'll go back to this page here and let's set up a property. So we actually have a shortcut for this now in the tooling and we can say instead of prop tab tab which we might be used to to do this, we can say para parameter tab tab and now we get the parameter attribute and then we can expose a property on our component. So let's call this count by. So this is an integer that we'll set to be count by and instead of just incrementing this internally we can just say plus equals count by. We might want to set a default value here. This is what if somebody does not pass in the parameter. So we'll do that. I saved it. We'll go back to our index and now we can say count. I may have to recompile here. Let's do a build and now we can do count by. There we go. Now our IntelliSense comes up. We needed to build that library out. I can set that to an integer of five and we'll save this and we'll refresh our page. So if I'm getting this right, so these are individual components. So the actual counter should still increment by one but this one should pick up the parameter. Right, so the instance of the counter on my index page counts by five and the instance of the counter on the counter page is only counting by one. But now we've extended that component out and actually made it a little more robust where we can have like a developer experience where you can type in and get IntelliSense and set variables and properties on the object. This is the component. So a very simple component model to understand. It's absolutely simple to get up and running. So let's take a look at the other project type. So that's the first half of a full hour of Sam and Ed talking about Blazer in the next episode of Visual Studio Toolbox. We'll continue on with their conversation.