Discusssion: Web Assembly support - clear road map

[juanfranblanco]

In the interesting of having the full cross-platform capability of XAML, web assembly should be considered as a platform to support.

Any enterprises which have done an investment on Silverlight as LOB will now have a clear path to transition their applications to the web, desktop, store and mobile.

It has been demonstrated already how this will work using Razor https://github.com/SteveSanderson/Blazor using a subset / older version of .net. Unity3d already converts to webassembly using IL2cpp.

[birbilis]

btw, good paths for publishing existing Silverlight apps to the (desktop-only) Store would be:

• allow Hosted Web Apps that contain Silverlight (using IE11 engine with Silverlight preinstalled instead of Edge when web manifest contains such meta-info)
• allow Desktop Bridge to wrap and publish to the Store single page WinForms/WPF apps with WebBrowser ActiveX control to host a remote Silverlight app and show it using IE11 engine. Probably can do the WebBrowser ActiveX control already, but not sure if it can wrap (pseudovirtualize) the Silverlight installer (would be best if it was preinstalled in Windows)
• allow Silverlight OOB (=Out-Of-Browser) apps to be wrapped as Store apps using Desktop Bridge (there is a chance it can do it already via some manual effort). Could even have the Store allow uploading a Silverlight .XAP that has OOB support in its manifest file and do the wrapping online. OOB apps were running out of the browser anyway.

note that not all apps can be rewritten extensively after they're paid (by a client or funded by a grant etc.) and published, but if effort was small to publish to the Store one could do it, or find funding for it more easily.

[juanfranblanco]

Yes good points about SL, the issue is that the life of these apps is already limited, and will require rework. If the rework warranties cross platform / cross browser Xaml standard (Xamarin.Forms including web assembly) it is a bigger sale. At least web assembly is warranted to last.

[Mike-E-angelo]

At least web assembly is warranted to last.

Hopefully. 😄 It still requires the collaboration and agreement between MSFT, GOOG, and AAPL. You know, something that has never, ever transpired in the history of tech, that's all. 😄

Still, nice to see projects like Blazor lend credibility to this, even if its .NET runtime is something that hasn't been touched in 6 years. (Don't fret though, Mono is being ported to WASM as well, which should allow .NET Standard-compliant applications run in a browser like they do on iOS & Droid. 👍 )

Btw, nice little conversation going in here about this, too: https://github.com/Microsoft/xaml-standard/issues/57

[juanfranblanco]

Yes, the Razor sample uses the DNA subset.. if you look at it there is not much to it. Mono / netstandard route will be the best. (But if nothing happens, it is a great starting point ;) )

IMHO, I think both initiatives are needed Razor and Xaml.

Razor compliant web assembly would allow current .Net web developers to use their skills, they might even be able to port current applications front end and back it with rest api calls probably wrapping their service layer.

The Xaml standard route (and obviously a standard backend like Xamarin.Forms) would allow for the much needed (regardless of the language) cross platform portability including web. You might even get Razor too :).

Re agreement, I think everyone will cooperate, there is no reason to kill plugins now (the mobile market is saturated), and web assembly would allow pushing other markets, even VR.

Great point about those threads, I have been seen your pushing on the subject over years now?

[juanfranblanco]

In perspective, we have been wasting our lives during 20 years. Java applets, Activex, Flash, Silverlight, just needed earlier standardisation and bandwidth.

[Mike-E-angelo]

I have been seen your pushing on the subject over years now?

Pushing, whining, complaining, denial, anger, bargaining, depression, acceptance, same difference. 😆

The irony of Silverlight is that it originally was designed so that you can interface with it via (standardized) JavaScript, but via the ominous (non-standardized) Active-X control which, of course, led to its demise. Funny though that this didn't kill Flash which still lives on with that very same ominous (and security vacant) vehicle. Nonetheless, we do have the promise and appeal of WASM starting to crackle and gain mind share. If it sticks this will all be a distant, bad dream someday. 🙏 praying 🙏 for this to be the case.

[juepiezhongren]

@juanfranblanco ola, amigo. There is an issue which we should expect, how big mono runtime will be like, considering everytime a webpage loaded the mono bytes are to be transferred from the server. So, shall another aot with a lot of restrictions? I don't know much about DNA, is it a aot solution? Te ruego explicaciones.

[birbilis]

@Mike-EEE Silverlight was a Netscape plugin (NPAPI) too since it worked on Safari and Firefox, on Internet Explorer after some version you couldn't have such, had to use COM/ActiveX (probably for more security). However you could make a DLL that was both ActiveX control (exported DllRegisterServer etc.) and an NPAPI plugin. Not that you really needed to reuse a single DLL, but some people were doing that too.

So using ActiveX is unrelated to the demise of Silverlight. Apple's war on plugins was and Google's switching to another plugin/extension API for Chrome with Mozilla (aka Netscape) eventually killing their own plugin API.

[birbilis]

Btw, UWP under the hood is COM (maybe COM+ stuff too) I think. ActiveX was a binary component spec and related services over COM. Very well designed and covering stuff that people who rewrite everything haven't yet bothered to look at

[birbilis]

regarding size of Mono runtime for WebAssembly and the different options for shipping such a thing via WebAssembly (e.g. compiled IL, interpreted IL etc.) see Miguel De Icaza's comments at: https://www.reddit.com/r/programming/comments/6swm9j/mono_begins_using_cf_to_webassembly_with_a_look/

[juepiezhongren]

@juanfranblanco, i believe mono-wasm could be called silverlight x.0

[stonstad]

WebAssembly support would be truly awesome.

[dotMorten]

WebAssembly support would be truly awesome.

Sure, however that's completely out of the scope of the XAML Standard. The XAML Standard is not about platform implementations, but what a platform implementation should include to call themselves XAML Standard compliant.

[stonstad]

@dotMorten You are certainly welcome to your opinion. It is completely valid to assert the idea that the XAML Standard working group and Microsoft should give serious consideration to WebAssembly as a target platform for successful adoption and reach. Thanks.

[dotMorten]

@stonstad This isn't really an opinion. It's no different than .NET Standard isn't a platform either. It's a spec that dictates what .NET Core, .NET Framework and Mono needs to implement. Should the XAML Standard working group give serious consideration to this? No. It's not their place to do that. They need to focus on what's the minimum common set Xamarin.Forms, UWP (and perhaps a future WebAssembly version) should support. Should Microsoft give serious consideration to this? Sure why not, but this repo just isn't the place for that.

[birbilis]

for those interested in the subject: CoreRT in WASM https://github.com/dotnet/corert/pull/4480 https://github.com/dotnet/corert/blob/master/Documentation/how-to-build-WebAssembly.md

[stonstad]

Thanks birbilis. I encourage open discussion of XAML Standard and its intended purpose and platform targets, as that is the purpose of this thread.

[birbilis]

note though, that the XAML standard indeed should be expected to deliver a spec, not implementations by itself

[dotMorten]

I encourage open discussion of XAML Standard and its intended purpose

And I encourage we don't overload the working group with a gazillion off-topic discussions :-) (Something that this repo suffers really badly from already)

The goals of the standard is already described and fairly clear. The issues are for talking about part of XAML should then get included within that defined scope. Supporting new platforms are definitely not part of that scope.

[juanfranblanco]

Very good point @dotMorten on what the Xaml Standard is about. The specs. Still, there is not a better place to air the needs (and discuss) of a wasm platform with support for Xaml and its (future) standard. WASM in itself will have different capabilities to adhere and challenges due to its browser sandboxing. So having this discussion here, which tracks any advances of .net towards that direction (and hopefully a road map) it will ensure that when implemented it will take into consideration the very important Xaml Standard spec that is being delivered in this repository.

[juanfranblanco]

I also understand the issue of having different discussions, if you are a maintainer of this repository you could label them so they can be easily filtered out.

[MelbourneDeveloper]

It would be awesome to have a XAML Standard compliant platform to build web apps with. The Avalonia project (https://github.com/AvaloniaUI/Avalonia) would be a really good contender to sit on top of Web Assembly.

[zezba9000]

If HTML was an official target of Xamarin.Forms... that might be an option. Working demo of .NET with XAML in browser: http://praeclarum.org/post/171899388348/oouiwasm-net-in-the-browser

[juanfranblanco]

Oh yes, and don't forget Uno http://platform.uno/Playground/index.html. But still there is not a clear XamlStandard.. Uno is based on UWP.

It will be great or ooui to be officially supported I agree. Well, all the Xamarin "branches" gtk#, wpf, mac should be all officially given more love so frameworks can support them (ie MvvmCross)

[stonstad]

It's all about time to market. The delay caused by the unobtainable desire to build a perfect XAML Standard specification threatens the creation of a viable cross-platform API. Microsoft needs to win in cross-platform. Microsoft created a universal platform and despite the acquisition of Xamarin they are far from winning. The GitHub issues and associated conversation here is emblematic of the lack of strategic vision within Microsoft.

[YAJeff]

I started this in my free time: https://github.com/XamlEngine/Samples Example: http://www.xamlengine.com

It's rendering Xaml natively in the browser using WebAssembly & WebGL. It exposes the Xaml to any language that can run in the browser/WebAssembly.

Anyone want to help build it?