Using WebAssembly, Mono can now run your C# and F# code in the web browser. You'll learn about Mono's WebAssembly backend and the AOT and interpreter engines that power it, and see its modern dotnet SDK based toolchain in action.
 Okay. Good morning everyone. Hope you're enjoying first time. Sorry about the delay. I had trouble getting a taxi then got very lost and then the equipment did not cooperate. So I'm here to tell you about.NET on the web with web assembly. My name is Michaela Hutchinson. I work at Microsoft on the mono and visual studio for Mac and Xamarin teams. You can see my email address and Twitter handle there. If you have any questions for me, feel free to send me those questions. So how many people here know what web assembly is? Okay. So not everyone. Good because I prepared an explanation for you. So it's essentially a bytecode for the web. So you can compile programming languages down to this bytecode and run them in your web browser. It's a stack-based machine very much like.NET. It's the equivalent of.NET IL. So you can run this in the web browser. You can also run it on Node.js. So you can run the exact same thing on the front end and back end. So this is really interesting because it allows you to use your language of choice for programming in the web browser, which previously you couldn't do. You had to use JavaScript or transpile to JavaScript which gets complicated. There was a precursor of web assembly called as in JS. This is a refined and more standardized version of that. It also is really interesting because it allows you to reuse existing libraries. So if you have existing code that's written in C or C++ or so on, you can compile that to web assembly and now run that in your browser. Or you can run it in your browser and then use it from JavaScript. So this is what it looks like. So if you have some C++ like that, or that could be C quite easily, it compiles into a machine code. There's a nice op codes there. This is the textual representation of those. So as you can see, it's very much an assembly language. You could actually write this if you wanted to. There's a slightly higher level, kind of S expression based version, which is syntactic sugar to make it easier to write the assembly. So the web assembly initiative was started in 2015. The community group that developed it, they standardized their MVP, their minimum viable product in 2017. So it's available in all the major web browsers, in Chrome, in Firefox, in Safari, in Edge, and of course all of the browsers that are derived from those, the Chromium and so on. And this has actually been used to run some pretty big existing code bases, some pretty serious code. So people have got Unreal Engine running in this, like actual games running in the web browser, all C++, the Unity game engine, the open source Godot game engine. I believe they have a booth over here as well, if you want to check that out. And also AutoCAD and Figma. Figma is a really nice tool for designing UIs that we use a lot. And I was very surprised to find out that this thing was all written C++ running in the web browser. And as I mentioned before, it builds on Asm.js, which has actually been around since 2010. So this is how the compilation pipeline works. So you have your C or C++, and that feeds into Clang, which generates LVM IR, then that goes into M-Scripten. So M-Scripten has a back end for converting the LVM IR into WebAssembly or Wasm. So this is kind of the standard M-Scripten tool chain that everyone uses for running C and C++ in the web browser. So you might expect that with seeing as Mono has an LVM back end, we could just swap out Clang for Mono and use the same pipeline for.NET IL. And of course C-Sharp and F-Sharp and so on would produce your.NET IL or any other language like Boo, for example. But it's not quite that simple. WebAssembly is running in a sandbox. It's a very constrained environment. You can't JIT compile, and JIT is kind of our default method of running code. You don't have threads. Our garbage collector relies on threads. Our finalizers rely on threads, even if you're not using threads yourself. You also don't have signals, which we typically rely on for catching null reference exceptions by the segful or the garbage collector uses that for interrupting threads when it needs to garbage collect. So we have to do a lot of work to actually work around these limitations. And I'll get into those in a little more depth later. But yeah, the net result is that it mostly works. There are a bunch of limitations and it is getting better. So the way that we run code in this non-JIT environment is, first of all, we have the Mono interpreter. Now Mono had an interpreter back when it was dotted almost 20 years ago, called Mint that was deprecated and it was only a couple years ago that we resurrected it because this enabled us to run dynamic code on languages that don't allow JIT compilation, like the iPhone or games consoles or the Apple Watch and so on. And the interpreter has the advantage that it's really easy to get running on any new platform. But it is slower to execute your code, of course. But it does have the advantages that the code is smaller. IL is pretty compact compared to the generated native code. And it's also fast to compile because you don't have to do anything else to your IL. You just run your IL directly. Another technology we have is ahead of time compilation, where we essentially pre-compile everything that the JIT would compile into a native binary. And that still needs to run time for garbage collection, reflection, stuff like that. But it's essentially a native binary. So that results in much faster code because we can run that through LVM, for example, and get all of the amazing optimizations that LVM performs. It's slower to compile. LVM is very slow to compile compared to the C-Shop compiler, for example. And the generator code is bigger. So we also have this hybrid mode or mixed mode where you can combine the two. So you can use AOT for some of your code, like the class libraries or really hot methods and so on. And then you can use the in-top to first stuff that isn't used as frequently. So that essentially lets us pick the trade-offs to get the best of both worlds. So given that you're running in the browser, you don't have access to syscalls and all of those things that your library is typically built on top of. You have to do everything through calling into JavaScript, and then JavaScript calls into the APIs that JavaScript has access to. So you essentially need a bridge layer. So we have our runtime.invoke.js, and that returns JS objects, which have an invoke method and so on. It's all very kind of, it's like reflecting almost. You have to get these little JavaScript strings, emit them, you get back a kind of object that you have to ask it for its properties and stuff like that. It's not very friendly to program against. And the same thing is true on the JavaScript side. It's very much you're using the mono embedding APIs to like load a method handle and construct objects and invoke it and so on. So to make this easier to use, we are currently building something called the binding generator. I don't have anything just to show off just yet. So one of the problems is that in JavaScript, the type system is, it's loosely typed and it's dynamically typed, and that doesn't map well to C sharp, which is pretty strongly typed and is statically typed, because you won't get in tele sense, the compiler can't compile against methods that it doesn't even know are there, because they're only added at runtime and stuff like that. Or when it returns an object, the C sharp needs to know what type that object is. It can't come back as multiple different types that look the same and therefore you can use them the same way like you can in JavaScript. However, in practice, most APIs are not. Most APIs like the browser DOM and so on are static. They always look the same and they always return the same types. So this is great resource. So TypeScript, which compiles down to JavaScript but is strongly typed, has a repository of definitions at definitelytype.org, which is essentially defines in a statically typed, strongly typed way what these APIs look like. So what we are doing is we are using those definitions to generate C sharp wrappers into these same APIs. So how do you get started with this? Well, of course, you can check out the repository. It's all up on GitHub. That commit there was literally last last night. You can watch development as it's happening and you can compile it from source. But not everyone wants to start from bare bones. So there are some higher level platforms that do a lot of the kind of low level stuff for you so you don't have to deal with those low level details. So the biggest and most well known is Blazor, which is being developed by Microsoft. It's still very much a kind of, it's not kind of officially going to be stable for sure. It's kind of a prototype, but it's very mature for a prototype, very usable. It's essentially a full stack framework that's very like React. So if you want to write your single page applications running in the browser, you can write those in C sharp and have a very react like component model and so on. And you can choose how those are split between the client and the server and the client and the server using all C sharp. And the back end is ASP.net core. Another really interesting one is Uno. Now this is an open source cross platform re-implementation of the Windows UWP UI framework that runs on iPhone and Android and so on. But it also runs on WebAssembly in the browser. So that's really interesting because you can run, you can write a C sharp app that runs across mobile and in the browser client. Another interesting one to check out is a UI object oriented UI toolkit. It's a very easy to use UI toolkit that maps down directly to HTML elements. So if you want to do things in kind of a more web like way, that's a great toolkit to use. And one I find particularly interesting is Wazem WinForms. So a developer just as a side project decided to take Mono's Windows form stack and run that in the web browser. So he compiled X Windows and FreeType and Cairo and LibGDI plus and all that stuff and managed to get Mono's WinForms implementation running completely client side in the web browser, which is kind of amazing. So I have about five minutes left. I am going to show you a quick demo. So I have my web browser open at a cup. No, not that. Okay, so this is Uno. So this is actually XAML that is rendering into HTML completely on the client. You can play around with all the different controls they have here, but you can see it's real. Like if I change the red to green, for example, and then run, it reloads, takes a little. Yep, and now we have two green squares. And of course this has all of the things. Oh, I don't have Wi-Fi right now. So this is actually, you know for sure this is running in the client. For those of you that don't know, Uno is a clone of the Windows 10 API. So when Windows launched they introduced a new graphics UI. And these folks in Canada went and clone all of the Windows API and did their mobile on Android and iOS then now on the web. So if you can build a Windows 10 API, one of those modern APIs, then you can run it well now. Yeah, thank you for that. Yeah, so this is Ui. So this is one of its, this also running in WebAssembly. As you can see, it's served up from S3, so completely static. And this is also a demo that does convert, that is live again. And so this is converting Xamarin forms, XAML into Ui elements. So these are all just divs and stuff. And this is Wazem running Windows forms, which is actually completely functional if, well, I appear to have lost mouse input. But it is, yeah, I've tried it. It's completely functional, which is amazing. So yeah, so back to the slides. Yeah, so if you want to learn more about these, we have these, here's some resources. The slides will be up online, so you don't have to write these down right now. And yeah, thank you for coming to my talk. Please remember to fill out your session evaluations. And again, if you have questions, that's how you can contact me. Thank you.
 Okay. Good morning everyone.  Hope you're enjoying first time. Sorry about the delay.  I had trouble getting a taxi then got very  lost and then the equipment did not cooperate.  So I'm here to tell you about.NET on the web with web assembly.  My name is Michaela Hutchinson.  I work at Microsoft on the mono and visual studio for Mac and Xamarin teams.  You can see my email address and Twitter handle there.  If you have any questions for me,  feel free to send me those questions.  So how many people here know what web assembly is?  Okay. So not everyone.  Good because I prepared an explanation for you.  So it's essentially a bytecode for the web.  So you can compile programming languages down to  this bytecode and run them in your web browser.  It's a stack-based machine very much like.NET.  It's the equivalent of.NET IL.  So you can run this in the web browser.  You can also run it on Node.js.  So you can run the exact same thing on the front end and back end.  So this is really interesting because it allows you  to use your language of choice for programming in the web browser,  which previously you couldn't do.  You had to use JavaScript or  transpile to JavaScript which gets complicated.  There was a precursor of web assembly called as in JS.  This is a refined and more standardized version of that.  It also is really interesting because it allows you to reuse existing libraries.  So if you have existing code that's written in C or C++ or so on,  you can compile that to web assembly and now run that in your browser.  Or you can run it in your browser and then use it from JavaScript.  So this is what it looks like.  So if you have some C++ like that,  or that could be C quite easily,  it compiles into a machine code.  There's a nice op codes there.  This is the textual representation of those.  So as you can see, it's very much an assembly language.  You could actually write this if you wanted to.  There's a slightly higher level,  kind of S expression based version,  which is syntactic sugar to make it easier to write the assembly.  So the web assembly initiative was started in 2015.  The community group that developed it,  they standardized their MVP,  their minimum viable product in 2017.  So it's available in all the major web browsers,  in Chrome, in Firefox, in Safari, in Edge,  and of course all of the browsers that are derived from those,  the Chromium and so on.  And this has actually been used to run  some pretty big existing code bases, some pretty serious code.  So people have got Unreal Engine running in this,  like actual games running in the web browser,  all C++, the Unity game engine,  the open source Godot game engine.  I believe they have a booth over here as well,  if you want to check that out.  And also AutoCAD and Figma.  Figma is a really nice tool for designing UIs that we use a lot.  And I was very surprised to find out that this thing was all  written C++ running in the web browser.  And as I mentioned before,  it builds on Asm.js,  which has actually been around since 2010.  So this is how the compilation pipeline works.  So you have your C or C++,  and that feeds into Clang,  which generates LVM IR,  then that goes into M-Scripten.  So M-Scripten has a back end for converting the LVM IR  into WebAssembly or Wasm.  So this is kind of the standard M-Scripten tool chain  that everyone uses for running C and C++ in the web browser.  So you might expect that with seeing as Mono has an LVM back end,  we could just swap out Clang for Mono and use the same pipeline for.NET IL.  And of course C-Sharp and F-Sharp and so on would produce your.NET IL  or any other language like Boo, for example.  But it's not quite that simple.  WebAssembly is running in a sandbox.  It's a very constrained environment.  You can't JIT compile,  and JIT is kind of our default method of running code.  You don't have threads.  Our garbage collector relies on threads.  Our finalizers rely on threads,  even if you're not using threads yourself.  You also don't have signals,  which we typically rely on for catching null reference exceptions  by the segful or the garbage collector uses that for  interrupting threads when it needs to garbage collect.  So we have to do a lot of work to actually work around these limitations.  And I'll get into those in a little more depth later.  But yeah, the net result is that it mostly works.  There are a bunch of limitations and it is getting better.  So the way that we run code in this non-JIT environment is,  first of all, we have the Mono interpreter.  Now Mono had an interpreter back when it was dotted almost 20 years ago,  called Mint that was deprecated and it was only a couple years ago that we  resurrected it because this enabled us to run  dynamic code on languages that don't allow JIT compilation,  like the iPhone or games consoles or the Apple Watch and so on.  And the interpreter has the advantage that it's really easy to get running on any new platform.  But it is slower to execute your code, of course.  But it does have the advantages that the code is smaller.  IL is pretty compact compared to the generated native code.  And it's also fast to compile because you don't have to do anything else to your IL.  You just run your IL directly.  Another technology we have is ahead of time compilation,  where we essentially pre-compile everything that the JIT would compile into a native binary.  And that still needs to run time for garbage collection, reflection, stuff like that.  But it's essentially a native binary.  So that results in much faster code because we can run that through LVM, for example,  and get all of the amazing optimizations that LVM performs.  It's slower to compile. LVM is very slow to compile compared to the C-Shop compiler, for example.  And the generator code is bigger.  So we also have this hybrid mode or mixed mode where you can combine the two.  So you can use AOT for some of your code, like the class libraries or really hot methods and so on.  And then you can use the in-top to first stuff that isn't used as frequently.  So that essentially lets us pick the trade-offs to get the best of both worlds.  So given that you're running in the browser, you don't have access to syscalls and all of those things  that your library is typically built on top of.  You have to do everything through calling into JavaScript,  and then JavaScript calls into the APIs that JavaScript has access to.  So you essentially need a bridge layer.  So we have our runtime.invoke.js, and that returns JS objects, which have an invoke method and so on.  It's all very kind of, it's like reflecting almost.  You have to get these little JavaScript strings, emit them, you get back a kind of object  that you have to ask it for its properties and stuff like that.  It's not very friendly to program against.  And the same thing is true on the JavaScript side.  It's very much you're using the mono embedding APIs to like load a method handle and construct objects and invoke it and so on.  So to make this easier to use, we are currently building something called the binding generator.  I don't have anything just to show off just yet.  So one of the problems is that in JavaScript, the type system is, it's loosely typed and it's dynamically typed,  and that doesn't map well to C sharp, which is pretty strongly typed and is statically typed,  because you won't get in tele sense, the compiler can't compile against methods that it doesn't even know are there,  because they're only added at runtime and stuff like that.  Or when it returns an object, the C sharp needs to know what type that object is.  It can't come back as multiple different types that look the same and therefore you can use them the same way like you can in JavaScript.  However, in practice, most APIs are not.  Most APIs like the browser DOM and so on are static.  They always look the same and they always return the same types.  So this is great resource.  So TypeScript, which compiles down to JavaScript but is strongly typed,  has a repository of definitions at definitelytype.org,  which is essentially defines in a statically typed, strongly typed way what these APIs look like.  So what we are doing is we are using those definitions to generate C sharp wrappers into these same APIs.  So how do you get started with this?  Well, of course, you can check out the repository.  It's all up on GitHub.  That commit there was literally last last night.  You can watch development as it's happening and you can compile it from source.  But not everyone wants to start from bare bones.  So there are some higher level platforms that do a lot of the kind of low level stuff for you so you don't have to deal with those low level details.  So the biggest and most well known is Blazor, which is being developed by Microsoft.  It's still very much a kind of, it's not kind of officially going to be stable for sure.  It's kind of a prototype, but it's very mature for a prototype, very usable.  It's essentially a full stack framework that's very like React.  So if you want to write your single page applications running in the browser,  you can write those in C sharp and have a very react like component model and so on.  And you can choose how those are split between the client and the server and the client and the server using all C sharp.  And the back end is ASP.net core.  Another really interesting one is Uno.  Now this is an open source cross platform re-implementation of the Windows UWP UI framework that runs on iPhone and Android and so on.  But it also runs on WebAssembly in the browser.  So that's really interesting because you can run, you can write a C sharp app that runs across mobile and in the browser client.  Another interesting one to check out is a UI object oriented UI toolkit.  It's a very easy to use UI toolkit that maps down directly to HTML elements.  So if you want to do things in kind of a more web like way, that's a great toolkit to use.  And one I find particularly interesting is Wazem WinForms.  So a developer just as a side project decided to take Mono's Windows form stack and run that in the web browser.  So he compiled X Windows and FreeType and Cairo and LibGDI plus and all that stuff and managed to get Mono's WinForms implementation running completely client side in the web browser, which is kind of amazing.  So I have about five minutes left. I am going to show you a quick demo.  So I have my web browser open at a cup. No, not that.  Okay, so this is Uno. So this is actually XAML that is rendering into HTML completely on the client.  You can play around with all the different controls they have here, but you can see it's real.  Like if I change the red to green, for example, and then run, it reloads, takes a little.  Yep, and now we have two green squares. And of course this has all of the things.  Oh, I don't have Wi-Fi right now. So this is actually, you know for sure this is running in the client.  For those of you that don't know, Uno is a clone of the Windows 10 API. So when Windows launched they introduced a new graphics UI.  And these folks in Canada went and clone all of the Windows API and did their mobile on Android and iOS then now on the web.  So if you can build a Windows 10 API, one of those modern APIs, then you can run it well now.  Yeah, thank you for that. Yeah, so this is Ui. So this is one of its, this also running in WebAssembly.  As you can see, it's served up from S3, so completely static.  And this is also a demo that does convert, that is live again.  And so this is converting Xamarin forms, XAML into Ui elements. So these are all just divs and stuff.  And this is Wazem running Windows forms, which is actually completely functional if, well, I appear to have lost mouse input.  But it is, yeah, I've tried it. It's completely functional, which is amazing.  So yeah, so back to the slides.  Yeah, so if you want to learn more about these, we have these, here's some resources.  The slides will be up online, so you don't have to write these down right now.  And yeah, thank you for coming to my talk. Please remember to fill out your session evaluations.  And again, if you have questions, that's how you can contact me.  Thank you.
_NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_0_143.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_144_1319.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_1320_6191.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_6192_6563.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_6564_9203.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_9204_9467.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_9468_12767.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_12768_14423.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_14424_16859.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_16860_16991.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_16992_17411.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_17412_17579.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_17580_21767.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_21768_21887.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_21888_21983.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_21984_22103.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_22104_23327.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_23328_25079.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_25080_25547.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_25548_25883.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_25884_26015.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_26016_26567.png _NET_on_the_Web_with_Mono_WebAssembly_Kp5YkpYdVZ4_26568_26681.png