Silverlight – Developer’s perspectives

Everyone in the Web’s industry is so excited with this latest Microsoft RIA platform, Silverlight. I can easily tell that with the growing number of samples, showcases and response from community on the Internet. We can also feel the excitement from the fellow developers who visited our booth in the previous TechEd exhibition. They are so amazed, with what Silverlight has to offer.

If you take a look at Silverlight’s Showcase, you can find almost 80% of them are using Silverlight for non-business scenarios, such as creating media application (a.k.a. Youtube-alike). As Silverlight enthusiasts, one challenge popped up in our mind. Can it, or how is the feasibility, to use Silverlight in business scenarios application? I’m not sure, probably we’re too early looking in this area, or maybe not. Anyway, we’ll just try to do some prototyping using the popular Blend 2.5 June 2008 Preview.

The feature I liked most in Silverlight is to be able to write codes in C#, as most developers did. However, this heavy client side utilization also introduced several drawbacks that I think important for us to consider before going further. Well, let’s get straight to the points:

1. Severely much more hand coding.
   Ability to code in C# for client side development is just amazing, but we have seen significantly more coding needed even for just to perform a simple data retrieval task. I think it’s pretty much counterintuitive with what Microsoft and tool vendor like us already done so far. Compared to Web development in Visual Studio, the business application development in Silverlight is practically not feasible given the current state of Beta 2. It might be feasible, of course, but the techniques are not elegant at all. 

   For instance, we are forced to use “Networking” level technique in order to retrieve data from REST services, and with several dozen line of codes to map it back into objects using LINQ. This is just for a very simple data retrieval, and not to mention bind it back to the UI controls and other basic requirements such as data editing, and so on.

   Having that said, if we think back on the Web development in Visual Studio when we can easily perform data retrieval, data binding, etc – with simply drag and drop and some properties set; connecting to database is a snap using datasource control, and requires zero line of code. Then, do you still think Silverlight could win developer’s heart while it require so much hand coding and efforts? I doubt it.

   What’s more, the codes and development using Silverlight becomes way too complex and complicated when it comes to data serialization and deserialization, which developers need to take care manually now. Using Visual Studio Web, we don’t need to know anything about business logic in the client side, as the databinding are all done in server side. Now with Silverlight, you have to define your business objects and classes too in the Silverlight C# client side in order for the data to be mapped back as object before bound to the DataContext.

   With more hand coding requirements, it seems we are taken back in the pre-.NET era and even worse, it reduces developer’s productivity as well as diminishes reusability and automation that we already familiar with.
     

2. Lacking of server-side counterparts.
   RIA, specifically Silverlight in this context, is a pure client side technology. If you are going to develop business application using Silverlight 2 entirely (the other option is using Mixed technologies that I will cover later), then you will have a lot of challenges to overcome. One of them is the missing server-side infrastructure.

   Looking from the perspective of a Visual Studio Web developer, we have been familiar with all those server technologies such as a postback process where developers can handle the logic in code behind, and then return it to the Web. And then AJAX, which performs postback seamessly (we called it FlyPostBack in our technology) and updates only necessary parts of the page. Next, we have nice Web components that perform everything automatically, from handling the datasource, filtering, paging, you name it. Not to mention all those automation and features that ASP.NET has to offer, such as automatic state management, master pages, user control, security, and more.

   Turning to Silverlight, all those nice technologies are suddenly gone. You can’t, let’s say, click on a Button and easily write codes in the server side to set a value of Silverlight’s TextBlock. This is not surprising because Silverlight is entirely a new technology and a new platform that works in totally different way. When you create a new project in Blend, you will only see xaml and some html pages for testing. In short, Blend and Silverlight are purely client side technologies, leaving off ASP.NET server side technologies.
    

3. Confusing Web development path.
   The question is, why Microsoft created Silverlight? Isn’t Silverlight just going to compete with their own well-branded Visual Studio (specifically ASP.NET/AJAX)? Perhaps just to compete with Adobe, or try to intimidating Google? I’m not sure, and I don’t want to know.

   But the real challenge here is — in my view as Visual Studio Web architect — the sense of insecure of existing investments and upcoming technology changes. Imagine a team of Web developers who have just finished their Web application using ASP.NET, and now telling his boss “Sir, we have to rebuild the entire applications in Silverlight because it offers better user interface. And this means we have to buy more tools and some new books and training”. The boss replied and asked “Can’t we use the existing tools that we have heavily invested?”.

   “Sorry, can’t.” would probably the most pathetic answer that the development team could say.

   Given the current state of Beta 2, Microsoft doesn’t have a global overview yet on how the Silverlight can be used alongside with ASP.NET technology, specifically WebForm (for exactly, the pages with ASPX extension). Sure you can create Web Service, WCF using Visual Studio — but those are no longer related to WebForm. Sure you can also use <asp:Silverlight> to show Silverlight content in a WebForm, but that’s not the context of this post (and it’s also too wide to be discussed in single post), as we are speaking development that use Silverlight 2.0 technology entirely.

The above three points are so far the biggest challenges in Silverlight from the perspectives of Visual Studio Web developers. So, what options do we have now? Stick on ASP.NET Web development, or turn to RIA Silveright development? The answer is, I think, depends on the application type that you want to build, and the target audiences. If you are building mash-up sites or graphic-intensive sites just for fun, Silverlight couldn’t be wrong. But, for large enterprise-scale business application? That’s still a big question mark. Would developers need to be hurry to turn to Silverlight for business apps? I think, probably not, at least for now.

Again, this post is not intended to demote Silverlight at all, and is written based on the Beta 2 state. Maybe, who knows, tomorrow ScottGu will announce Silverlight RC1 which have resolved some of the issues above. Let’s hope so.

Thoughts, comments?