To enable WebAssembly to be read and edited by humans, there is a textual representation of the wasm binary format: https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format
http://blog.stevensanderson.com/2018/02/06/blazor-intro/ Interpreter: The Mono runtime itself is compiled to WebAssembly, but your .NET assembly files are not. The browser can then load and execute the Mono runtime, which in turn can load and execute standard .NET assemblies (regular .NET .dll files) built by the normal .NET compilation toolchain. This is similar to how, for the desktop CLR, the core internals of the CLR are distributed precompiled to native code, which then loads and executes .NET assembly files. One key difference is that the desktop CLR uses just-in-time (JIT) compilation extensively to make execution faster, whereas Mono on WebAssembly is closer to a pure interpretation model.
Ahead-of-time (AOT) compiled mode In AOT mode, your application’s .NET assemblies are transformed to pure WebAssembly binaries at build time. At runtime, there’s no interpretation: your code just executes directly as regular WebAssembly code. It’s still necessary to load part of the Mono runtime (e.g., parts for low-level .NET services like garbage collection), but not all of it (e.g., parts for parsing .NET assemblies). This is similar to how the ngen tool has historically allowed AOT compilation of .NET binaries to native machine code, or more recently, CoreRT provides a complete native AOT .NET runtime.
Interpreter: Faster AOT: Smaller and compression-friendly compared with AOT-compiled assemblies
• Razor MVC
• Razor Pages
• Similar to ASP.NET
• Is more an MVVM framework
• Enables two-way data binding
• Useful for SPA apps.
Running .NET in the browser
“The first step to building a .NET-based SPA framework is to have a way of
running .NET code inside web browsers. We can at last do this based on open
standards, supporting any web browser (without any plugins), thanks to