Colin Eberhardt's Technology Adventures

Can Microsoft ‘fix’ JavaScript and make HTML5 applications viable?

August 16th, 2011

Microsoft’s recent change in stance over Silverlight, promoting HTML5 as “the only true cross-platform solution for everything”, seems to have sidelined Silverlight as a niche framework. This has understandably caused a great deal of upset and confusion in the .NET development community. Despite this, Microsoft are remaining steadfast and tight-lipped about their vision for tighter integration of HTML5 into Windows 8 (and as a result just how side-lined Silverlight will be), until the BUILD conference next month. Recently I have read numerous blog posts about the difference between HTML5 and Silverlight, and how to select the right technology for your development, however almost all of them seem to ignore the great-big thorn in HTML5s side … JavaScript. In this blog post I will explain why JavaScript is such a big issue for Microsoft and what it could do to solve this.

That HTML5 will be a huge success is a given. The specification is not finished yet; the parts that are finished are not fully-rolled out, however it is making technology headlines on a daily basis. The HTML5 buzz has also been felt by both technical and non-technical managers, who you will often find asking, “why aren’t we creating HTML5 applications?”. Pointing at the unfinished specification is a little unfair on HTML5, you can reliably use a number of the APIs right now, and they will certainly provide a ‘boost’ to your current web-offerings.

HTML5 is a real mixed-bag of features, from the complex, such as canvas and video, to simple semantic markup improvements and a powerful set of CSS features. Because HTML5 provides a spectrum of features from the simple to the complex, I don’t doubt that every new site will be using HTML5 in a few years time, you simply have to add rounded borders or a <header> tag to earn yourself the coveted HTML5 badge!

One concept that underpins the HTML5 specification(s) is that of client-side web-applications. The server-side web-application, where business logic and presentation logic reside on the server, spitting out markup (sprinkled with a bit of JavaScript) are becoming an architecture of the past. The model where the server exposes business logic as a service makes it much easier to provide a front-end on a range of devices (mobile, tablet, desktop), a range of operating systems (Windows, iOS, Android), allows the effective use of client CPU, and provides a more accessible service that customers can integrate into their own application. From my perspective the most significant undertone of the HTML5 specification is that it supports this model.

The problem is that the name ‘HTML5’ can be a little misleading. Whilst the specification has much to do with HTML, it has much more to do with JavaScript. In fact, many of the HTML5 APIs have nothing to do with presentation or layout. Any article which compares HTML5 and Silverlight, without focussing on JavaScript is really missing the point.

So, what is my big issue with JavaScript?


Image used under Creative Commons Licence from Flickr

JavaScript was hastily developed as a language for scripting the web. Unfortunately it has not evolved much since its inception. Certainly the APIs that surround it have evolved, including the DOM APIs, HTML5 and popular libraries such as jQuery, however the language itself remains largely unchanged.

The big issue with JavaScript is that it is not well suited for the development of large applications, and if we shift to a model where the server provides a service which is consumed by the client web-application, this necessitates a lot of JavaScript code. I don’t want to go into all the gory details of the problems with JavaScript, but here are a few:

  • Many language quirks and gotchas (see this article on codeproject)
  • A lack of ‘familiar’ object-oriented concepts (I am not going to make the mistake of saying it is not an OO language!)
  • A lack of dependency management
  • A lack of organisational structure (namespaces)
  • A very small ‘base’ library (for example no event support, string formatting, etc…)
  • It is not strongly-typed
  • A confusing array of patterns for solving some of the above!

This list is certainly not exhaustive; rather it is just a brief illustration of some of the obstacles that JavaScript presents to the developer of complex applications. Many of the items listed above are features of the language that are advantageous in a simple, scripting context, but when used to develop complex applications they are quite troublesome.

Another issue with JavaScript is not so much the language itself, more the attitude of developers towards the language. Because of its quirks and its predominant usage as a language for scripting web-pages (with the usual “google → cut → paste” approach) many developers simply don’t bother learning how it works. I have interviewed many job candidates who list ‘JavaScript’ as one of their skills, yet they cannot describe the difference between the binding of the ‘this’ variable between JavaScript and C#/Java.

There are numerous JavaScript frameworks that go some way towards solving the above issues … filling in the gaps. This is an area that Microsoft has dabbled in before, with the Microsoft Ajax Library adding inheritance patterns and .NET style libraries (albeit with a very clumsy, verbose and convention-heavy syntax!).

Whilst the list of issues above presents a challenge to the JavaScript developer, they provide just as great a challenge to the tool providers. Many features of existing IDEs, Intellisense (auto-completion) and structured views of the code rely on language features that are absent from JavaScript. Again, Microsoft has provided some innovations in this area, with pseudo-execution of JavaScript code providing some Intellisense support. Unfortunately this neat feature, which works well if you have all your code in a single JavaScript file, is less easy to manage on a large, more complex application. From personal experience I find Visual Studio adds little value to my JavaScript development experience, I am equally happy with Notepad++ and JSLint!

So when Microsoft announces their tighter integration of HTML5 / JavaScript into Windows 8, what innovations are they going to announce?

Personally, I think if Microsoft is serious about HTML5 and its potential for client-side application development they need to do much more than just add CSS3, canvas and video support to ASP.NET. They need to support the client-side application model, where ASP.NET no longer has a stake. To fully support this they need to ‘fix’ the problems with JavaScript.

One of Microsoft’s most prized assets is Visual Studio, their investment in tool-support allows you to use the same quality tooling for developing in a wide range of languages (C#, VB.NET, C++, F#, …) and frameworks (WinForms, MFC, WPF, Silverlight, ASP.NET, …). To fully embrace HTML5 / JavaScript it has to be fully embraced by Visual Studio. But therein lies the problem, the lack of namespacing, familiar object oriented concepts, strong-typing and base ‘class’ framework makes this a challenge.
I think the worst thing Microsoft could do is add their own JavaScript framework to the mix, further fragmenting the JavaScript development experience. Thankfully they recently adopted jQuery within their ASP.NET framework, showing signs that they are willing to work with existing open-source frameworks. So if they do not announce a new JavaScript framework, what could they provide instead?


Image used under Creative Commons Licence from Flickr

Microsoft’s Scott Henselmann has published a couple of interesting blog posts about the concept of JavaScript being the assembly language of the web (or the JVM of the web depending on your perspective). His second blog post included comments from a number of JavaScript thought leaders including its creator Brendan Eich who said “Believe it or not, classical OOP languages — especially ones with not-very-expressive static type systems — are not the only way to build large apps. It can be done in JS, but it’s harder than it ought to be”.

Google have already made some innovations in this area, the first is Google Web Toolkit (GWT), which allows developers to write Java code (using the powerful Eclipse IDE), which is compiled into JavaScript. The second is Google Closure Compiler, a JavaScript to JavaScript compiler / optimiser that provides type checking via annotated comments. It is this area that I think Microsoft should be investing in.

Microsoft could create a C# (or VB.NET etc…) to JavaScript compiler with an accompanying set of .NET base-class libraries. This would significantly boost Microsoft’s JavaScript offering in that it would be fully supported by Visual Studio, providing the developer with the quality tooling that they are used to when developing using other .NET frameworks. Furthermore, the C# to JavaScript compiler could be used to compile the existing .NET base-class library giving developers a large suite of familiar libraries for use within their code. You could event support C# to jQuery using a fluent Linq-style API!

So how would this work a runtime? When used on the internet to write applications for the browser or mobile browser, a set of C# DOM APIs could be created that compile to the ‘native’ JavaScript equivalent. HTML and CSS3 could of course be included directly within the project as resources.

On the desktop there are a few options, HTML could certainly be used as the presentation technology, but there is of course another option … XAML. Microsoft has clearly indicated that XAML will be part of Windows 8, considering that Silverlight 1.0 was XAML + JavaScript, it is clearly possible to have a XAML UI backed by JavaScript code. Although, it would seem a bit convoluted to compile C# to JavaScript to interact with the UI generated from XAML when C# APIs exist already!

In summary, I feel the current focus on HTML5 whilst ignoring the very real JavaScript issue is going to cause adopters of this technology a lot of pain. Whilst this technology set gives a fantastic boost to interactive websites, using JavaScript for the development of large client-side applications is an expensive option. My hope is that if Microsoft really embrace HTML5 they look beyond simply adding tag support and tooltips and address the real problem … JavaScript.

Regards, Colin E.

Tags: , ,
Posted in Uncategorized | 21 Comments »

Talk on Cross-Platform XAML Applications @NEBytes

August 9th, 2011

I am happy to have been invited by NEBytes to give a talk on cross-platform XAML applications later this month. The event kicks off at 6:30pm on August 17th at Room 120, Claremont Tower, Newcastle University, with the event including both my presentation and a talk on Office 365 by Jonathan Noble and Andrew Westgarth. You can sign up for the event via the NEBytes eventbrite page.

An abstract for my talk is as follows:

WPF and Silverlight: Unifying the Development Platform for Desktop, Web and Mobile with Colin Eberhardt

The recent boom in mobile and tablet devices and the ubiquity of the web mean that we, as software developers, have found ourselves developing for a wide range of devices. All-to-often applications destined for the web, desktop and mobile are developed separately at great cost. This talk will look at how the XAML based technologies of WPF and Silverlight allow you to use your skills to build application for a wide range of platforms. Furthermore, with the use of simple design patterns, it is possible to share a common code-base for all three. In this talk I will cover the differences and similarities of WPF, Silverlight and Windows Phone 7, with a practical demonstration of cross-platform application development.

At this talk I will demonstrating various working examples including XAMLFinance a cross-platform WPF / Silverlight / WP7 application I have been working on:

Hopefully see you there!

Regards, Colin E.

Tags: ,
Posted in Uncategorized | 2 Comments »

Implementing a Windows Phone 7 Conversation View Part Two

August 8th, 2011

This blog post describes how to implement a conversation / messaging style application with Windows Phone 7. It covers how to style the speech bubbles and the scrolling of the conversation list view when the phone keyboard is shown.

A couple of weeks ago I wrote a blog post which described the creation of a Windows Phone 7 ConversationView, a view which renders a list of messages so that they look like a conversation. In this blog post I am going to extend the concept further, by adding an input text field allowing you to have a conversation with ELIZA, an A.I. chatterbot. This blog post will look at some of the tricky issue regarding scrolling the list of messages so that the most recent is always visible when responding.

You can see a video of this code in action below:

I hoped that I could find a decent C# ELIZA (a classic chatter application that takes on the role of a therapist) implementation on the internet, however, the only one I found was rather basic. If you know of any alternatives, pleas let me know!

In my previous blog post I created a UserControl which renders each Message instance, where the template used to render the message is dependant on which side of the conversation it relates to. Refer to my previous blog post for implementation details.

The layout for my simple chat application uses an instance of the ConversationView user control, with a text input located at the bottom of the screen:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
  <Grid contribControls:GridUtils.RowDefinitions=",Auto">
 
    <ScrollViewer x:Name="ConversationScrollViewer">
        <!-- conversation view -->
        <local:ConversationView x:Name="conversationView"/>
      </StackPanel>
    </ScrollViewer>
 
    <!-- the text input field -->
    <Grid Grid.Row="1"
          contribControls:GridUtils.RowDefinitions=",,"
          Margin="0,10,0,0">
      <Rectangle Fill="White"
                  Grid.RowSpan="2"/>
      <txt:WatermarkedTextBox Watermark="type a message"
                              TextWrapping="Wrap"
                              AcceptsReturn="True"
                              Padding="0"
                              x:Name="TextInput"
                              GotFocus="TextInput_GotFocus"
                              LostFocus="TextInput_LostFocus"/>            
      <Path Data="m 0,0 l 16,0 l 0,16 l -16,-16"
            Fill="White"
            Margin="0,0,5,0"
            HorizontalAlignment="Right"
            Grid.Row="2"/>
    </Grid>
  </Grid>      
</Grid>

Note the simplified Grid markup from the WP7Contrib codeplex project, where the string ",Auto" is used in place of the more verbose RowDefinition XAML elements.

The WatermarkedTextBox is from an article by WindowsPhoneGeek (and it works like a charm – thanks!). A simple Path and Rectangle are added to the layout so that the input field looks like a speech bubble.

When the user clicks on the input TextBlock the phone keyboard will be revealed, allowing them to enter their message. This is where we stumble upon our first major problem!

When the phone keyboard is displayed, your application content is ‘pushed’ upwards to make space for the keyboard. Unfortunately, this results in the message which the user is replying to being pushed off the top of the screen …

Because our ConversationView sits within a ScrollViewer we can scroll to push the message further down the screen, however, this would require a negative scroll offset, which isn’t possible!

To circumnavigate this issue, we can add an element which is used to ‘push’ the top message downwards so that it is located at the bottom of the ScrollViewer. The following markup adds a Rectangle which sits above the ConversationView, with two Storyboards that expand / collapse the Rectangle allowing us to push the messages down when we need them:

<ScrollViewer x:Name="ConversationScrollViewer">
  <StackPanel Orientation="Vertical"
              x:Name="ConversationContentContainer"
              VerticalAlignment="Top">
    <!-- padding element -->
    <Rectangle Width="100"
                Height="0"
                x:Name="PaddingRectangle">
      <Rectangle.Resources>
        <Storyboard x:Name="PaddingRectangleShowAnim">
          <DoubleAnimation Storyboard.TargetName="PaddingRectangle" 
                Storyboard.TargetProperty="(Height)"
                To="400"  Duration="00:00:00.3"/>
        </Storyboard>
        <Storyboard x:Name="PaddingRectangleHideAnim">
          <DoubleAnimation Storyboard.TargetName="PaddingRectangle" 
                Storyboard.TargetProperty="(Height)"
                To="0"  Duration="00:00:00.3"/>
        </Storyboard>
      </Rectangle.Resources>
    </Rectangle>
 
    <!-- conversation view -->
    <local:ConversationView x:Name="conversationView"/>
  </StackPanel>
</ScrollViewer>

We can detect when the input TextBlock receives focus to determine when the keyboard will be revealed. Using the Show / Hide extension methods I blogged about a while back, we can fire the animations which make this padding rectangle grow or shrink when the keyboard is shown or hidden:

private void TextInput_GotFocus(object sender, RoutedEventArgs e)
{
  PaddingRectangle.Show();
  ApplicationBar.IsVisible = true;
}
 
private void TextInput_LostFocus(object sender, RoutedEventArgs e)
{
  PaddingRectangle.Hide();
  ApplicationBar.IsVisible = false;
}

If we fill the rectangle so that it is visible, you can see how it pushes down the content as shown below:

The next step is to ensure that the ConversationView is always scrolled so that the most recent message is visible. The ScrollViewer has a ScrollToVerticalOffset method which can be used to programmatically scroll the content, however, because this is not a dependency property it cannot be animated via Storyboard.

Here I am using the same trick I employed for the Windows Phone 7 Jump List control, where a private dependency property that sets the scroll offset value in its change handler is used as a target for the scrolling Storyboard:

/// <summary>
/// VerticalOffset, a private DP used to animate the scrollviewer
/// </summary>
private DependencyProperty VerticalOffsetProperty = DependencyProperty.Register("VerticalOffset",
  typeof(double), typeof(MainPage), new PropertyMetadata(0.0, OnVerticalOffsetChanged));
 
private static void OnVerticalOffsetChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
  MainPage app = d as MainPage;
  app.OnVerticalOffsetChanged(e);
}
 
private void OnVerticalOffsetChanged(DependencyPropertyChangedEventArgs e)
{
  ConversationScrollViewer.ScrollToVerticalOffset((double)e.NewValue);
}

Using this dependency property we can create a simple Storyboard and DoubleAnimation that scrolls to reveal the latest message:

private void ScrollConvesationToEnd()
{
  // start from the current position
  scrollViewerScrollToEndAnim.From = ConversationScrollViewer.VerticalOffset;
 
  // set the scroll position to the the height of the contained content
  scrollViewerScrollToEndAnim.To = ConversationContentContainer.ActualHeight;
 
  // go!
  scrollViewerStoryboard.Begin();
}

And there you have it, a fully functional conversation application. Enjoy!

You can download the complete sourcecode: WP7ConversationView.zip

Regards, Colin E.

Tags: ,
Posted in codeproject | 7 Comments »