Silverlight or Html5 - from A .NET developer perspective.

Html5 vs Silverlight for the .NET developer :

If you are already invested in .NET, then you have been honing a particular set of skills for the past decade. This puts you at a position where it is difficult to favor Html5 simply because you lose some agility and sometimes this may make all the difference.

Since MIX11, there is much debate with regard to Html5 vs silverlight. And developers continue to ask, what should I use. When I try to make a decision on the technology to use and power my applications the following facts helps me consolidate my ideas and beliefs further and this is also my current state of mind.

• Silverlight is cross browser / platform

Note: This is great news if we are comparing silverlight to wpf but when compared to html5, we can agree on one thing. Html5 will be available on many more devices so it's not actually a pro for silverlight however, it's good to note that silverlight runs on those devices where it counts :

All major browsers on both the mac and windows are supported. *nix support through Novell mono moonlight, which currently lags a bit behind but don't let this be a show stopper for you. You can easily develop a secondary slim version that works for moonlight which currently fully supports version 2.0 of silverlight and one that supports 3.0 is almost complete.

Depending on the features your using, you might even be able to provide support for your application in it's full glory or perhaps with a minor workarounds if this audience is very important to you. Finally you also get to target the mobile platform wp7(Currently html5 support is lagging on wp7).

• Strongly typed languages support (c#, vb.net). Unlike losely typed languages, you will benefit greatly from compile time error checking, and many language specific features.

• Easy deployment --your compiled silverlight assembly includes the compiled code and xaml files for all your pages in your application. These files are embedded as resources and are compressed. While this is the default, it's also very flexible, meaning you can split your code in modules that can be dynamically downloaded by your silverlight application upon request. Tip: Prism is a great library if you want to benefit from modularity among other things in your silverlight apps.

• First class IDE support. Not only are you benefiting from superb IDE support for both designing your applications in expression blend while doing the development in visual studio, but your way of working changes very little if you are already a developer in the microsoft space. Note that we will soon see some pretty good IDE support for Html5 as well, so this particular con for html5 won't hold true for very long.

• Reuse existing known code patterns. Patterns and practices have been gathered over the years and are a way for us to reuse "experience" in our development. Some are our own, some are industry known patterns and practices. On the other hand, Javascript too has been around for a very long time and they too have adopted their own set of patterns and practices, but clearly as a .NET developer, with silverlight, you don't have to relearn anything. I do heavy development in both c# and javascript, so this point is pretty moot for me, however, it's an important decision maker when chosing the right technology.

• Reusing existing code --You already have existing code written for the .net framework, be it code that simply executes on the server or perhaps a WPF desktop application. Porting this code to run on the client instead in silverlight is much easier than rewriting it from scratch in javascript.

• As a web developer, you write client-side code for Silverlight in the same language that you use for server-side code (such as C# and VB), similarly you will be able to leverage the same objects you use on the server, so : generics, LINQ, Lambda, collections and many more even though only a subset of the .NET framework classes.

• IE8, 7 and 6 support is important to you because you still have a lot of clients on these browsers. This is a given in silverlight, yet these browsers currently do not support the html5 featureset. Using another third party plugin such as google frame to target content to this user group ( also currently constituting the majority) is out of the question. Why should the largest portion of your userbase be served in downlevel?

• Install and upgrade --fully managed install and upgrade mechanism in place for Silverlight. This means as new versions of silverlight are made available, we can start using them in our applications right away and based on the runtime version of silverlight your applications are built against, that version will be used or the user will prompted to download and install it. This is fully managed by Microsoft and you do nothing in this department other than some minimal configurations such as MinRuntimeVersion and so forth.

Counter this with Html5, where features that constitute Html5 are supported at the discretion of the browser vendor. This means each browser vendor will pick up the feature they think is useful or important and will implement it. This makes it quite easy to find a feature that works in one browser but doesn't work in another or simply a feature that works in the latest versions of the browser while your left working around to compensate for the feature loss in older versions.

In fact not too long ago whatwg has officially moved to a non-versioned model where Html5 is simply known as Html. This move by whatwg makes sense to me also because no browser currently supports the entire featureset of Html5 and therefore the name is misleading. Infact no browser ever supported html4 completely. Silverlight, being a plugin does not suffer from this lack of feature uniformity across browsers/devices.

Final notes : 
One thing is sure, Html5 has been a hot topic for a while now and with the release of ie9 it has gotten even hotter. This is a fresh area with room for plenty of innovation and new business opportunities to tap into. Like all new things, there's a gold rush. Everybody is pushing out web applications that uses shiny new Html5 features, because that is the current trend and there's lots of room for investment. This is a large market segment with a wider audience.

As a .NET developer, if you are selling development tools, you are no longer confined to Microsoft developers, instead suddenly the web is your oyster. Lastly, it makes the headlines to invest in Html5 at this early stage, which can quickly translate to free marketing for you. That's someting to consider as well.

So, in the end, which one is the better? Today I'm confident about my silverlight investment because it made sense for my application and it's needs. However on a different project, I may sing a different tune all together. Sadly, there is no better choice. You know your application, only you know what it needs.

For instance I developed Abmho based on need. I couldn't find a proper syntax highlighter on the web that simply worked, that wasn't riddled with adverts and one that didn't require me to make a request to the server everytime. Soon this became irritating and so I decided to make one myself.

It was important that my syntax highlighter executed in the browser as an application and was fast and responsive. I also wanted to complete development fast and I have a .NET background. I also already had a syntax highlighter library in c#. Rewriting this library in javascript would have simply taken forever. It was certainly not worth the effort.

This move allows me to ship a wpf version (currently in the works) that requires subtle minimal changes to get working as a full fledged desktop application that I will be making available soon since Silverlight is a subset of Wpf. All this wouldn't be possible if I had gone the Html5 route.

Setting up a ConnectionStrings in .NET

ConnectionStringBuilder :

Tip for today is the ConnectionStringBuilder class. This is quite an unknown class but can result very useful in building your connectionstring. Normally, you'd take a connection string and pass it directly to your connection objects such as SqlConnection or DbConnection classes directly.

Quick example from msdn :

private static void CreateCommand(string queryString,
    string connectionString)
{
    using (SqlConnection connection = new SqlConnection(
               connectionString))
    {
        SqlCommand command = new SqlCommand(queryString, connection);
        command.Connection.Open();
        command.ExecuteNonQuery();
    }
}

As you can note from this classical example above, the connectionstring is passed directly to the SqlConnection object's constructor. While this is fine, any error in the connection and it's quite easy to make a mistake, won't be known until the connection is opened.

Further more, if you want to pass some additional values, or modify existing values in the connectionstring it can be time consuming and again error prone and more effort than you want to invest.

Say hello to the ConnectionStringBuilder. What this class does for you is that it facilitates parsing a connection string and also provides named properties you can simply set in code or whose values you want retrieved. A classic code example from msdn itself :

using System.Data;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        // Create a new SqlConnectionStringBuilder and
        // initialize it with a few name/value pairs.
        SqlConnectionStringBuilder builder =
            new SqlConnectionStringBuilder(GetConnectionString());

        // The input connection string used the 
        // Server key, but the new connection string uses
        // the well-known Data Source key instead.
        Console.WriteLine(builder.ConnectionString);

        // Pass the SqlConnectionStringBuilder an existing 
        // connection string, and you can retrieve and
        // modify any of the elements.
        builder.ConnectionString = "server=(local);user id=ab;" +
            "password= a!Pass113;initial catalog=AdventureWorks";

        // Now that the connection string has been parsed,
        // you can work with individual items.
        Console.WriteLine(builder.Password);
        builder.Password = "new@1Password";
        builder.AsynchronousProcessing = true;

        // You can refer to connection keys using strings, 
        // as well. When you use this technique (the default
        // Item property in Visual Basic, or the indexer in C#),
        // you can specify any synonym for the connection string key
        // name.
        builder["Server"] = ".";
        builder["Connect Timeout"] = 1000;
        builder["Trusted_Connection"] = true;
        Console.WriteLine(builder.ConnectionString);

        Console.WriteLine("Press Enter to finish.");
        Console.ReadLine();
    }

    private static string GetConnectionString()
    {
        // To avoid storing the connection string in your code,
        // you can retrieve it from a configuration file. 
        return "Server=(local);Integrated Security=SSPI;" +
            "Initial Catalog=AdventureWorks";
    }
}

Note: the same applies for the generic non SqlClient class DbConnection and you'd use the apposite DbConnectionStringBuilder class.

Lastly, retrieving the connectionString itself can be facilitated by using Server explorer, after having made the connection to the database visually in VS.NET you need to select your database in solution explorer and right click - Properties. From the property grid you can see the connectionstring VS.NET is using. That is the connectionstring you want.

Alternatively you can use create a DataLink and copy the autogenerated connectionstring created by the DataLink. Follow the url in the references section below.

Reference material :
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnectionstringbuilder.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx
http://msdn.microsoft.com/en-us/library/ms718102(v=vs.85).aspx ( DataLink )
http://msdn.microsoft.com/en-us/library/33wwc2yw(v=VS.80).aspx (Server Explorer)

Typps 3.1 released

A new 3.1 stable release is available for download.

Typps 3.0 released

We haven't been blogging much. We'll try to improve in that too. In the mean time know that 

3.0 is now released. This version fixes many problems among which issues in IE9.

Typps Version 2.7 released

We have a new release that fixes an important bug in when running the editor in a website that targets .NET 4.0 and Ajax control Toolkit. This release does not break any features so it should be a fairly easy upgrade.

Currently we are restructuring code in preparation for new features. So unless there is a major bug to fix, we will be skipping a few iterations.

One of the things we don't currently do is check in our code on codeplex. Instead we make releases and put out packages in the download section. Hopefully from the next release onwards we will start doing that too.

Typps Version 2.2 released

After 8 months of heavy development, Typps is back with a vengence. This new version marks a milestone because the code base has gone a partial rewrite and includes numerous bug fixes and new features that we shall be documenting soon.

Infact we shall soon provide a backlog so people know what feature is being worked on and where we are headed. In this release we have stalled many times but this is due to the numerous problems we were trying to tackle in Typps. To make it worse, we under went a complete rebranding phase and we are now officially called Typps. Along with the new name we have revamped our site, moved our discussions to codeplex ( much more consistent and less maintenance work for us).

We are however still lacking in documentation and demo pages to showcase on http://demo.typps.com/ ; the demo pages are also downloadable on codeplex. This allows you quick access to seeing how everything works. There are a lot of plans for typps and where we are headed, eg : more documentation, video tutorials, a faster release sprint (while adopting agile methodologies), supply more unit tests ( our current unit tests are quite scarce and broken). Moving forward, we also want to provide MVC support and silverlight.

MVC and silverlight are important, in this manner we can reuse the same components across various project types without resorting to alternatives etc.

This new release does not offer an upgrade, so don't expect to upgrade your existing apps by simply copying the dll. There are a lot of breaking features to take this to the next level. If you encounter issues, report them on codeplex.

We have rebranded to Typps (Formerly jiffycms)

Lots to do and so little time. With a little bit of patience it will all be done and we will put up the latest release on codeplex.
This is the very first post on our new blog! Finally. In the my next post entry I'll write a little on why we rebranded and the reason to move into the cloud. Why google apps and blogger and what happened to our cms? ಠ_ಠ
But now it's time to put up some documentation and wrap up this release.

Note that previously we maintained our own forums too. We are now using the forum on codeplex, so use that to report any issues or ask for help http://typps.codeplex.com/Thread/List.aspx