Hello,
Thanks for your message and for your interest in C#/XAML for HTML5.
Please find below the answer to your questions:
ClaudeMartel wrote:We are using some mainstream commercial Silverlight components in our application. What is the upgrade path regarding commercial components? Will the be converted? Under what condition?
In a few months we are going to release adapters for chart-related components of the main component vendors, including Telerik, Infragistics, DevExpress, ComponentOne, and Syncfusion. In other words, if your code currently makes use of chart components from any of the said vendors, you will be able to compile your code "as-is" with C#/XAML for HTML5.
As far as non-chart controls are concerned, it really depends on which controls we are talking about.
The general approach is this: If the control has an easy-to-implement equivalent in HTML/JS, we will do the same as for the chart controls, that is we will map them to existing controls so that developers can compiler legacy XAML code without making any changes. Otherwise, if the controls are missing and they cannot be easily mapped to standard controls, developers have the option to either create the missing controls from scratch by manually writing HTML and JavaScript code, or ask us to create the control for them (either vote on cshtml5.uservoice.com or request a professional service).
In the case that a component vendor provides both a XAML and a HTML5 version of the same control (many vendors are doing so), creating an adapter will be very easy.
Please feel free to post a list of all the main third-party controls that your Silverlight-based app uses so that we can look into each of them.
ClaudeMartel wrote:Should we decide to go with an hybrid solution and use native HTML5 components to build some pages, will we still be able to use C# as the programming language? How do you intend to implement MVVM in such pages?
Yes. The documentation on how to mix HTML code with C#/XAML code will be detailed extensively in an upcoming knowledge base. Below is a short example that shows how one can create a new FrameworkElement from scratch that renders some arbitrary HTML code (in the example below, the rendered HTML code is "<img/>"). Any data binding to the "Source" property in C# is reflected on the "src" property of the HTML code:
Code: Select all
public class MyCustomImageControl : FrameworkElement
{
public MyCustomImageControl()
{
// Specify the HTML representation of the control
CSharpXamlForHtml5.DomManagement.SetHtmlRepresentation(this, "<img/>");
}
// Dependency Property to store the Image Source URL
public string Source
{
get { return (string)GetValue(SourceProperty); }
set { SetValue(SourceProperty, value); }
}
public static readonly DependencyProperty SourceProperty =
DependencyProperty.Register("Source", typeof(string), typeof(MyCustomImageControl), new PropertyMetadata("", Source_Changed));
// Called when the "Source" property changes
static void Source_Changed(DependencyObject sender, DependencyPropertyChangedEventArgs e)
{
var control = (MyCustomImageControl)sender;
var newValue = (string)e.NewValue;
// Always check that the control is in the Visual Tree before modifying its HTML representation
if (CSharpXamlForHtml5.DomManagement.IsControlInVisualTree(control))
{
// Update the "src" property of the <img> tag
CSharpXamlForHtml5.DomManagement.GetDomElementFromControl(control).src = newValue;
}
}
}
ClaudeMartel wrote:What is the expected performance difference of an application compiled with C#/XAML versus a true native AngularJS/JavaScript/HTML application?
- Application startup (Framework load time): AngularJS is about 1MB before minification, whereas CSHTML5 Beta 2 is 2.5MB. After minification, AngularJS is about 150KB. We are working to minimy CSHTML5 as well (as of Beta 2 the libraries are not minified yet). In the long term, we expect to have similar startup times.
- User Interface (compared to hand-written HTML5): Since the beginning, we have made the choice to never use any JavaScript code for layout purposes. While we were tempted to do so - implementing the XAML Grid would have been much easier if we had used JavaScript -, we have decided to only use CSS because modern browsers are optimized for that. We think that the UI performance of apps compiled with CSHTML5 will be at least as good as that of hand-written HTML apps - if not better because other frameworks tend to use JavaScript for layout purposes. In the coming months we are going to release great demos with very rich UIs that show the level of performance obtained with our XAML to HTML5 converter. We have many XAML-based apps that we are going to use to showcase that performance (one of them is Olympus Farmer available at http://tinyurl.com/k3a4wlc , which is entirely XAML based and which we are planning to migrate to HTML5)
- C# execution: The C# to JavaScript compiler is provided by JSIL (jsil.org) which takes performance very seriously and generates highly optimized code. Whenever a c# instruction exists in JavaScript (C# maps relatively well to JavaScript), the compiler just translates it "as is". For example, the C# code "myString.ToLower()" becomes "myString.toLowerCase()" in JavaScript, and the C# code "MessageBox.Show(myString)" becomes "alert(myString)" (this is made possible thanks to the "JSReplacement" concept of JSIL). In some cases the generated code can be even faster than the hand-written equivalent because some operations can be done in many different ways and JSIL knows which one is faster. You can see some examples of high-performance generated apps at jsil.org (there is even a raytracer).
Please feel free to let us know shall you have any further questions, feedback, or suggestions.
Thank you again and best regards,
JS-Support