 button. Here we go. Good morning everybody and welcome to a new episode of the Visual Studio Office hours. My name is Matt Christensen and I'm coming to you live here from my garage in Redmond and today is very exciting because I'm a long term web developer and there is this new thing out there called Blazor for ASP.net and I haven't actually looked too much into it and I'm very curious as to what this thing is and there's no better person to explain this whole thing to me than Mr. Dan Roth himself from the Blazor team. Hello Dan, how are you doing? Hi everyone. Thanks for having me on the show Mads. It's great to be here. Yeah I'm the program manager for for Blazor at Microsoft on the ASP.net team. Alright and so yeah and you've been you've been on the ASP.net team for for quite a few years and been around the blog. You know you think about ASP.net I think. A little bit. I came came on to ASP.net I don't know like five or seven years ago. I actually don't remember exact the exact time frame anymore. It has been long enough that I forgot in the exact exact period but I started working on ASP.net. Web API actually was where I really really joined with ASP.net. I mean I guess technically if you go back far enough I actually worked on ASP.net web services like you remember the old like azamex style soap services. I worked on that so that technically had some some ASP.net code in there as well but for web UI that's more recent like I really started working on web UI with MVC4 and MVC5 on ASP.net. Okay I didn't know you did the old the ASM mix stuff so this was I don't know if the audience remember back in like 2000 Visual Studio 2005, 8 and all that sort of stuff we had you could right click your project and go say add service reference and you could point to an ASMx file which was kind of like a web forms but for that would generate soap APIs is that is that kind of how it was? It was it was for consuming consuming services right like you wanted to build an endpoint for your back end and you wanted to be able to easily consume it from you know whatever code a web app a desktop application. Yeah so the soap based services era I actually joined Microsoft right when WCF was being was being put together and developed as the mix was sort of one of the precursors or ASP.net web services was one of the precursors to WCF so I worked on that for a good long while mostly as focused on the back end right like back end services, back end server infrastructure. It's only more recently at my time in Microsoft that I've been working on front end web UI. Yeah you know I remember back then I built like phone app this is back when there was Windows this is before Windows phone it was called Windows Mobile and it was called Windows Pocket PC and the cool thing about that you know as well as WinForms this is before WPF and of course ASP.net and they were all able to talk soap in a very very easy way through look at service reference point to an endpoint that had an ASMx file which was a very simple and easy way to construct soap from like it really democratized the service oriented architecture I feel like back then and we never really got it back right. I don't know what happened but it kind of the world went into REST APIs and JSON and in the process we lost that you know maybe things that people really hate about soap which was the schemas and the weird authentication and security models and all this sort of stuff but but the ease of use and the ability from me to very easily create a SOA service oriented architecture kind of died and now it's very manual and it's very like you have to learn a lot of things it's not the tooling doesn't kind of just help you along in a very natural way. I don't know am I being nostalgic or did we lose something there Dan? What happened I think with soap was that soap as with the tooling involved you could generate code from these description language right like it wasn't actually the ASMx file you pointed Visual Studio at it was a web service description language file a wisdom file right that was a big chunk of XML that described all the endpoints on that service that was generated by the ASP.net web service or WCF service and then Visual Studio could generate a whole bunch of code based off of that description language that you could then use to send the actual soap messages and all the protocol details you didn't have to really worry about you just call it C-sharp code and mostly that that mostly that just worked with the move to web APIs I think the the desire there was to simplify really the the amount of machinery between you and actually sending that message I think there was a big reaction of why not just use HTTP as as you know timbersly intended it's you know supposed to be an application level protocol why do I need all this additional abstraction on top of that I'm just going to send an HTTP request with some some data in there and that's probably good enough and for a lot of scenarios that does actually simplify things a lot because soap required a fairly thick toolchain to make it productive if you had Visual Studio then it was it was great if you were in a platform that didn't really have like a soap stack then it was like terrible it was just like on iPhones for a long time the only way to send a soap message was to like string concatenate a bunch of XML together and you know that was just like ah it's terrible whereas sending an HTTP request was pretty straightforward so there was some simplicity that came with the the web API movement and a lot of the code generation type features have been coming back actually in ASP.NET Core we did a bunch of work I think in .NET Core 3.0 or .NET Core 3.1 where you can take an API and generate a similar description document from it it's not a whistle file it's a you know open API specification which describes the API and then Visual Studio does have tooling where you can then generate code from that description document in order to call that API in a strongly typed way so some of these features have have made their way back but personally honestly I love just taking like HTTP client and maybe using some of the like there's some new JSON extension methods that the .NET team put out using system text JSON and HTTP client together in a kind of strongly typed way you just take an object put it into an HTTP request get get an object back it's all handling the JSON serialization for you that's honestly how I like to do things now but if you want that sort of code generated client there is that as available as well. Okay so that's good news I was not aware of that that that makes me a little bit excited because it was it was the ease of use and the get going quickly and robustly that was at the same time it felt like that was that was a good selling point for me when I think about back then you know WCF services was the same thing because it still produced a whistle document if you use SOAP nut I think it also had remote incapabilities and other protocols whatever but you know I don't remember I just remember the SOAP part which I'm not a fan of SOAP but I was a fan of the experience anyway this is a segue into into blazer right we just talked about yeah this is this folks out there this is about blazing so don't worry but those of you that are live on the broadcast right now there's a Q&A panel on your right hand side so go check that out ask some comments as we go along and we will answer them all right so Dan so blazer so ASP that has come a you know a long way of course I started with ASP and then became ASP.net around the year 2000 then 2001 and that was web forms and then we had MVC come in around the year 2009 2010 I think Phil Hex started that project and that became web API that became you know then .net core came along and you know part of all this was the sort of the birth of the client side frameworks as well like Angular of course where the big ones knock out you know the data binding frameworks and then there were the full application frameworks react now is it's probably king view js is another one so when you set out and said okay let's look at like like in that world where we had already strong server side ASP.net components in MVC and razor pages and so on and we already had the client side components that were really strong such as react and angular how did blazer fit into that story at the time yeah so um that that's exactly right like that's the history of web development with .net is that we've always had a really strong story for building web applications that are server render right like you you write some .net code you stick it on your server request comes in and that .net code runs and does some fancy stuff to generate a dynamic html response or maybe some some jason in the the response like web api would do and that then gets rendered by the browser um if you wanted to do anything client side anything that actually ran on the user's machine like in the browser on the user's device well that meant you had to write JavaScript because that's the only thing that historically browsers have been able to execute is just JavaScript so you had to use a JavaScript based framework to do any client side based logic and you know JavaScript is is great has a fantastic ecosystem it's come a long way since it's very humble beginnings um but I think having to bridge those two ecosystems like having to bridge JavaScript the JavaScript world and the .net world it comes with a cost like they're two different runtimes two different frameworks two different languages I often make the analogy to human spoken languages like having to write your application in both .net in JavaScript is like having to learn a second language and so for many people learning multiple languages is fine like I have a sister-in-law who knows like seven languages and doesn't mind picking up new languages at all like human spoken languages um but for a lot of people you know learning a new language is a pretty big investment like I can say you know hello and where's the bathroom and in Portuguese but that's that's about it I'm certainly not fluent if I if I had my choice I normally would speak in English and if I'm writing code I normally would prefer to write .net code because that's where my skills are that's that's where I'm fluent that's what I'm most familiar with um and fortunately the web community agreed and the browsers all the browser vendors got together and said hey let's let's standardize a a byte code for the web a low level byte code format for the web that's called WebAssembly and so now browsers don't just speak JavaScript they also speak this low level byte code format that runs and it's now implemented in all the browsers it's WebAssembly supported um all the desktop browsers all the mobile browsers and the idea there is as long as you can compile your code to WebAssembly or run it on WebAssembly you can now write your code in any language that you want and have it run in any browser on any device at near native speeds and so that's what really then opened the door to have not just JavaScript but other development platforms running in browsers and Blazor was a project that we kicked off to enable full stack web development with .net where you can use your whatever skills or your your your language that you're fluent with your .net tool belt be able to use it not only on the back-end server but also be able to use the client side in the browser okay so that's very fascinating does that mean that I can like I can share code between them so like if I have a if I have some object models or whatever in C sharp that I'm going to use on the server can I use them on the client as well it used to be like with JavaScript you had to like duplicate your object model in JavaScript as you pass things and forth so is that a benefit here absolutely yeah that's that's one of the big benefits is that you can you can share code in fact when you create a Blazor WebAssembly based application we set you up this way we give you the we give you a server project which is just an ASP.net core project you know standard ASP.net core application where you can have your web APIs and any server rendering logic that you want we give you a client project which is the actual Blazor WebAssembly app that's the .net code that's going to get downloaded to the browser and executed client side and then we also give you a third project a shared project which is just like a it's just a normal .net standard class library but it's referenced by both the client and server and that's where you can put like object object models or any shared validation logic that you want to have on both the client and the server and that same DLL like they literally the same file gets used on both sides of the wire both client and server okay that that's amazing that's like the holy grail of a lot of these things I know that you know in the Node.js world the idea of what do they call isomorphic development or ISO something right where you you code the same in the client and on the server it's a big deal and I guess now we have that and on the ASP.net stack as well yeah it's a huge savings like you you no longer have to bridge these two worlds you can just write in one language you can reuse the code you get full stack web development with .net that's what web blazer was was really all about so yeah that then that there's been quite a bit of excitement about that because I think it is really enabling like I remember the first time that I sat down with the original blazer prototype which was implemented by a dev on our team named Steve Sanderson it was actually just about three years ago today it was in it was in July of 2017 Steve was doing a talk at NDC Oslo and he was it was it was just a talk about things that browsers can do at the time that you may not know about you know new browser features and one of the new browser features was WebAssembly and Steve had this idea you know for a demo wouldn't it be cool if I could get some .net code running in the browser on WebAssembly and he managed to find this little .net IL interpreter called .net anywhere DNA it was on github it was written by some I forget the guy's name at Google I really should remember his name but it was written like you know years and years ago it was all written in C and at the time the only thing you can really do with WebAssembly was take some some C code or C++ code run it through the inscription tool chain and generate some WebAssembly from it so that you could then run it in a browser and so Steve took this code and tweaked it a little bit and got it built as WebAssembly and managed to get Hello World running for the first time in a browser all written in C sharp but of course this is Steve Sanderson so he didn't just stop there he was like wow that's interesting Steve if you don't know Steve he's also the author of Knockout.js you know fairly popular JavaScript front-end framework so he's familiar with the JavaScript world and he handles a lot of the integrations that we do with front-end JavaScript frameworks and so he thought well maybe I could write a little WebUI framework using this and so he wrote a .NET component model and WebUI framework on top of that runtime which he named Blazor where did that name come from well it's browser plus razor because razor is the HTML and C sharp templating language that we use for for ASP.NET web applications and he used that same format for writing components so browser plus razor where does the L come from he said it just sounded better I think at one point he joked that it was because of blockchain but we don't really know I guess it's he just stuck it in there and he got that framework working and then he also did like Visual Studio tooling for it like he knew enough of the razor editor to like get into its innards and enable like intelligence and completions for components and stuff and he did this demo at NDC Oslo at just a demo right where he showed hell here I'm going to write some .NET code with a bunch of UI components and get it running completely in the browser on this WebAssembly thing there full stack web development .NET and it was like mind blown and I remember sitting down with that prototype for the first time and feeling like wow you know I I know some JavaScript but it's not really my strength and I've always kind of you know I kind of fumble around with it I feel like I can now be productive writing client side web UI and it was great and that was the beginning of the blazer project wow that's a that's a quite a cool beginning I think I think your team has a few of those type of moments right I think it wasn't SignalR it's kind of a similar similar story where you know could we do it for fun or I want to show something and then SignalR came out of it and became a huge hit right that's a great question I don't know I mean that's a Damian Edwards and David Fowler question I don't know the exact conception story for SignalR but probably yeah well there you have it folks so sometimes you just have to go with your instinct when you see something cool and you know make it happen I guess yeah and honestly when we started it it wasn't I mean a lot of people were very impressed but there was also a lot of skepticism because there were a lot of front-end frameworks very well established Angler and React I think came was either around there but was maybe a little earlier in its history but still these were very well-established front-end frameworks and there were some questions like is this is can this really stand on its own in this in this world of such dominant JavaScript players that's why we kicked off the project initially as an experimental project like if you followed along with Blazor early on it was experimental it wasn't even preview it was like you know pre-alpha we weren't even sure if it was going to go anywhere and we weren't ready to even commit that it would become a thing but after shipping like nine some odd experimental releases of it and the community really seemed to rally behind it and was getting pretty excited we finally made that that pivot to say yeah let's let's let's let's productize this thing let's let's take this web assembly dotnet runtime and turn it to something that people can really use in production and it just ships like so we ship Blazor WebAssembly just in May of this year it was a almost a three-year journey to finally get it out the door and make it ready for people to use a little bit before that we ship the another version of Blazor slightly different that we call Blazor server in dotnet core 3.0 and it shipped again with dotnet core 3.1 LTS Blazor is a little bit closer to like a traditional dotnet web app in that all the code still runs on the server side but what we do is we set up a web socket connection with the browser that's just live and it uses the same component model as Blazor running in the browser on WebAssembly but the components run on the server and all the UI interactions happen over that real-time connection so you like click on a button in the browser that button click gets sent to the server over that web socket connection the component runs it does its rendering on the server Blazor figures out what needs to be updated in the DOM on the server and sends that DOM diff back down to the browser and updates the the browser then client side so it's a much thinner client piece most of the logic runs on the server but it still enables that like rich interactive feel that you would expect from a spa style application right you can click on things and update the UI without having to do a whole page refresh that that also shipped late last year in like September I think then again in December of 2019 okay so we got a few questions here related to this so you said that it's you know Blazor shipped in 3.1 it doesn't core 3.1 is that is that ready for production is it like is it in a preview or is it final like what's the and is it like would you recommend people using it in production today oh absolutely yeah it's shipped it is ready for production I mean Blazor server has shipped twice already it shipped in .net core 3.0 and then shipped again with .net core 3.1 .net core 3.1 is a LTS or long term support release so it's got a nice long support horizon on it people are using it today for all sorts of things Blazor Web Assembly just shipped you know a little about two months ago now with and it's it's in the .net core 3.1 SDK we haven't actually declared Blazor Web Assembly an LTS release yet it was the first release of Blazor Web Assembly so it is a supported release but it's called a current release all that means is that when we ship Blazor Web Assembly again with .net 5 which we are working on right now that will ship later this year you'll be expected to upgrade and that upgrade should be really seamless like we're expecting to have a very high compatibility bar from the Blazor Web Assembly .net core 3.1 based release and the .net 5 release but both are absolutely supported and are ready for production use right now awesome we got another question here which is about like what languages are supported you mentioned C sharp are other .net languages supported as well well fundamentally Blazor is just best based on .net and .net IL so if it compiles the .net IL you can use it in a Blazor app there is one language constraint which is Blazor is heavily based on razor and razor in .net core is HTML and C sharp if you've never seen a razor file before it looks like a mixture of HTML markup and then interweaved with C sharp code and then that build time what happens is that file gets turned into a normal C sharp class where all the markup rendering logic is captured in that class and then when your Blazor component or your MVC view or your razor pages page renders that C sharp class is just executed as a compiled .net class at runtime because the razor format itself is C sharp based like there's no VB variant of razor in .net core or and there's no F sharp variant of razor in .net core either that razor file actually does need to live in a C sharp project so the place where you use your write your razor code that needs to be that needs to be in a C sharp project but anything else like your business logic you know any other code that you want to reference or use from that application you can put that in like a VB .net project or an F sharp project reference that from your Blazor app and you're and you're good to go. Okay awesome so any .net language so there's some there's cobalt .net there's all I think back in the day with .net started I think there were over 20 languages because you can add you can add your own language to .net by the way in case you're wondering and so people did which was kind of funny there was lol code I don't know if you are familiar with that that's a what is that it was it was it's a it's a fantastic language that no one ever wrote anything interesting in but it was just a joke but yeah go look it up if you haven't seen it it's a hilarious I kind of wonder if that if that may come back because I feel like in the Java world like with the JVM there's been this growth in JVM based languages on top of of of that ecosystem like you know Kotlin and Scala and these types of things like you know for a long time it was just basically just Java and then those languages kind of came along with .net it was almost kind of the inverse right like we had a sort of explosion of .net runtime based languages and then it kind of kind of whittled down and I wonder if at some point there may be more interest in doing language based innovation on top of the the .net runtime but we'll just see see what people come up with I think I think that's how F sharp came to be right there was there was a demand for like a functional language on top of the object oriented that we had C sharp and visual basic .net and and I think that's how F sharp started so I think the difference is that it had a company supporting it year after year I think Scala and Kotlin they also have organizations behind them to to sustain them and maintain them over time so maybe that's the trick I don't know yeah yeah we'll have to see see what the future holds okay so I remember like back three years ago and I was on the asp.net team I think it was or I just left the asp.net team at the time and we talked about it and you had this idea about bringing the web assembly before it was even called well maybe it was called blazor but the idea of .net web assembly and I think at the time you and I talked about it you mentioned that yeah you know right now it's based on was it mono runtime that actually so you had to include the entire mono runtime in the web assembly that you sent to the browser that the browser has to download just to say hello world so you're a very simple hello world web page like a completely white blank web page that just says hello world in text would actually include the entire mono runtime to be able to do that and I forget the numbers but it was something like yeah it's like four megabytes or eight megabytes I think it was just to do that and of course that was prototype and all that sort of stuff but where are you now in that journey as we you know if the competition is decided react and react is like a smaller JavaScript library or whatever like how does how does the blazor web assembly stack up against those well first of all blazor web assembly app is not four or eight megabytes today just to just say the published download size for like a default blazor web assembly app if you just create a new project publish it that app will weigh in about like 1.7 1.8 megs transfer size for for the application and that includes everything that includes the dotnet runtime that yep you are you are bringing a runtime along with your app it includes all the core framework library dependencies that you need for that application includes your app assembly with your own components and your app logic as well as any other stuff that you decide to include in your web app like our templates include bootstrap so includes the the bootstrap styles and any other dependencies that the bootstrap has in that app so blazor web assembly apps they are still heavier than like you know really optimized and tree shaken JavaScript based application so you do pay an overhead for download size and and startup time with this model that that is that is absolutely true we are bringing a runtime with the app the runtime that we're using is the mono dotnet il interpreter based based runtime that's how the the code is executed and it is brought in as a web assembly bundle that's actually the only piece of web assembly in the application once you have the runtime we just boot we boot it up we started up in the browser and then it executes normal dotnet assemblies directly in the browser so kind of weird people out actually when they look at the network trace for a blazor web assembly app because they'll see like all these dls like come down with the app and they're like whoa why are dls being downloaded by the browser and some people actually even get worried about like security is like is that is that safe is that okay um the web assembly code that's running those dls is actually running in the same security sandbox that javascript code runs in so those dls can't do anything that you couldn't do with javascript they can't like go randomly touch the file system they can't open random network connections none of that stuff it's it's in the same browser security sandbox that you would get if you wrote an angular app or a react app but yeah you are bringing that that down with the application some people also get concerned about the fact that it's mono and they ask us well why is it not dotnet core with one of the big efforts that's actually happening right now on the dotnet team is this unification of all of the different dotnets that we have either implemented or accumulated over the years you know we had originally had dotnet framework right that's the dotnet that shipped with windows and powered many dotnet apps for for many many long years dotnet core was an effort to make a cross platform version of dotnet that could run server applications and then more recently they just added support for desktop apps like winforms and wpf mono originated externally from microsoft as a cross platform implementation of the the dotnet framework it got the most traction in the mobile world like through through xamarin xamarin used mono to enable dotnet scenarios on ios and and android devices xamarin is now part of the the microsoft fold so all the technologies is just now part of dotnet but there's obviously some reconciliation that needs to happen there like there's stuff that mono has and that dotnet core has that kind of overlap and we'd like to unify so that you know it's less engineering cost for us to not have to maintain two things and it's better for customers because it means you get a more consistent experience you get more features because we have more time to build those features that's a big theme for the dotnet five and dotnet six wave if you've read scott hunters like a vision blog post on dotnet five he talks about this one dotnet vision like let's let's not have two different implementations of the core framework libraries let's let's get rid of the overlap and just have one dotnet and that is happening right now like in dotnet five actually we're still using the mono base isle interpreter and it's it's kind of disingenuous actually to still keep calling it the mono isle interpreter in my opinion because it's really now the dotnet isle interpreter for all of dotnet we don't it's not like we have multiple of those so that will continue to live on if you want to do isle interpretation that's the the code base that we intend to use but for the core framework libraries in dotnet five we were using the mono based implementations of those libraries in the most recent blazer web assembly release and for dotnet five we're replacing those with the dotnet five core library implementations so that gives us you know one code base and it also expands the api surface area that we now have available for blazer web assembly in dotnet five before we targeted dotnet standard two that one in dotnet five will target the dotnet five surface area so yeah we you do bring the runtime with you it is the it's lineage of the isle interpreter is mono but really you should just think of it as the dotnet isle interpreter for for all of dotnet and we do a lot of work to trim things down to make them small so when you publish that app we will run an isle linker over all of your dotnet isle code to strip out all of the unused codes that we can we can we can detect using static analysis and there's actually a lot of investment happening in the dotnet five and probably also in the dotnet six time frame to improve isle linking in dotnet so we can have standalone executables that are that are really small that helps to reduce the size quite a bit we also statically pre-compress all of the built assets using broadly like maxed up to the its highest setting so when you finish the the publish output everything has been i al linked and also pre-compressed to be as small as it can be using the highest broadly settings you then deploy those assets to your to your you know a static you can deploy them as a static site or you can deploy them to like an azure app service and they are you know it's a little bigger than uh than you could get with JavaScript but it's still for many applications quite reasonable all right so a few questions there so um so do you depend on broadly like what if the browser does not support that um sipping algorithm will you fall back to gzip or like what is the lowest what is the browser support here does it doesn't work in internet explorer does it work in the pre-chromium versions of edge for instance yeah that's a great question so for blazer web assembly obviously you need support for web assembly so you're going to need a modern browser that has web assembly support all the all the existing modern browsers support web assembly so that's generally not an issue it happens to be that also the same browsers that support web assembly they all support broadly so if if you have one then you automatically get the other ie does not support web assembly and it will never support web assembly so no you can't run a blazer web assembly app in ie ie does support web sockets though so you can build a blazer server application and have that work with with ie that works just fine with the there's I think there's some polyphones that you do have to add still for ie to get at the work but it it is a supported scenario so you're looking at basically chrome edge firefox safari on desktop mobile browsers if you have a you know reasonably current version of all those browsers then you should be good to go with blazer if you need ie 11 support then blazer server is what we would recommend that you then use for that scenario okay so here's a question for you shady asks do you think browsers will include the framework to run blazer in the browser so the megabytes to download will be very small that would be nice yes so we should we should ask them to do that um it'd be great to have some way to pre cash the these these assets with the with the browser um I don't know honestly of a path currently that would allow us to do that so that before your app even runs those those assets are already there but those assets do get downloaded to the browser using the normal htp mechanism so once they're downloaded they are cashed in fact we handle a lot of that for you like we will once once we've downloaded the runtime and the framework assemblies we put them into the the app cache for for that application and we set up like a manifest with hashes of all the assets so that we can very efficiently detect if anything in the app has changed if we need to you know invalidate the cash and grab a new version of the app so the second time you load the application you don't see any of the traffic for the runtime or the dlls because they're already downloaded and installed well not installed but you know cashed in the browser so so browser based caching mechanisms that all works perfectly fine you can put those assets on a cdn as well that also works um so you can get cdn based optimizations for your application as well would it make sense and and so the runtime itself you download that's a separate download so that that will be cached you know between you make updates to your app code if it's on the same runtime you might already have a cached in the browser is that do i understand that right no i'm typically the the runtime in the framework libraries are still downloaded per app so it's not like you download it once and then every app gets them um i mean i think there used to be capabilities in the browser where you could like point at a common resource download it and cache it and if someone else point at the same resource like the same cdn for example the browser would reuse that asset i think browsers have generally moved away from that model due to security concerns um so even if you try to like uh pre-cache the uh the downloaded assets with one app and then use it from another i think browsers in general will will not let you do that but for at least for that app once the user has browsed the app the first time when they browse to that app again um the the the runtime in the framework libraries are already there so the download size of that second hit is actually pretty small you actually can see this when you create your first blazer web assembly app if you create the app you build it you run it the caching um happens on that first hit so you hit that you hit the html page for the app it downloads a little uh a bootstrapping javascript file to download the runtime download the framework library set everything up and then fire up the runtime for you all the runtime assets are now cached to that point if you then try to go to the network tab and see oh how big is this app and so you you know control f5 to see the app it'll look really really tiny in development um because well everything was cached after that first hit and you didn't see the network tab on the first hit so if you really want to go see where the assets are you have to go digging around in the browser app cache uh part of the the application tab and the browser dev tools um during development we don't run the il linker and we um uh don't do pre-compression so the download size during development will look significantly larger like i think it's in dot net five it's now like it is like eight megabytes or something like eight or nine megabytes during development but that's okay because you know you're on the dev machine downloading those files as fast because it's all locally on your on your box when you go to publish then all the optimizations kick in to reduce the size of application and make it nice and tight and and reasonable to download okay so that's like the debug versus release builds uh kind of concept there um okay so yeah i remember like jQuery it used to be like you would you would point to the google cdn or jQuery i think at the end had their own cdn and so if every website got their jquery.js from the same url then the browsers all had them cached and but you're saying this is no longer the case i don't think that works really any i could be wrong if someone someone feel free to correct me if i'm wrong but from i understand like um trying to use a common cdn pattern like that browsers have moved away from that kind of cross app code sharing due to um some security concerns that i don't i don't not the best person says the details oh i just remember looking into it hoping that oh maybe we could maybe we could leverage this and it turned out that most browsers have have disabled that that capability for caching specifically they don't cache the off domain javascript files or some they won't cache the files across apps like they won't you can't have a shared shared resource like that is my understanding if i'm wrong please open a github issue on the ace net core repo and tell us how we could achieve this because that would be great if there was a way to actually download blazers runtime once and have it be reused that could be a big win for a lot of people i'm not aware of a way to currently do it though so let us know if you if you have a clever idea i have an idea slash question so you mentioned you're doing a manifest so is this a web manifest like do you actually create like a service worker where you do some aggressive caching and setting up potential offline capabilities as well because i know when you do a service worker that's a javascript concept there are a bunch of caching like it's it gives you the opportunity to be way more aggressive when it comes to caching and way more granular and you can really control things instead of kind of leaving into the browsers and um and then i also wonder uh if if maybe that could be a mechanism to have that shared component living on the ace pinette cdn as a service worker up there that will then uh you kind of install a service worker to the browser it's kind of weird uh but if that then gets installed to the browser uh then others can use it or there's something there i don't know have you is that right do you do service worker and web manifests so we we do have like we do set an app up with a service worker and a web manifest when you set the option that you'd like to create a progressive web app so you can create progressive web apps with with blazer and that enables scenarios like offline support installability you can do push notifications all those standard pwa features can be done with with blazer and in fact we have a template option where you can say please when I create this project set it up as a pwa and we'll give you that that service worker and the web manifest um the service worker that we give you when you publish the app it does handle offline scenarios so it will handle caching the assets of the application so that they are available offline so you can run the app without having any sort of network connection and that yeah that's that's supported today um the mechanisms that you if you haven't selected the pwa option we still cache the the files that are downloaded locally but that it's not a um it's not set up for an offline uh logic because I believe it's the service worker that basically kind of intercepts the htp request and says no no no I've got that already it's right here let me give it to you so you need that additional logic to get offline to work all we do in the non pwa case is just make sure the files are cached so that the app loads faster on the second second refresh all right um so here's uh here's a really question about um performance in general so when you're running uh c sharp in web assembly in the browser and you know um how does that compare from a performance perspective to let's say react or angular yeah um it's it's unfortunately not going to win any uh uh speed competitions with react and angular um this is something that we are uh actively working on right now remember I said that the runtime is an il interpreter based runtime now most of the time with with dot net you're not running on an il interpreter you're running on a jit based runtime where the il code is just in time compiled to native code on the machine and that's what makes it really really fast and dot net is ridiculously fast dot net core on the uh like public benchmarks like the tech and power benchmarks it just crushes like in terms of server performance and throughput it is amazing so definitely go check out the tech and power benchmarks if you haven't seen those yet but when you're running in the browser the runtime is just doing il interpretation and that is significantly slower than the jit based runtimes and the the the code execution will also be significantly slower if you just ran javascript javascript runtimes are also are heavily optimized and they are you know very performant in in browsers if you're doing cpu workload uh intensive workloads with javascript you can get uh good performance uh in a browser and the the runtime we're using doesn't really compete you know it's not even ballpark close so our our goals at least initially with blazer web assembly were we want to enable you to build rich responsive ui um the performance is sufficient for doing that like you can build rich interactive user interfaces with with blazer web assembly if you are trying to do cpu intensive tasks like you're trying to build like a ray tracer that runs in the browser or you know a bit a bitcoin miner or something like that you're probably not going to want to do that with blazer web assembly because the execution of that that kind of cpu intensive code will be will be slow um what we plan to do to address that in the future is a couple things for for for dotnet five the plan is we are doing more work on the il interpreter to make it as fast as we can we're doing more work on blazers rendering pipeline so that it's as fast as we can basically optimizing and tweaking um the infrastructure that we already have that shipped um with the blazer web assembly released in in may post dotnet five the plan is aot compilation so ahead of time comp compiling more of your dotnet code all the way to to web assembly when you do that the web assembly code is very fast like it is like within you know a close approximation of native speed on the machine it's one of the reasons why web assembly was invented it but it was not just invented to broaden the developer ecosystem it was also invented to give you more deterministic performance in a browser uh javascript is is heavily optimized and can be fast but because of the dynamic nature of the javascript language the javascript runtime often has to do these like this guesswork where it's it it thinks it knows what the code is doing and so it will optimize it in a particular way but then something dynamic happens where it's like oh darn like i was wrong so i got to roll that back and optimize it differently and that kind of back and forth can result in some swings in performance in javascript runtimes web assembly basically shortcuts a lot of that and says no no no i'm just going to go all the way to that already um optimize code and give you much more deterministic performance in the browser so if we can take your c-sharp code and turn it into web assembly that does get significantly faster and that is something we've been working on for a good long while um we had actually hoped to ship it in .NET 5 originally i had even published a um a .NET 5 roadmap for blazor web assembly and we had aot on there and people were really excited about it and then we had to take it away um what happened is that uh the work to move from the monoframerc libraries to the .NET 5 framework libraries is quite a bit of work um and trying to get that done and do aot all in the half of the .NET 5 release that we still have remaining just it just didn't fit um so we ended up having to push it off to to .NET 6 but we are going to do it and when that shows up that should give you um great performance there there is a trade-off there that people should be aware of um aot compilation of .NET i l tends to also expand the size like the way you should think about this is think about the like native images that get generated from the .NET assemblies that are used in you know any .NET runtime those native images tend to be quite a bit larger than the original .NET assemblies some a similar phenomenon happens with aot compilation to web assembly so there's this trade-off right where yeah you can aot compile some of your code but it'll get bigger and so that may you're basically moving uh trading off with load time then for for your application so what we're thinking there is that um you you probably want to aot compile the performance critical hot paths in your app like you won't just aot compile the whole thing you'll you'll aot compile the the parts that are really performance critical and then the app will run in a mixed mode where some of the app is ahead of time compiled the rest of it is being run as normal .NET assemblies um that's really the tricky part to to to get right and why aot needs a little bit more time um we do have an implementation of aot for for blazer web assembly in fact some other companies like the the uno folks there's another company that builds a web assembly based .NET app platform using the uwp model they've done a lot of experiments with the aot model but what what I for my understanding happens if you if you try to use it today um and you want to run in this mixed mode linking the .NET assemblies to make them smaller gets broken because you at compile a bunch of a bunch of code it has these sort of fixed offsets that it uses to call then into the .NET code and then when you link the .NET code all that stuff gets scrambled then nothing works anymore so that's a bunch of work it requires you know figuring out the right tool chain for how we handle that scenario that's all stuff that's coming in the the .NET six time frame so don't don't don't go expecting that you're going to get you know amazing performance from this the .NET code in a blazer web assembly app but you do get to take advantage of running on the client machine take advantage of the you know the the memory the storage the cpu on that machine um if you need code to run faster in that scenario you have the option of either offloading that code back to the server because it'll run really fast on .NET core so put it behind a web api and do it on the server or you can also do javascript interop where you you write that performance critical code in javascript call into it from blazer which is fully supported and then you can call back from javascript back into .NET to speed up certain uh code paths using uh using uh targeted javascript that's also a potential strategy okay so um what when is there like a what in in all the situations where i would use react or angular let's say today like would i use would i be able to use blazer for the exact same use cases or are there differences pretty much like if you look at blazer and you kind of squint it basically kind of looks like react what's done in .NET and cchar it there they were blazer was in particular heavily inspired by by react so if you're familiar with react you probably find a bunch of things in blazer that feel very uh natural so yeah the things that you would normally do in react you should be able to do in blazer okay but i don't need a bunch of node modules and packages to to bundle all my javascript and compile all this sort of stuff and you know do npm restores and it's all like within .NET it's all within visual studio there's no none of these sort of artifacts that you know i know a lot of people really don't like them that's right yeah .NET new blazer or you can file new project of blazer web assembly app in visual studio control f5 or even f5 we actually support uh full debugging of your blazer web assembly code from vs which requires some very interesting gymnastics if you think about that one because you're trying to remember the code's running not like locally on the machine it's running in a browser in a like on web assembly in a dot in a on a javascript runtime effectively how do you debug your .NET code that's executing in the browser we do some very clever things there with a debugging proxy that speaks the javascript debugging protocol and sort of augments it with .NET specific concepts in order to make that happen you can even actually go into the browser dev tools and there's a gesture that will allow you to debug your .NET code in the browser using the normal chrome or edge browser dev tools which is pretty cool you can set break points in like your razor code and see that in the the browser dev tools and hit that break point all within the the browser so yeah that that whole experience end to end is very easy to get started with if you want to get started with blazer just go to blazer .NET click on the get started button and you can have your first blazer app running in about five ten minutes oh that's amazing that sounds like magic what you describe in the in the browser developer tools uh i gotta try that it's pretty cool did you implement the debuger using the debug adapter protocol uh just like we have the language server protocol that's shared between vision studio and vs code there's also something called debug adapter protocol that is also something is that how you implement this well remember we have to connect to the to the browser so we have to support whatever browser debugging endpoints it supports and so that's why we plug through the uh like the v8 debugging protocol endpoint and the nice thing about doing that is in addition to stepping through your c-sharp code if you do then do javascript interrupt like if you call into some javascript you can just keep stepping and you can then step into the javascript code and then come back out again the way you can think about it if you're familiar with the javascript script debugging features in visual studio like where you attach to javascript code from vs it's very similar infrastructure that we're using for for blazer and it will work both for your dotnet code and for your javascript code oh okay so you mentioned you had the blazer server and which doesn't contain any of the web assembly it contains a thin javascript layer on top of a let's say normal ish razor based web app and uh all the client side interactions actually takes place by proxy and back and forth on your behalf over a web socket connection to make the changes in the DOM this sounds a lot like dare I say it web forms and the hx control toolkit is there it is a little similar but to be honest the fact blazer in general um you know it has a component model so you're building reusable UI components um it's very event driven like you you click a button and you have a button click handler thing that you that you then write some code for if you're familiar with web forms development there's quite a bit in blazer that kind of looks familiar to you now it is not web forms like this let's all be very clear it's a very different it is a different component model a very different execution model um but there are some things that will feel familiar and natural if you're coming from a web forms background and in fact we've been working on a on an ebook for a while called blazer for a spinette web forms developers that's available on the dot net site that's specifically targeted for that crowd if you're a web forms dev and you're kind of interested in getting started with blazer that book walks you through the blazer concepts and how they relate to web forms development that you uh you might find interesting to to read through it's it's it's still not fully done yet this book but it's almost complete so we should hopefully have it completed here within the next month or two but yeah it is it is similar um and uh yeah that's exactly how it works like you have a all the UI interactions happen over that signal our connection is it is using signal our under the covers to manage the web socket connection um and it's simulating that spa style app while still leaving all your code running on the server and it gives you that light client feel it also you it can really simplify the app architecture in a lot of ways instead of having to like I'd say you want some data like from the database in a true spa style application well you would have to then stand up a web api and that web api then talks to the database and you ship data back and forth between the browser and the server through like you know some jason data or whatever in a blazer server app you're already on the server you have full access to all of dot net core and all the server capabilities so from your component code you can go ahead and just talk to the database or talk to an arbitrary service um and not have to jump through those additional layers which can can make things quite a bit easier I think blazer server is really great for that quick line of business application that you just want to deploy on your internet and uh you don't want to you know it doesn't need to be architected to handle like 100 000 users you can just do something really really fast and get going really quick with a blazer server application yeah because I guess you're now at the limit of how many web socket connections you can have open at the same time so there's like there's a natural limit that is different is that a server limit or is that a yeah that must be a server limit not a browser limit because it'll have any browser just have to be one good blazer server you have to start thinking about scale out of the the server resources because you're you're paying with your server resources to run the ui for every connected client and you need a connection for every client now for the connection scale out we actually have an azure service that can help you out the azure signal our service is specifically built to handle connection scale out for signal our based apps and it works great with blazer server so you can scale up to you know tens or hundreds of thousands of connections using the azure signal our service but you'll still need then to think about the server resources to then handle the the logic for all of those connections so people that do the database connections and all that sort of stuff to the website the yeah and potential like your database connections and whatever other resources your server is using to produce the logic um okay so that's that's good to know so if you're willing to spend a little money to to to adopt the servers that can scale then you're good for even the largest sites doing blazer server so we're almost out of time and we have a few questions here okay um so michael asks are there any public lists of sites using blazer i'm not talking he's not talking about samples here just but actual real world sites um there there isn't today and this is not been on my to-do list to put together for for a long while to have like a like a showcase or at least i'm published like user stories or case studies for applications that are using using blazer today there are sites out there um last i checked i think the steel toe site um from the what from the pivotal folks that was built on on on blazer um if you have a site that is public and using blazer today i would love to know about it so shoot me an email or find me on twitter um dam raw 27 on twitter um where i am trying to put together that list and get something published so that people who have very similar questions uh can can find out about that but it is yeah it is absolutely being used we're using it internally at at microsoft as well for various projects and uh you can use it too awesome here's another one uh from shady he says uh is there any plan for local storage and session storage to be inside blazer soon so those are two browser concepts yeah for storing any data in the browser um support for uh interacting with local storage is something we actually plan to add in dot net five it's uh it's being either worked on right now or it might already be done uh steve sanderson had put out a package for that um some number of months ago as like an experiment and we are planning to add that to dot net five but you don't need to wait um there are uh several i think community packages out there as well that have already written the javascript interrupt code to interact with local storage and basically shrink wrapped it in a dot net c sharp wrapper that you can then just add as a new get package to your application i think blazer it has one there's there's a couple of them out there so you can do it today absolutely but we do plan to make that a um sort of a first class part of the blazer framework nice excellent and i think um that's pretty much what we have for uh the show today we're completely out of time um dan i will say this was uh this was a true pleasure i now know a lot more about blazer than i did before and so thank you so much for coming on and explaining it all to us you're very welcome madz and i'm looking forward to seeing your your first blazer application head on over to blazer dot net you heard of folks blazer dot net and so go check it out try it out let us know what you think and you know i'll make sure to post dan's twitter in the description below if you're on youtube watching this and so go check it out and let him know what what you think about asking questions and so on that's it for now thank you so much i hope to see you again next time