Thanks a lot for your message.
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.