Aspnetcore: Separate The .NET Core to WASM Experience from Blazor

Hi @EisenbergEffect! The core WebAssembly work is actually being handled by the Mono team. We are building Blazor on top of what they provide. Others in the .NET community are free to do so as well and several already are (Ooui, Uno, cshtml5). You can follow along with the progress on mono.wasm in the Mono repo.

I'm very much not interested in compiling Mono to WebAssembly. I'm only interested in .NET Core. What I'm asking for is something like this:

• Use the .NET CLI to create a .NET Core C# project.
• Use the .NET CLI to compile my .NET Core project to WASM, having the 3 outputs described above.

@danroth27 Is that supported today?

The Mono folks are also working on full ahead of time (AoT) compilation of .NET code to WebAssembly along with the supporting MSBuild SDK. The last update they published on the effort was http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/. @mhutch is probably the best contact for getting the latest status.

I'm not interested in Mono. I'm interested in .NET Core only. Is there a story for .NET Core WASM?

Is there a story for .NET Core WASM?

Not currently. .NET Core is primarily used today for cross-platform server scenarios. Mono is the .NET runtime used today for cross-platform client scenarios (Android, iOS, macOS, gaming). Most WebAssembly scenarios today are client scenarios, so Mono is the cheapest way forward right now. Over time it's reasonable to expect there will be a convergence, but that will take some time.

FWIW I really think this issue of runtimes and platform targets needs to be addressed first. When I hear that I have to use two different flavors of .NET to build an app...use Mono for your client and then use .NET Core for your server...it doesn't get me excited at all. I just want to use .NET Core, and frankly, forget that any other .NETs exist. One .NET please :)

@EisenbergEffect from the consuming perspective it should be pretty much an implementation detail which runtime is running your code.

I disagree. Never in my history of being a software engineer have I considered which run-time is running my code to be an implementation detail I can ignore.

@danroth27 Just some feedback from my development team, we also would like to see Blazor use .NET Core eventually. We are not interested in Mono or even the full .NET framework. We want the same runtime on client and server.

We are not interested in Mono or even the full .NET framework. We want the same runtime on client and server.

Well, no matter what we do you won't have exactly the same runtime on the server and in the browser: the browser runtime needs to be WebAssembly based, but the server one does not. It's not unlike how running on iOS is fundamentally different that running on the server. The unifying factor on the client and server is .NET Standard. That said, I think we share your goal of wanting to unify on a single runtime impementation. It doesn't make sense for Microsoft in the long run to own and maintain two runtimes at twice the price. Convergence work is already happening in many ways. More and more of the code in Mono and .NET Core is shared. But getting to a single runtime is still a major effort that will take some time.

In the meantime Blazor is an experiment and we are experimenting with what can be made to work today 😃

@danroth27 Thanks for the excellent response, Dan!

Excellent totally agree

On Tue, May 15, 2018, 10:54 AM paulost notifications@github.com wrote:

@danroth27 https://github.com/danroth27 Thanks for the excellent
response, Dan!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect I had similar view on Mono, however when I learned that since Microsoft acquired Xamarine, Mono is Microsoft tech... And is optimized for client scenarios... And I can use it to run my ".net standard" code inside browser today... All concerns were brushed aside.

To grab browser runtime only components:
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-amd64/

... Now I get back to building my own XAML based UI stack in C# targeting WebGL

To be clear, it's not about using non-Microsoft tech. It's about wanting to use only .NET Core. I'm looking for one, open source, cross-platform .NET with a unified cross-plat CLI. Not two or three .NETs or multiple compilers. I would have thought that new efforts would be focused around .NET Core and unification, so I found it surprising that WASM was only for Mono and required a different toolchain.

I've personally been asking for unification in the .NET platform for over 10 years. So, forgive me if I'm a bit agitated in this thread, since after 10 years I still need 3 .NETs to build my services and clients. There are very few things I'm willing to wait 10 years for. I left .NET several years ago and since December have been looking back into it to see if the situation has improved. I'm more than a little disheartened to find many of the same issues I left behind, still lingering.

I mean this with all sincerity, I want to love .NET again. Please, take this seriously.

I mean this with all sincerity, I want to love .NET again. Please, take this seriously.

We are taking this issue seriously and we are actively working on convergence of the various .NET runtimes. But it will take time, and we may very well decide that in the short term due to practical considerations it makes sense to proceed with Mono with a longer roadmap for convergence with .NET Core.

I still need 3 .NETs to build my services and clients

I assume the three .NET's you are referring to are .NET Framework, .NET Core and Mono. The good news is that we announced at BUILD that .NET Core 3 will have support for Windows desktop applications, so hopefully that will reduce the need for one of those runtimes and provides further evidence that convergence is our common goal.

FWIW, Mono has already switched to the Roslyn compiler and the msbuild build system, so it's not really a different toolchain. You can build .Net Core and Mono-based projects in a single solution, with the same build system and compiler. Mono is also using large and ever increasing parts of the .NET Core classlibs.

WASM is a pretty unusual target. Not only is it not possible to JIT compile, things like threading, file, and sockets have very different models to most other platforms. Mono has many existing technologies developed for ports to other unusual/constrained platforms like iOS, watchOS, PS4, etc that help with the WASM port, such as the IL interpreter, cooperative GC suspend, Full AOT (surprisingly hard for generics) with generics sharing, LLVM bitcode backend, and managed linking.

I fully expect Mono's WASM project type to use SDK-style projects, with a MSBuild SDK delivered via NuGet, and usable from dotnet.

I think I smell some Mono hate here, no?
Please do not be so quick to want to throw Mono out. Remember when Microsoft had no love for Linux? Mono was there for C# devs. Remember when Microsoft had no love for Mac OS? Mono was there again. Now JavaScript is eating our lunches, guess who shows up? You bet, Mono is here to save the day, being the first full .net to run on Wasm. Please show some respect!

Listen, we C# devs over this side love Mono. They are doing a fantastic job. Leave Mono alone. If cool kid .Net Core wants to party, that’s fine too, BUT MONO STAYS!

@humbersoft If you want a reason why we "hate" Mono I'll give you one. It's seeing errors like this in your browser console: "WASM: It should have been installed in the `/Users/builder/jenkins/workspace/test-mono-mainline-webassembly/label/highsierra/sdks/out/wasm-interp/lib/mono/4.5/mscorlib.dll' directory." Who is jenkins? What a bizarre message! A Mono dev evidently hard-coded his/her personal path in the runtime.

@paulost Jenkins is a continuous build service. Search for it. It's very popular.

Thanks @MisinformedDNA but why is Mono telling me that it should be installed in that exact path on my system? I am not trying to build Mono but only use it to run a blazor app. A shipped runtime shouldn't tell you about its build service path.

I don't have the full context of the error, but I can guarantee you are going to see additional debug info because Blazor is not a shipped product. Mono may be shipped, but we may be using preview versions of Mono as well or preview libraries built on top of Mono. Remember, we are still in the experimental phase.

Finally, Xamarin runs on Mono, which probably runs thousands of mobiles apps. It's a well-done technology. Would it be better to have one runtime? Of course. But .NET Framework is Windows only and Mono was later created as a port for compatibility with Linux and .NET Core was then created for better scalability in the cloud. Do you really think MS prefers managing three separate runtimes? Of course not. But not every language has the scale or ambition of .NET. Also, in case you missed it, MS is porting WPF, WinForms and UWP to .NET Core 3.0. .NET Core is the future, but it will take time.

Yes, Mono webassembly support is in preview and is not yet shipped in any release.

In this particular case, the runtime attempts to determine the runtime assembly directory (which contains files like mscorlib.dll) based on its current filesystem location, and the last-ditch fallback is the path in which the runtime was compiled. On wasm the concept of a "filesystem location" doesn't really apply... On other similar embedded setups the embedding code typically registers a custom assembly resolver (e.g. to resolve from an android APK zip), and I guess that hasn't been set up here yet.

@PaulOst
That's the thing with living on the bleeding edge, you are likely to get cut. Mono for WASM is in its early stages and is very experimental, but it is more complete than the DotNet Anywhere that Blazor was originally based on. It's not polished yet for sure, so errors like the one you experience are to be expected.

Some devs like the hot bits, some rather wait until everything is cool and calm. These are hot bits, maybe you need to adjust your expectations a little. I understand perspective though, you want a polished product. Can you imagine waiting around for .NET Core to target Wasm? They may not get to it until 3 years. Mono is a solid product and it's a lucky thing that Microsoft has them, otherwise, we wouldn't have a .NET story for WASM and so many other platforms.

Another thing, I submit to you that most devs prefer the new Microsoft that is developing important techs like this in the open. We'll end up with a better product in the end.

With all of that being said, Blazor may not even see the light of day for a variety of good reasons. Plan for that too.

I went ahead and started building a Xaml engine that runs natively in the browser. You can check it out here: https://github.com/XamlEngine/Samples

Joining this discussion a bit late, but surprised that so many people are concerned how their .NET standard code runs. Slap whatever label you want onto the runtime - Mono, .NET Core, FlubberGast - whatever the actual runtime is going to be different. There's no way .NET Core on server will be the same as .NET Core on WASM or compiling against WASM. So who the heck really cares?

What matters is how the rubber meets the road or how easy it is to access that runtime code. I agree with @EisenbergEffect that having an easier lower level path to getting .NET bootstrapped could be a huge boost for .NET in general.

Why not make this a serious push in addition to what Blazor does as this surely would drive innovation around different ways of using .NET in the browser. This can only be a huge plus for visibility of NET if lots of new projects pop up that use .NET in new and innovative ways in the browser. I'm sure Rob is asking because he has some ideas on how to build a new framework of some sort :-)

This is doable today with the current Mono.wasm module and in the future with .NET Core or at least the Mono AOT compiler but I think building a standard hosting interface that could faciliate getting .NET bootstrapped into the browser would go a long way towards this goal. The actual runtime could then be plugged in and swapped out as updated technology and resources becomes available.

This seems like a huge opportunity to for .NET to be an early adopter in the Web Assembly space. What I've seen with Blazor looks very promising, but I think it's not thinking progressively enough if that's the only official WASM exposure point of .NET. I really like the Blazor model and what it allows for, but I think that's just the tip of the ice berg of what's possible if the eco system for running .NET was as simple as creating a standard .NET application. I'm not necessarily talking about UI frameworks here - but even just being able to bootstrap and call into loose .NET classes either as an entry point and Web Worker like processing, or even as a means to interop from existing JavaScript applications. Even for that the benefits of sharing some business/validation code could be incredibly valuable.

Lots of potential - it would be cool to enable that as much as possible by making it easy to use this technology, even the lower level bits!

@RickStrahl It may not look progressive because they are still in the experimental phase, but they have a lot of ideas they are working on including server rendering, desktop/mobile apps, web workers, etc. This will give you a better idea of what they are considering.

Oh I don't think that Blazor is not progressive - I clarified in my message above. Even just playing around with this I can totally tell that this is going to be a great way to build apps. There are so many little moments where you just go - this would be such a pain in Javascript/Typescript.

My point is mainly that I think that they should also add the raw .NET functionality in addition to the Blazor stuff. This infrastructure has to be built anyway to support Blazor, so why not expose it in a more user friendly way so it's drop dead easy to drop the .NET 'hosting' into a client app.

I'm not sure I understand, Blazor lets us use most of the .NET functionality, what specifically functionality do you think is missing?

I have to use Blazor. What if I have an existing HTML application, or building something with another framework and have no need for Blazor? There is still a great use case for providing access to .NET code in the browser outside of an HTML framework (sharing validation code, utilities etc. etc.).

I have to use Blazor. What if I have an existing HTML application, or building something with another framework and have no need for Blazor? There is still a great use case for providing access to .NET code in the browser outside of an HTML framework (sharing validation code, utilities etc. etc.).

I don't understand. Blazor is essentially:

1. Razor syntax for web components,
2. various JS interop helpers,
3. Mono-based WebAssembly .NET

You presumably want the second and third of those, and the first doesn't harm you.

My point is mainly that I think that they should also add the raw .NET functionality in addition to the Blazor stuff. This infrastructure has to be built anyway to support Blazor, so why not expose it in a more user friendly way so it's drop dead easy to drop the .NET 'hosting' into a client app.

That is certainly the intent of the mono.wasm effort as I understand it. We often refer to Blazor and mono.wasm in the same breath, but in reality Blazor is a just a web framework. It's mono.wasm that provides the underlying WebAssembly based .NET runtime. Other frameworks are free to build on top of the same runtime, and alternative frameworks already exist (Ooui, Uno). @kumpera @mhutch are probably the right folks on the Xamarin team to speak to the dev experience they hope to enable around using mono.wasm independent of any particular UI framework.

The zip file provides, today, extremely raw support for writing C# apps without Blazor. It’s good enough to validate the tech but it requires a lot of manual work.

It’s our goal to provide what this issue description suggests, a full toolchain including rich bindings and debugging.

Which zip file?

@EisenbergEffect what you should care about is .NET Standard, not .NET Core.
Make sure your dependent APIs rely on .NET Standard and you're good.

@weitzhandler I think you may be missing my point. If I want to build something with .NET, I have to install some concrete set of tools, don't I? I started working with .NET over 15 years ago, so I don't personally find any of this daunting or confusing (though I prefer not to have quasi-duplicative tooling installed on my machine). But, imagine someone who has no experience with .NET and who's a Mac user. They decide they want to build a .NET app, both front-end and back-end. They hear that .NET Core is the latest, snazzy thing, so they go through the rigamarole to install the .NET CLI and VS Code. Then, they find out they can't build their front-end with that. They need to go get a different set of tools (with a different name, from a different place, with different leadership, etc.). Again, imagine they have no prior history with .NET. This is not a good first-time experience. Ok, now imagine that this person is an Architect or CTO who is trying to give a fresh evaluation of .NET either for the first time or after a number of years. Maybe they are setting the direction for their company. Is this the experience you want that person or their technical advisors to have? They are going to be comparing it to Go, Node, Rust, etc.

As to my personal feelings, my tolerance is fairly low after so many years and so many versions of .NET. I'm trying to help people like @danroth27 understand a bit of what has to happen to make people like me take an interest in .NET again. There's a lot more to it than this, but having a bit more unification would certainly help. I just want to install a single CLI and VS Code. The process of getting up and running with a full-stack .NET app on non-Windows platforms should not be any more complicated than that.

My original post was intended to paint a simple picture of what a WASM "north star" should look like from a dev experience and build output perspective. I install the CLI, I write some C# code (with whatever editor I want) and then I execute a CLI command to build my C# code to WASM, producing a reasonable set of output files (wasm, bindings, types). That should be the goal. If it's not there today, that's understandable. But, let's make sure we're sailing the .NET ship in the right direction, towards the best possible experience, not settling for what's simply easiest or quickest for Microsoft engineers.

@EisenbergEffect
Rob, I agree the goal would eventually be to have .NET Core run everywhere even replacing Mono with it.
I'd even want a ".NET UI Standard" that renders everywhere the same to be included with .NET Core, but .NET Core is relatively fresh. .NET Standard was the best solution to get this divergence in shape, and currently doesn't look like you can ask for anything better.

My vote is for replacing Mono with .NET Core for the same points @EisenbergEffect made.

@EisenbergEffect I have a dream of a caliburn micro for web, is this what you have in mind? I actually started working on spiritual successor with knockout and Duocode (JavaScript port of mscorlib) a while back before webassembly was a thing.

@AndersMalmgren Aurelia is much like Caliburn.Micro for web today. The vNext version we're working on for release this year even supports alternative renderers so it can render to not just HTML but also native desktop, 3d, and console apps. It's written in TypeScript, not .NET though. It might be possible to port Aurelia to .NET Core at some point in the future, once this tech matures a bit more.

That said, since Microsoft is building Blazor, I'm less likely to personally build anything for .NET WASM because that would put me in competition with Microsoft. From history, we know that no open source inside the .NET ecosystem ever amounts to anything when Microsoft has decided to build something similar, regardless of whether that open source is better designed, more extensible, more performant, etc. I admit to being pretty jaded here. The only thing that's likely to change this is if Microsoft were to hire me to lead a .NET Core-based front-end framework and ecosystem. It wouldn't be Blazor though. Blazor isn't designed right (it's repeating .NET anit-patterns from 10yrs ago), nor is it ambitious enough, standards compliant enough, or forward looking enough, in my opinion. The's a larger opportunity at stake for Microsoft, but the window is closing. I've tried to convince various people at Microsoft to embrace what they could do but so far I've been unsuccessful. Front-end just doesn't seem to be a big priority for Microsoft right now.

@EisenbergEffect The problem for me is that Blazor uses Razor which is MVC. We need a true MVVM that can take the power of a full clr runtime. Like type convention based templating etc. I started this work with DuoCode and knockout and used my Knockout.BindingConventions to glue them together. I even got syntax like this working

public IEnumerable<IResult> Save()
{
    var confirm = new ConfirmResult("Proceed?");
    yield return confirm;

    if (confirm.Result == ConfirmResults.Cancel)
        yield break;

    yield return new service.SendCommand(new SaveSomethingCommand(this.something));
}

https://github.com/AndersMalmgren/Knockout.BindingConventions.DuoCode/wiki/IResult-state-machine

Knockout died out and my interest with it. But the dream lives on :D

Well, I might take up the work again but with Vue or similar.

Maybe Aurelia instead of Vue, since Aurelia descends from Durandal, which comes from Caliburn.Micro. Also, Aurelia has conventions, vanilla JS models, performs better, has strong standards compliance and a lot more goodness that other frameworks don't have 😄

It wouldn't be Blazor though. Blazor isn't designed right (it's repeating .NET anit-patterns from 10yrs ago), nor is it ambitious enough, standards compliant enough, or forward looking enough, in my opinion.

What's wrong with it?

@EisenbergEffect or Aurelia. I like Aurelia but since it uses JavaScript or Typescript which is a type erasure language you lose all of that sweet CLR runtime magic you can do. Plus JavaScript DI is to be honest crap compared to what you can do with a proper clr runtime. I implemented a small DI container for Duocode for the same project mentioned earlier and type based injection in frontend is the way forward in my opinion. I need to look into the modularity of Aurelia, knockout was very extendible back in the day, and Vue seems to continue that trend.

@AndersMalmgren Aurelia is probably the most extensible front-end framework today. The vNext implementation we're working on takes it to another level as well. You also might be surprised about what we can do with our DI :) It is type based and has extensible lifetimes, etc. Since JS has native support for classes, there's no erasure. We can also model interfaces with a DI helper method or a Vanilla JS Symbol. So, TS can merge those with TS interfaces, enabling the same patterns as .NET. In other words, you can have IAuthenticationService injected into a class just fine at runtime 😄 As far as I know, we are the only framework that can do this. I tried to bring as much of the good parts from Xaml and Caliburn.Micro to the web while leaving the bad parts behind. So MVVM is even much simpler and more powerful in Aurelia as well. I'll put together a series of blog posts on Aurelia for Xaml developers and Aurelia for ASP.NET MVC developers. That might help people connect the dots and understand why/how it makes front-end development not only fast and easy, but also SOLID.

@manigandham I spent many, many years as a .NET developer, .NET open source leader and Microsoft MVP, giving lots of feedback to Microsoft on stuff like this. I even worked for Microsoft as a Sr. PM, Sr. PM Manager and Principal PM Manager for a short while (not on the .NET team though). Unfortunately, over a period of about 12 or so years while I was doing that, I saw very little come from it, particularly regarding feedback I gave around front-end frameworks. So, you'll have to forgive me if I don't feel like spending my Saturday writing a 10k word paper on the design issues with Blazor, the web standards problems, the product vision, etc. I'm just not sure it would amount to anything. If Microsoft wants to hire me to lead the future of front-end for them, I'd certainly consider, but as I said, front-end isn't really a priority for them right now. And as far as I know, Blazor isn't even funded yet.

And for those that don't know me, I just want to add that I'm not angry about all this or an angry person. I know sometimes things seem a bit that way when you don't know me and you just read my comments here or there. However, I'm very very passionate about front-end. I've been building front-end frameworks, libraries and tools for almost my entire career. It's a short 15yrs, but it's comparatively a long time to spend focused in this area. So, I've seen a lot of stuff, done a lot of stuff and absolutely have strong opinions. I'm passionate and I get frustrated when I see Microsoft repeating old mistakes or doing things that I've already seen go wrong elsewhere. So, I have no ill will here. I really want Microsoft to succeed. I want to see them be the leader in front-end. I just get frustrated and a bit sad to be honest, when I see that not happening. I want the best for .NET and its community.

you'll have to forgive me if I don't feel like spending my Saturday writing a 10k word paper on the design issues with Blazor

The point is that you made a claim, and then someone simply asked you to get into more detail about it:

Blazor isn't designed right (it's repeating .NET anit-patterns from 10yrs ago), nor is it ambitious enough, standards compliant enough, or forward looking enough, in my opinion.

I, too, would be curious about particular examples.

And given the nature of Blazor right now, I'm not sure it's fair to compare it with an average Microsoft product. It _isn't_ a product yet, and it's being developed in the open far more than it would be if it were.

@chucker I understand. It's cheap of me to make a claim like that and not go into detail. I'm thankful that you are interested in hearing more.

From my perspective though, most of what I would say is feedback I've given to Microsoft before, often repeatedly before. So, while it would be interesting for you, I'm not sure it would make a difference to Microsoft. I don't know if anything would change.

That said, I'll try to start outlining something. It would be too long to drop in a GitHub comment though. I'm a bit fearful of backlash if I publish a blog about it. I've been bullied and hated on plenty of times in my career by various groups who didn't like being criticized. While that's mostly been Facebook/React team members recently, I'm not sure I want to open myself up for it yet again.

Maybe there's some way I can frame such a post where it would make a difference and not invite a lot of negatively. It's a tough game to play. I'll give it some thought though.

I can confirm that in many ways both known and unknown Blazor is not perfectly designed and we welcome any constructive feedback to make it better. As evidenced by our issue backlog there is plenty of work to do! And while design perfection will almost certainly remain elusive, in the end what really matters is if developers find using Blazor productive and useful. That much seems achievable.

@EisenbergEffect I certainly welcome any objective and constructive criticism or feedback you might have. As with any objective criticism I can't promise it will change anything. I can only say that we will do our best to thoughtfully consider it.

Also, no one deserves to be bullied or hated on and such behavior is explicitly against our Code of Conduct.

In my humble opinion Blazor has already succeeded. In my 20 years of developing with both Microsoft and non Microsoft technologies I've seen the same pattern emerge every single time. When ever something new comes out you see two types of developers. One who sees the programming model as a vehicle to get somewhere and one who likes to spend hours and hours tinkering with different libraries. I have tried to convince myself that using all these different js libraries from all these different companies gives me more mobility and freedom as a developer but soon find how they all drift apart in vision, mission and regrettably, compatibility at some point in time. I always ended up looking for a unified programming model and realized that strict conventions aren't always a bad thing. In short. I care about the solution and Microsoft has never let me down. Some of my best and most used web apps are all done on Microsoft tech and I believe Blazor will bring a good unified programming model that plays well but is not dependent on hundreds of other libraries working together.

In my humble opinion Blazor has already succeeded. In my 20 years of developing with both Microsoft and non Microsoft technologies I've seen the same pattern emerge every single time. When ever something new comes out you see two types of developers. One who sees the programming model as a vehicle to get somewhere and one who likes to spend hours and hours tinkering with different libraries. I have tried to convince myself that using all these different js libraries from all these different companies gives me more mobility and freedom as a developer but soon find how they all drift apart in vision, mission and regrettably, compatibility at some point in time. I always ended up looking for a unified programming model and realized that strict conventions aren't always a bad thing. In short. I care about the solution and Microsoft has never let me down. Some of my best and most used web apps are all done on Microsoft tech and I believe Blazor will bring a good unified programming model that plays well but is not dependent on hundreds of other libraries working together.

If Microsoft didnt took influence from outside we would be stuck on winforms and webforms

https://devblogs.microsoft.com/dotnet/introducing-net-5/
Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.

There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

We will introduce new .NET APIs, runtime capabilities and language features as part of .NET 5.