WASM in .net maui

[manishbisen]

@davidortinau Why .net maui does not support wasm to target web platform just like uno or flutter ?
Right now blazor hybird is present for web ,but it is kind of code sharing instead of from single code base

[iot-crazy]

If it supported WASM I'd take it up in a flash!

[iot-crazy]

..without blazor I mean, just like with platform.uno, I want to use XAML to create WASM, pleeeeease!

[martin-braun]

I am confused as well. Microsoft invested a lot into Hybrid Blazor, but I don't get why. Things have moved on and people don't want to ship web views as mobile apps anymore. Uno has a really interesting approach in which it even renders the DOM instead of pixels on a canvas, which makes it even a fine candidate for simple websites with the option to expand to other platforms.

WASM is the new foundation for browser script languages that replace JS. Blazor, Avalonia, Uno, Flutter, etc. prove that it's possible, the missing part for MAUI is generating the HTML/CSS from a MAUI app.

[iot-crazy]

Thank you! I thought I was going crazy and was the only person alive who didn't want to use web technologies for native apps! :)

[Xyncgas]

UI built to deliver unifying experience that's a benefit web can deliver

[emceelovin]

I absolutely wish MAUI would target WebAssembly. The problem with MAUI targeting WebAssembly, is MAUI is a handler based UI framework. MAUI is abstract and implementations for the UI come from native OS UI backings. E.g. WinUI(which is interfaced itself even further, and targets UWP, WPF, Win32, etc), Cocoa on MacOS, Androids UI API, etc. I'm sure you can see where I'm going with this here. To target WebAssembly, you need a UI framework to map MAUI handlers to, but AFAIK, there isn't one. It has to be created. Uno renders their way with the DOM, and Flutter renders to a canvas. Flutters UI engine is it's own entire rendering framework. It doesnt rely on any backing. That also requires them to create their own control library in multiple flavors(each OS's theme; Fluent, Cuppertino, Material, etc). Uno targets UWP/WinUI depending on which project template you choose. If, and when, MAUI targets WebAssembly, not only do they have to create a UI implementation to bind handlers to, it has to be created in each theme flavor since there is no UI API on a browser with a specific theme.

[martin-braun]

Yes, there is no UI framework, however there is still a UI for web, which is just HTML. If we assume MAUI renders a DOM (which would be the right choice, since it results in native browser controls) it would render plain HTML without CSS if your controls have no styles attached. However, MAUI could expect you to provide default CSS. It could also provide default CSS based on a theme as you said Flutter does. Additionally MAUI could enable the possibility to attach exclusive styles for web.

[emceelovin]

That is a possibility, sure. Technically, there is no UI for web though. There are tools for you to make one(CSS HTML like you mentioned). If you're going to go the CSS route, which is what you do in the web world to create any kind of UI element for a website, which might be the fastest way to get started initially, there would need to be CSS styles and properties to match the XAML styling/properties of MAUI XAML. Basically the inverse of MAUI Blazor hybrid. Which is exactly what we want, exactly in the opposite direction. Blazor components being mapped to MAUI. Which gives you full on web, desktop, mobile across the board, BUT, in the backwards direction. Everything will be HTML looking and functioning.

The problem I'm seeing with the CSS approach, is to manipulate the DOM in a browser, you need JS(and anyone can correct me if I'm wrong here). I wish JS and typical web development would just go away completely, and it be a normal language across the board with WASM not even requiring JS interop and having direct DOM manipulation access, but maybe that'll happen in the future; Where browsers are just a UI host to render whatever cross platform framework, or even a UI host is created that runs on every OS to run cross platform native code in a standalone window. Kind of like a native ElectronJS.

Back to the DOM manipulation. You would need JS to manipulate the DOM so you can reapply different styling at runtime to DOM elements. Which is what you need if you want to resize things at all, change colors, set text, hot reload, any kind of typical UI manipulation, etc. That means there would have to be a transparent JS interop layer MAUI wraps. Opposite of Blazor where you deal with both yourself since you have to make components, or download third party component libraries. This would be an OK start to getting off the ground with MAUI web until a better option came along.

Before any of that can happen, you need CSS/HTML together to build UI elements. Once that happens, THEN you the CSC.exe to spitout WASM instead of CIL, I would imagine, so that it ran in WebAssembly. Which all of the dotnet framework has WebAssembly framework assemblies that run in WebAssembly due to Blazor, so that takes care of that part. You'd then need web assembly specific code in the MAUI handlers(I think, which also could just be hardcoded prebuilt WASM assemblies that already exist?), which would allow WASM to talk to JS however the WASM API allows that to get you to manipulate the DOM, so that whatever CSS style sheets(premade i'd imagine), for say, a Button.css, could have their color, corner, etc properties modified when that stuff is changed by code in the app.

[martin-braun]

@emceelovin Yes, with WebAssembly, you still need a JS host to access the DOM, but it can be minimal, so you only pass accessor logic from the WebAssembly to the JS host and do the rest (your code and framework code working with UI) in WebAssembly. I think this is the best it can get.

There is no alternative to HTML for WebAssembly, except drawing on a canvas. The problem I see on a canvas is that it's not native. A traditional website would feel like an app, unless you implement all native functions of the browser such as right clicking anywhere or marking any text.

Thus, your final conclusion is really good and it helps to get the head around the issue. I think this is really what needs to be done, unless there is any other way I'm unable to see right now.

Kudos. I appreciate your input and I hope the Microsoft team will read your statement.

[emceelovin]

Yes, with WebAssembly, you still need a JS host to access the DOM, but it can be minimal, so you only pass accessor logic from the JS host to WebAssembly and do the rest (your code and framework code working with UI) in WebAssembly. I think this is the best it can get.

That's all we'd need and all I would want honestly. The rest of the app logic will live in web assembly execution. That's why I mentioned if the handlers were the only WASM <-> JS code, that should be fine then. All of the other application logic would live in the web assembly(program?). It seems like to get it off the ground going in a basic fashion, for now, there needs to be WASM handler assemblies that allow access to DOM manipulation through JS. Since that's the only way you can manipulate it. Through the WASM -> JS interop layer. Once that happens, it shouldn't be hard or take too long to makeup style sheets for each control. A lot of stuff for web already exists thats equivalent to Grid and FlexLayout(FlexBox is the most common web layout it seems). How hard can it be to make a button also?

To be fair, and I don't know if it's just because of the hardware I have, I have had zero issue with flutter and rendering to a canvas, but I could see how that would be an issue on slower hardware. I just didn't think an HTML5 Canvas would be slow. I think they're always hardware accelerated with the latest browsers? I always thought it was really cool when Canvas came out. It's basically like GDI on the web in a way. Which allows things like flutter to exist. It's just through HTML, and like I mentioned before, I hate web HTML and HTTP. I can't wait for them to become obsolete. Direct access to the DOM and even a direct version of Canvas in web would be great, but then you're just getting into a cross platform framework host(like ElectronJS) like I mentioned, but I totally get what you're saying. All good points for sure.

Thus, your final conclusion is really good and it helps to get the head around the issue. I think this is really what needs to be done, unless there is any other way I'm unable to see right now.

Like you mentioned, there are only two ways. Canvas or WASM assemblies to use JS to manipulate the DOM. There are a lot of things people have to consider that are static. Most you mentioned.

1. To manipulate the DOM, JS is required. Non negotiable.
2. Handlers(which are static I believe in code and controls are ran through them) need to be WASM assemblies(shouldn't be hard at all to build them since dotnet framework already exists in WASM assemblies. Theoretically could just take the handler code and run it through whatever was used to build the framework assemblies in WASM) which allow JS interop/UI.
3. Style sheets would have to be made to style existing HTML UI elements to represent the elements in the MAUI UI as best as they can, or composite UI elements to map to something that doesn't exist on web itself

All seems doable though, so I'm not sure what will happen in the future. I have a project of my own right now, but I wouldn't mind trying to figure out how to at least get MAUI to build to WASM without any functionality at all. That way I could try to make the simplest element, a Button.

Kudos. I appreciate your input and I hope the Microsoft team will read your statement.

I'm with you and all of the others on wanting web on maui. NOT in the Blazor fashion.

[legistek]

This is all true, but Microsoft publishes a very robust set of Fluent UI controls for React which they use themselves in Office online, which would be a perfectly good place to start.

[akhanalcs]

Please give us WASM/Web target in MAUI!
@davidortinau

[evgeshkastrong]

also dream about it

[n8allan]

I too would like this. It seems like the result would overlap significantly with OpenSilver, would it not? If nothing else, it might be worth referencing as a pixel precise platform for representing XAML in the HTML DOM on WebAssembly.

[minze-it]

I would like this too!

[ParadiseFallen]

+1 there. uno.platrorm looks cool. and it would be awesome to see rendering xaml into html and running in browser

[jcgalveza]

WASM is the missing piece in .net maui
Please, give us WASM in .net maui.

[SalimiHabib]

I am a fan of WASM in Maui

A big yes for WASM in Maui

[chrisk414]

To MS,
I'll hold MAUI adoption until it supports WASM!
You even said ".NET loves WASM" recently.
Isn't MAUI a .NET?, or it has become a foster child already?

Or please give a reason why MAUI won't support WASM in the future.
Thanks.

[stevexuzeta]

When will MS support wasm in maui? I focus on maui for a long time, but it does not have web/wasm and linux support even plan. It seems that MS does not want any UI support for linux. I feel confused and disappointed.

[Xyncgas]

#17015

[MarkBrainfire]

Now that Uno Platform supports 3rd party Maui controls hosted in Maui Islands, there's all the more incentive to get WASM working.
Microsoft should pay the team at Uno to collaborate with the Maui team to get it done.

[joseluisct]

Please give us MAUI Wasm target! +1

[malachib]

I left C# because of JavaScript (good luck finding a C# job that doesn't require JavaScript). MAUI + Wasm could bring me back!

[ParadiseFallen]

well. good luck coding on js then. it's not a problem to find a .net job

[Xyncgas]

.NET would be not a thing in ten years, prepare to see language support directly in browsers' JIT compiler
Using browser to build UI is the 75% future of all programming language

[malachib]

well. good luck coding on js then. it's not a problem to find a .net job

We are not understanding one another...
C# Jobs nearly always require a ton of JavaScript, and I hate writing in JavaScript. So I had to leave C# too. It is very much a problem to find .NET work which doesn't involve JS.

[ParadiseFallen]

just search for backend devs? no?

[Xyncgas]

I suspect people are writing javascript in backend as a .NET developer nowadays, because CMS integrations are spaghetti codes

[malachib]

just search for backend devs? no?

That used to be a dead end. Search engines may have improved so I'll try that again. Somehow it hadn't occurred to me, so I appreciate the suggestion

[Xyncgas]

For me, running inside wasm means at least I can run inside a browser which is going to use browser to fetch things and enjoys the benefits of browser caching

[legistek]

I made a POC for a Webassembly Xamarin Forms target years ago:

https://github.com/legistek/Xamarin.Forms.Platforms.Webassembly

If it works on Xamarin Forms it would work on MAUI. It's 100% feasible.

No matter what Microsoft might tell you, this was a business decision on their part not to support this. I can only speculate that this is related to Office - being a cross platform suite with virtually identical desktop and web versions - and not wanting to put out a development platform for the world to use and potentially make apps that can compete with it.

And why do I think this? Because I did take the concepts in my POC and we turned it into a proprietary product that I don't want to give away :) (And that's also how I know it's 100% possible).

[minze-it]

You turned that PoC into a proprietary product? That's very interesting! Is it production ready? You got a web page? Can we try and possibly buy that?

[legistek]

Sorry I didn't mean to be a tease. It's an actual commerical application I'm talking about, not a standalone framework. And it's not MAUI or even XAML-based either, although it is MVVM and based on techniques in that POC I did publish. It's totally nonstandard and also probably not something anyone else would want to use. :)

The point is that it's 100% possible for write-once-run-anywhere to actually work on native and web. Microsoft does it with Office. We do it with our product. Heck even Uno and Avalonia do it now. I'm sure there are many many others. So the decision by MS not to make pure web a MAUI target was 100% business related and not in any way based on technical hurdles or lack of demand.