Any plans for taking Xamarin Forms to the Web now that WebAssembly is here?

[rxelizondo]

I know it is easier said that done but I was wondering if taking Xamarin Forms to the web is on the radar or not. It’s my understanding that WebAssembly could help make this a reality with relative ease. It also helps that all the work revolving around the Blazor project could probably be reused to help bring Xamarin forms to the Web (just a guess).

So, have you guys consider doing this?

Thanks.

[tpetrina]

WebAssembly means that the code compiles into JavaScript. While this can be done for business logic, what you mean is creating a web backend for Xamarin.Forms. This means that all the semantics of the Xamarin.Forms controls are mapped to DOM elements which is quite tricky.

Take a look at https://github.com/praeclarum/Ooui.

[rxelizondo]

Actually, creating a back-end for Xamarin.Forms that is mapped to DOM (HTML) elements is something that I think should be avoided (with a passion!). I am thinking more along the lines of taking the HTML Canvas control approach, basically, a canvas control that takes over the whole browser screen and draws the form elements directly into it (no other HTML / CSS involved). This is much the same way (I think) WebAssembly games are being developed. So if you can draw a sophisticated and highly interactive game on a HTML Canvas then drawing form elements should be no problem whatsoever.

Assuming that the Web Browser supports WebAssembly then no translation to JavaScript should be necessary so all this should be super fast.

I will look into the link you mentioned, however, if Ooui maps to HTML controls then I don't think that is the way to go. In my opinion, the web browsers needs alternatives to always relaying on HTML / CSS technologies for user interface design. HTML Canvas is a potential answer.

[adrianknight89]

I've been out of the loop with web development for a while. Is drawing UI controls on Canvas a recommended approach now by W3C instead of leveraging existing HTML controls?

...

OK, some discussion here: https://stackoverflow.com/questions/6856953/does-it-make-sense-to-create-canvas-based-ui-components

Looks like a big downside is search engines cannot crawl Canvas content.

[rxelizondo]

Thanks for the link @adrianknight89. Very interesting to see that this topic have been discussed for years now.

Assuming that no real technical limitations exist for using the Canvas control for this purpose. It seems to me that most if not all of issues that people are complaining about can be easily solved. I may be wrong, but it sure looks like it. But even if they are hard or impossible to solve, as others pointed out, public and internal web apps are very different animals and they should not both abide by the same silly rules.

As far as I can see, if people need to be compatible with web standards they should stick with HTML / CSS, however, if you don’t need to be compatible with web standards, you should be free to choose what best fits your needs, this includes utilizing progressive and innovative frameworks that are actually built from the ground up to be feature rich and highly interactive user interfaces. And if it takes drawing to a Canvas to achieve that so be it. Not sure why some people make such a big fuzz about it, if they don't like it they don't have to use it.

[migueldeicaza]

Hello,

We would love to reuse the work from Frank Krueger has done on Ooui on the server and bring it to the webassembly client.

So the answer is yes - we want to bring this, will close this to clear the backlog of bugs, as we will also be tracking this separately.

[leo-mck]

@migueldeicaza Please, please do not do this. I am all for supporting multiple platforms but we first need a stable, confiable product on the platforms it already support. Each new stable xamarin.forms release bring along lots of errors, regressions and problems - some of them that only shows on more complex apps so they get under reported. See this as an example:

#1332
#1736

This kind of error only affects people who are not doing small demo apps with xamarin.forms so we can't just drop it and look for another technology. But at this point, since this is going for a long time, it is really hard to recommend it to anyone doing mobile development.

[John0King]

@migueldeicaza @leo-mck Can we implement Xaml in JavaScript/Typescript first , today vue and react are very popular in web , and they are do similar thing like Xaml (component, template etc) , and if there is a Xaml framework in Javascript/Typescript and that will help Xamarin.Forms go to web someday later .
I'm thinking about write Typescript class's that controls HTML Element ,

class Button extends UserControl{
    UserControl[]|string Content
    render(){
       return <button>{this.Content}</button>
    }
}
class TextBox{}
class StackPanel{}
class Grid{}

let btn = new Button();
btn.Content = "hello";

[plamen-i]

https://github.com/praeclarum/Ooui now started adding support for running Xamarin.Forms on the client on top of WebAssembly - see README.md.
You can try it here.

[legistek]

@migueldeicaza are there plans to make a Blazor backend for Xamarin Forms? I've been playing with Blazor a lot lately and this seems very doable in the near future. Would be interested in contributing if so.

[migueldeicaza]

I do not have any plans, but there are already two versions of Forms that run on the web, one runs with WebAssembly and one runs with ASP.NET Core. I imagine that the former is what you are thinking of, both Blazor and the WebAssembly version can run side by side.

[legistek]

@migueldeicaza you're referring to Ooui, right? Yes very promising stuff; just wasn't sure if y'all were contemplating an "official" project of that nature. Ooui WASM doesn't use Blazor, and though they both run on top of Mono, I think Blazor has a really nice approach to the way they render C# components into the DOM that would make it a natural fit as a Xamarin Forms backend.

[montyclt]

What about the idea of creating two Xamarin.Forms backend, one based on DOM + CSS and other based on whole browser canvas?

I think canvas backend can be better for developing web applications because can reuse xaml style, but DOM + CSS can be better for public webs because search engines can index the content.

Any idea about routing pages?

[legistek]

Just to try to re-ignite this conversation, I have to say I'm a bit surprised there's not more interest in this (either official or unofficial). Being able to use a single code base for server, native clients, and web clients - using a language that doesn't suck - seems like the holy grail for .NET developers. And yet, Ooui doesn't really seem to be going anywhere. Avalonia won't go to the web anytime soon (AvaloniaUI/Avalonia#1387) and there doesn't seem to be any interest from the Xamarin developers on going this route. (#4888). Conversely, the Blazor team has no interest in using XAML. (https://github.com/aspnet/Blazor/issues/389).

Did Silverlight cause such PTSD, like the cold fusion debacle of the 80s, that no one wants to touch this again? Is the Javascript mafia holding peoples' families hostage? Why is there so much resistance to convergence between web and native app development?

[GalaxiaGuy]

I'm not sure there is a lack of interest as such - I don't think there would be much argument that this is a bad idea in theory. But the Xamarin team (and Xamarin Forms in particular) seem to be stretched quite thin and supporting everything they're already doing is a priority.

For example, if you look at the discussion at the end here (#2415) there are already people who feel Xamarin is trying to do too much as it is.

[legistek]

Good point. I guess my question is more directed to the Microsoft enterprise rather than just the Xamarin team. Microsoft has taken lots of positive steps in this direction but seems to keep stopping just short of fulfilling the vision. For example:

First they launch the "universal" Windows platform thereby establishing XAML as the preferred development platform for apps, but only on Windows 10. (Notably, though, they diverged the XAML syntax from WPF for reasons I will never fully understand, making porting very much non-trivial).

Next they acquire Xamarin adding .NET/XAML capabilities for other platforms. This would have been the logical point to start porting UWP to the Xamarin native platforms, but that obviously isn't happening. And of course Xamarin's XAML syntax doesn't play nice with WPF or UWP. So in terms of cross platform development, we're really no better off than we were before the merger. (By no means is this a knock against XF. But one has to concede that full UWP on all platforms would be a huge leap forward).

Then they begin Blazor - .NET on the web client - and are officially launching it with .NET Core 3.0. Yet that doesn't use XAML at all, In fact, Blazor's PM said that they were "specifically not targeting compatibility with WPF/UWP/Xamarin.Forms" (https://github.com/aspnet/Blazor/issues/374). There even seemed to be significant opposition to the idea expressed by many community members. (https://github.com/aspnet/Blazor/issues/389).

Finally, they decide to open source WPF (the inspiration for Xamarin Forms and UWP, yet tech that's 15 years old and only runs on Windows desktop), and also make it part of .NET Core 3.0. Yet once again they say specifically they are not interested in porting it to other platforms. "We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF." https://github.com/dotnet/wpf/blob/master/Documentation/contributing.md.

So we have FOUR technologies, each excellent in their own right, but not only are there no plans to bridge them, but there is declared opposition in some cases. It often feels as though there are two competing forces at work: one that's trying to spread .NET to every facet of the computing world, and another that is trying to protect Windows against competition from other OS's and the web. Otherwise I can't make sense of it.

All that being said, I give great credit to the Xamarin team for (among other things) building a framework that can be ported to other platforms with relative ease. By far this team has been the most committed to this vision out of everyone and I understand their need to stay focused and use their resources wisely. I also laud Microsoft at large for embracing open source and other platforms under Nadella's leadership. They've at least enabled the .NET community to take on this task. I hope the community will do so with the same drive as (though hopefully higher quality than) the web and JavaScript world.

[charlesroddie]

@legistek XAML is only an optional markup language. I think it's a red herring.

It's reasonable to have Xamarin.Forms target the web, and Blazor looks promising.

It would be nice if people in the community are interested enough to get a Xamain.Forms.Blazor backend working. But it obviously doesn't make sense for Xamarin to devote resources to it right now when Blazor is still incomplete and in flux and when Xamarin is very overstretched. I am sure when Blazor works, assuming it works well, Xamarin.Forms.Blazor will happen.

[weitzhandler]

Until Xamarin.Forms runs as WASM, I'll use Uno Platform for all projects that require web.

[legistek]

Yeah Uno's really interesting, but unfortunately as they point out the interpreted mono runtime is horribly slow.

One of the reasons I opened #4888 was so we could specifically talk about Razor Components (fka Blazor) which is now officially supported and will be part of ASP.NET Core 3.0. Razor Components does not equal WebAssembly. The .NET code runs on the server and UI interaction occurs over SignalR. WASM remains promising for the future, but MS has deemed server-side Razor Components ready for primetime. This thus seems like a good time to revisit the idea of an XForms backend for the web that would use the officially supported release-ready technology.

[legistek]

I've started a skeleton proof of concept. Encourage anyone who's interested to see what was possible after a day and a half of work!

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

[amirvenus]

This is particularly useful for noobs like me who know more XAML than CSS.

I would love to see it merged in the master branch one day.

[weitzhandler]

This is particularly useful for noobs like me who know more XAML than CSS.

I know HTML & CSS pretty well (I use SCSS), and man, does it suck.

[JeroMiya]

I think a Blazor backend for .net forms would be a good base for a port, vs a Ooui or Canvas based solution/etc... as it already comes with both client-side wasm and server-side remote-websockets support with a shadow DOM implementation. No sense reinventing the wheel.

As for priorities, I think the web as a platform and target for Xamarin.Forms should be a very high priority. Fewer and fewer clients are asking for mobile apps and many more are asking for mobile friendly web apps due to the massive amount of friction in how enterprise mobile apps need to be deployed, particularly on iOS. And despite being one of the three major supported platforms for Xamarin.Forms, I have literally never had a client ask for or say they were interested in a UWP app even if we offered one, so certainly I think a web target for XF should be at least as high a priority as UWP if not more so.

[BradChase2011]

Has anyone tried the Uno 2.0 WASM Xamarin.Forms target?
https://www.prnewswire.com/news-releases/uno-platform-announces-version-2-0-of-cross-platform-development-platform-300921202.html

[seankanderson]

Why is this closed?

[legistek]

From earlier in the thread:

"So the answer is yes - we want to bring this, will close this to clear the backlog of bugs, as we will also be tracking this separately."

[rxelizondo]

Possibly related: https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings-experiment/

[legistek]

I just want to reiterate that while no one at Microsoft appears to be working on this, at least publicly, there is absolutely nothing stopping the community from doing so. I posted a proof of concept and while I don't have the bandwidth to complete it, it's 100% possible.

[seankanderson]

Totally related:

https://visualstudiomagazine.com/articles/2020/01/15/blazor-mobile.aspx?oly_enc_id=1551B8087834I0F&m=1

Xamarin Forms literally blew up and and exceeded the original scope for a reason. It is proven now and the strides have been huge over these last few years. Leaning into this feature with real resources makes sense and aligns with Microsoft's open source cross platform cloud strategy.

[legistek]

Ok I'm extremely confused by this new announcement. Does this mean we'll finally be able to target web and native with the same code? And if not, WHY ON EARTH isn't that the top priority?

[seankanderson]

In my previous comment I wasn't at all suggesting that the XF team drop other stuff to work on this but that Microsoft should dedicate another group to this effort (XF in general, and for this feature)

[legistek]

Ok but how is this blazor bindings concept useful if you can't use the same code and markup for both web apps and native apps? Why would we want or need yet another native app development platform that doesn't work with existing code and doesn't work on the web?

[JeroMiya]

@legistek One potential way would be to write an alternative renderer for Blazor web that rendered the same object models as mobile Blazor. Alternatively, perhaps a set of the same components reimplemented for web. Then the apps could be the same on both platforms.

[legistek]

@JeroMiya yeah or better yet I could write a XF renderer for the web. Kind of like what this issue is about! :p

[seankanderson]

Ok. Forget Blazor. I was going from the logical extension of Blazor->.NET->WebAssembly. I'm talking Java Applets here. The application should start as C# and end up as a binary (web assembly). I wouldn't want my sweet native code barfed out as a document. The leap is that XF views all render as native (UWP -> Win32API) which in this case (web assembly) there are no native underlying controls. My idea is that a rendering pipeline be created that UWP/WPF apps can call instead of leaning on Win32API--standardizing on a default cross-platform client that everyone wants. Basically, UWP/WPF app that compiles and contains the code for the UI rendering and all of the other goodies of .NET shipped in a web assembly binary to the stupid browser so it can finally get out of our damn way.

Feel free to cringe at the Java Applet reference. The browsers (because of web assembly) are finally able to run applications. Microsoft is currently taking peoples' Blazor/.NET code and shipping it as webassembly. I say we skip Blazor and go full hog UWP so we can leverage all of the existing investments and tooling and skillsets and stay focused.

https://www.youtube.com/watch?v=noG3rxt38VI&t=1054s

[legistek]

@seankanderson what you're describing basically exists now and it's called Uno.

[BradChase2011]

The uno xamarin forms wasm project works. We moved a project with over a million lines of code over to it that we already run on uwp, wpf, ios, Droid, and macos. We had to jump through a ton of hoops and we used our own custom forms library but it does indeed work, just not right out of the box. The only two things we were waiting on was multithreading (happening if not yet) and isolated storage.

But if you have the patience, time, and willingness to learn, you can make it work literally today.

[legistek]

I think I finally understand what they're going for with the Blazor Xamarin bindings. It looks like it's just a way to make native apps for people who don't like XAML, where you can do things like put code inline with the markup (which, being a XAML devotee, I personally find to be a terribly undisciplined practice and a huge source of bugs in in Angular apps).

Leaving aside preferences, if it's not truly cross-platform (same code for both web and mobile) that's IMHO a waste of resources and a HUGE waste of an opportunity.

[montyclt]

@legistek

Leaving aside preferences, if it's not truly cross-platform (same code for both web and mobile) that's IMHO a waste of resources and a HUGE waste of an opportunity.

I think that the blazor components that binds Xamarin forms can binds HTML elements too.

For example, Blazor component that binds an StackLayout forms tag, can bind an HTML div with "stacklayout" class that apply CSS to simulate the behaviour of an stack layout.

[jrahma]

This will be great +1

[Phenek]

Yep +1

[legistek]

It WOULD be great if it happened but the Microsoft enterprise has shown zero public interest in making it happen. And this Blazor mobile bindings idea is the exact opposite direction. I'm very disappointed to say the least.

[Christian-Schl]

This would be great +1