Aspnetcore: Using CoreRT instead of Mono?

[petroemil]

While I understand that you want to showcase a semi-working prototype as soon as possible, I believe this project (ASP.NET Core Razor running in a browser, compiled to WebAssembly) should rather push towards achieving this with the official .NET Core toolchain.

So this is where my question comes:
Why are you not using (and improving) CoreRT's WebAssembly target instead of Mono? This project would be an excellent motivation for everyone inside and outside of Microsoft to actually build all the parts necessary to make .NET Core in the browser happen.

For all of this to become a reality (and a real product) we need

• proper compiler support for .NET Core with WeAssembly support - CoreRT
• a very simple (or low-level) interop library - nothing ASP.NET specific stuff, just the basics, HTML DOM manipulation, subscribing to UI evetns, WebAssembly/JavaScript interop, access to universally available JavaScript APIs (that default functionality that every browser provides out-of-the-box, etc.
• and finally Blazor itself, building on top of all of this, providing an actual (.NET Standard) framework to build web apps

Yes, you would be focusing on delivering an end-to-end solution, but in the meanwhile you would build a foundation that could be used by others to build frameworks more suitable for other scenarios, something like Fable (for F# developers), or Ooui.Wasm (Xamarin.Forms in the browser).

[RyoukoKonpaku]

The reason why mono is used for now since it's the one that has the most working webassembly runtine at the moment for .Net.

Blazor is just an SPA framework on top of the .Net runtime so in theory it isn't really tied in to any specific .Net runtime, so if CoreRT would have a working Runtime it would be easy to make Blazor point to that runtime maybe via a switch on the CLI.

Also If I recall Blazor is using .Net Standard as the target which means that it's fully compatible to .Net Framework, .Net Core, and Mono as .Net standard is supported by all three runtimes.

I do think in the future Mono and .Net Core would be eventually merged it's just that it's a big task to do which won't be done in a few months or years. Most of the code for Mono and .Net Core is shared in accordance to that goal as said by Miguel de Icaza from his recent reddit AMA.

[grahamehorner]

@petroemil @tjbortz1s just add my two cent worth on this; the developer shouldn't need to worry about which .NET runtime is used/hosted within the browser environment running as a web assembly.

Why/how you ask? .NET Standard is the key here, if the runtime within the browser supports a .NET standard any resulting compiled .NET code should work under that runtime weather this be full framework, core or mono.

@SteveSandersonMS did an initial concept using DNA and this was a great piece of research; and created so much interest within Microsoft teams they forked then code and worked on this during a hackathon :D moving away from DNA as the project had a few issues and wasn't maintained; the mono team has already a unit of work where they had undertaken to make mono produce a WASM output and it made perfect sense to use this as mono is a officially supported implementation of .NET Standard.

I don't think mono and .net core will be merged into a single code base, as they target different platforms; (mono supports mobile etc.) I do think they will share a lot of the core code.

[grahamehorner]

@RyoukoKonpaku +1 just saw you posted before I completed above

[RyoukoKonpaku]

@grahamehorner Yeah I'm pretty positive that .Net standard is the key/glue here since it's essentially working on all three runtimes.
Build 2018 is nearing so alot of cools stuff coming for .Net as a whole this year, maybe a demo from Blazor as well? If all goes well in the coming weeks I'd guess. 😄

[petroemil]

@grahamehorner I agree, the runtime should be transparent, and as a developer you should be able to just target .NET Standard and not care about the rest of it.

BUT, WebAssembly is not just another compiler target like x86, x64, ARM, etc. but also a platform with its own unique set of APIs to access platform-specific features, like Windows, Mac, Linux, iOS, Android, Tizen.

As a _library developer_ you might never touch any platform specific area, but as a _web developer_ you will definitely have to rely on those APIs to interact with the platform (which in this case is the browser).

Of course this web interop library and anything built on top of it (like Blazor) can STILL "run" on top of Mono (until the CoreRT' WebAssembly target implementation get ready), but at the end of the day, I still think that Microsoft will have to provide an end-to-end solution for this WebAssembly story.

[grahamehorner]

@RyoukoKonpaku #Build2018 can't wait +1 #signalr #blazor and new memory optimisations in the corefx with span etc... not to mention the kestrel https://www.techempower.com/benchmarks/ performance O:

[grahamehorner]

@petroemil I agree that the hosting application of the web assembly .net standard runtime (mono) , which the blazor application runs within may/does have a different set of APIs; these APIs can be access by blazor via the web assembly runtime an interop layer.

If I'm correct what you seem to be asking for is that these hosting application (web browser) APIs have a interop layer developed and supported by Microsoft ? I personally think that shouldn't be a priority or a need, if the interop layer is well documented and has good examples.

I've already started on the standard HTML5 API interop wrappers, and I know that @LunicLynx has already created a nupkg component for the Storage APIs.

I would also say that as this is open source and given the MASSIVE number of APIs/libraries a web developer could/would have at their disposal i.e. JavaScript/TypeScript if there is something you like why not write an interop wrapper and make it public/open source ?

do you have anything in mind? I could have a look at doing a wrapper as an example

[danroth27]

The decision on which .NET runtime to use for Blazor was discussed at length with both the CoreRT team and the Mono team. The guidance from the CoreRT team was to use with Mono, in large part because there is no committed investment at this time for the CoreRT WebAssembly support. Conversely, Mono support for WebAssembly is commited and has been making steady progress. Mono is already the Microsoft support .NET runtime for a variety of client scenarios (Android, iOS, macOS, games) and is a natural fit for Blazor.

For the most part though, as has already been pointed out, it really won't matter to the end user which .NET runtime is being used under the covers as long as it can successfully run .NET IL and has support for .NET Standard.