Implications of WebAssembly and Standard XAML.

tomcat
Posts: 2
Joined: Mon Nov 13, 2017 11:29 am

Implications of WebAssembly and Standard XAML.

Postby tomcat » Mon Nov 13, 2017 11:53 am

Links included below.

I am currently evaluating your C#/XAML product and my initial experiments are encouraging. I am wondering, though, about the consequences in a year or so of C#/XAML -> JS/HTML.

Specifically, my understanding is WebAssembly seems destined to be the future of web programming; currently just C++ compiles but the GC languages (C#, Java, etc.) will follow, running much faster than JavaScript. Then .NET will follow. And maybe even Standard XAML will be ported, though that would be a couple years out if ever.

If this comes to pass, it seems transpiling C#/.NET will be at a severe performance and infrastructure disadvantage. Assuming this is the future, I could see your product still very useful, but eventually replacing your transpiling and pseudo-.NET framework with the "standard" issue from MS/Xamarin/Open-Source combined with your XAML magic.

Have you considered these factors? Would you please help me understand how using your tool would not be signing up for some form of obsolescence?

Thanks,

Tom

https://www.infoworld.com/article/3217704/web-development/whats-new-with-webassembly-portable-code.html
https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/
https://medium.com/@mbebenita/webassembly-is-30x-faster-than-javascript-c71ea54d2f96
http://www.mono-project.com/news/2017/08/09/hello-webassembly/
https://blog.xamarin.com/glimpse-future-xamarin-forms-3-0/

JS-Support @Userware
Site Admin
Posts: 1142
Joined: Tue Apr 08, 2014 3:42 pm

Re: Implications of WebAssembly and Standard XAML.

Postby JS-Support @Userware » Tue Nov 14, 2017 12:46 am

Hi,

Thanks a lot for your message.

tomcat wrote:Specifically, my understanding is WebAssembly seems destined to be the future of web programming; currently just C++ compiles but the GC languages (C#, Java, etc.) will follow, running much faster than JavaScript. Then .NET will follow.
(...)
Assuming this is the future, I could see your product still very useful, but eventually replacing your transpiling and pseudo-.NET framework with the "standard" issue from MS/Xamarin/Open-Source combined with your XAML magic.


What you described is exactly our view of the future.

In a few years, our product will:
  • be based on standard .NET for WebAssembly, for excellent performance
  • still be capable of transpiling code to JS for older browsers compatibility
  • provide the full XAML stack, which we are going to keep improving and do major performance optimizations in 2018
  • provide UWP, WPF, and Silverlight (subset) compatibility for people migrating existing applications
  • be compatible with XAML Standard
  • have more and more 3rd party extensions, especially C#/XAML libraries that are implemented using existing JS libraries under the hood
  • keep providing the Simulator (which will be further improved before the end of 2017 for latest HTML5 features compatibility), for easier C#-based debugging inside Visual Studio, as well as runtime HTML-based XAML inspection.


tomcat wrote:Would you please help me understand how using your tool would not be signing up for some form of obsolescence?



Applications written today with our tool will keep working "as is" in the future, as backward compatibility will be one of our priorities.

Furthermore, as you mentioned, the industry appears to be moving in the direction of having the .NET Framework run natively in the browser (by "natively" I mean in binary compiled form, without JS, using WebAssembly), including eventually the XAML stack. At that moment, whether you will keep using our product, switch to a competitor's, or switch to a technology provided by Microsoft, you will still be able to keep your C#/XAML code. In other words, I believe that writing C#/XAML code today for the browser is the best approach because C#/XAML will likely become the preferred way to develop web apps for developers in the Microsoft ecosystem in the future.

Thanks again.

Regards,
JS-Support

TaterJuice
Posts: 147
Joined: Thu Mar 16, 2017 5:40 am
Contact:

Re: Implications of WebAssembly and Standard XAML.

Postby TaterJuice » Wed Nov 15, 2017 8:07 am

Thank you, @tomcat and @JS-Support for the excellent, educational post.

Mark Stega
Posts: 12
Joined: Wed Oct 07, 2015 2:10 pm

Re: Implications of WebAssembly and Standard XAML.

Postby Mark Stega » Tue Apr 17, 2018 1:33 pm

The body of the reply from @JS-Support should be incorporated in the Roadmap...

Mark Stega
Posts: 12
Joined: Wed Oct 07, 2015 2:10 pm

Re: Implications of WebAssembly and Standard XAML.

Postby Mark Stega » Fri May 04, 2018 6:24 am

@tomcat

The future that you suggest might be closer than expected. There is a small project called OOUI (Object oriented UI) that has a toolchain that implements C#/Mono/Xamarin Forms on wasm. Take a look at https://github.com/praeclarum/Ooui for details. I've been developing a Xamarin Forms app for UWP, testing on the desktop, and then moving the code over to my wasmproject. So far, my nascent application is running identically on the Windows desktop as a UWP app and in the browser using wasm.

Although not yet ready for production use, and lacking any decent method of debugging on the wasm side, it is none-the-less a great technology demonstration.

JS-Support @Userware
Site Admin
Posts: 1142
Joined: Tue Apr 08, 2014 3:42 pm

Re: Implications of WebAssembly and Standard XAML.

Postby JS-Support @Userware » Fri May 04, 2018 7:37 am

Thanks.

Yes, we are aware of it and we are doing a PoC with WASM too.

Here is a PoC using CSHTML5 in conjunction with Blazor running in WebAssembly!

http://blazorsample.azurewebsites.net/?20180416

(please be patient while it loads, as it currently takes up to a minute)

Stay tuned!

Mark Stega
Posts: 12
Joined: Wed Oct 07, 2015 2:10 pm

Re: Implications of WebAssembly and Standard XAML.

Postby Mark Stega » Mon May 07, 2018 10:52 am

That's a nice PoC; The only difference that I see from a local instance of the Showcase running is that the Azure hosted version has a display issue with the 1st binding demo (and lesser performance on page transitions). So this is very promising. I know that Blazor is an experiment, not a supported tool, but is does seem that the thinking is along parallel tracks. My issue with Blazor is that it doesn't take you out of the HTML5/CSS pit of despair. After building very nice LoB applications for years using XAML the combo of HTML5/CSS feels like a child's toy. I know that some great applications (GitKraken and Visual Studio Code come to mind) using that tech show that it isn't hopeless, but I still prefer the niceties of a XAML environment.


Return to “General Discussion and Other”

Who is online

Users browsing this forum: No registered users and 25 guests

 

 

cron