Silverlight Adventures

May 07, 2007 @ 3:16 am- from Maui, Hawaii

Well, here we are again - let the hype begin!!! Yup, we have a new toy to get excited about and this time it's Silverlight or Microsoft's entry in the Rich Internet Applications (RIA) space. RIA's are interesting to a lot of developers. I can't tell you how often I've heard the request over the years to build richer applications that can run in the browser. If I had a penny for everytime somebody's asked me - "how can I take and run my Windows app in the browser on the Web" I'd be - not very rich, but a good chunk o' change would have accumulated. This request dates back a LONG time and one has to ask what took Microsoft so long?

At Mix last week Microsoft made a number of announcements and showed off Silverlight (formerly known as WPF/E) for the first time. Silverlight has generated a lot of excitement and speculation of a scope that hasn't been seen in a while and it's clearly struck a nerve for a fix that a lot of developer are jonesing for.

Last week at the Mix ’07 conference Microsoft announced updated plans for a browser based technology called Silverlight (formerly known by the code name of WPF/E). Silverlight is a light-weight, self-contained and browser independent version of the Windows Presentation Framework (WPF) that can run inside of a Web Browser without any outside dependencies. Silverlight can run in IE 6 and 7, Firefox and Safari, both on Windows and the Mac and is installed by a single one-click installation that takes only a few seconds.

Microsoft announced two versions of Silverlight: Silverlight 1.0 beta which provides a base set of WPF functionality that is scriptable from an HTML document, and Silverlight 1.1 Alpha, which adds a client side version of the .NET runtime to Silverlight. Yup, this means .NET code in the browser – in various browsers and on Windows and the Mac. I’ll come back to the .NET integration later, but let’s look at the base features of Silverlight first.

Silverlight’s focus is on providing rich graphical experiences in the browser. It’s a browser plug-in that can interact with the HTML page and the controls on it. In version 1.0 of Silverlight all coding for Silverlight has to be done using JavaScript code, which can call into the Silverlight control and the document hosted within it, as well as acting as an event handler sink for events fired from the Silverlight application back into the JavaScript code. Hooking up this two communication in the browser is straightforward and provides a logical interface between the page and the control and its content.

Silverlight includes a small, graphics-centric subset of the full WPF, focusing mainly on the graphics and multimedia features. Many of the 2D graphics features of WPF are available in Silverlight, but there are differences and omissions that won’t quite allow straight across usage of full WPF code in Silverlight. If you want to use content in both WPF and Silverlight, you have to carefully decide which features to use to make sure they are Silverlight compliant. Among the missing features are most of the top-level panel containers of full WPF, data binding, styling and templating to name a few. Even more critical is the complete lack of any input controls at the moment. There’s no textbox, no button, no list – not even a scrollbar or support for auto-content scrolling of a container, which seems a bit puzzling given Silverlight's Web focus. It’s clear Microsoft’s focus in these first releases is not on line of business scenarios, but rather targeting directly at designers and rich custom interfaces built up on graphics primitives.

Silverlight and Browser Interaction

Since Silverlight controls are embedded in an HTML page, they can interact with the page and be an active part of the HTML document. One important feature of Silverlight is that it can create windowless controls that essentially work with a transparent background, which allows overlaying of Silverlight content on top of the HTML content. You can also overlay windowless controls with HTML controls, which is important because Silverlight doesn’t include any input controls of its own. If you need user input in your Silverlight controls, you either need to create the control manually via XAML layout and event handling (for key and mouse events, etc.) or you can use HTML controls for capturing input and passing the content to the Silverlight control. It’s possible by overlaying HTML controls and windowless Silverlight controls to provide a semi integrated control experience, but it’s not very seamless. Layout is awkard and it doesn't look right in most cases as the HTML controls have very different look than the anti-aliased Silverlight content. According to Microsoft control support will come later in the Silverlight 1.1 cycle, but v1.0 will likely ship without any Silverlight input controls.

But even these limitations aren’t stopping some very creative folks from going all out and pushing the limits of what you can do by creating the missing pieces on their own. The folks at www.windowsvista.si built a pretty impressive WPF/E application that mimics the Windows Vista desktop inside as a WPF/E browser application. Not just the basics, but a full bore implementation of the Desktop, Sidebar, Explorer, Media Player, the Start Menu etc. It’s not terribly useful, but it gives a mind blowing view of what’s possible with the technology. (unfortunately this sample doesn't appear to work with the current release of Silverlight as it was originally written for WPF/E but I expect it will be updated given that it's Microsoft sponsored). Much of what you see in this sample is custom-created control content and is not “in the box” of Silverlight. Someone has put a lot of work into creating the various control implementations. This sample also demonstrates what is possible with the technology in the hands of creative people—it certainly opens up many possibilities for user interface magic that simply isn’t possible with HTML alone.

Silverlight 1.1 – Let there be .NET

Microsoft also announced a more ambitious preview version in Silverlight 1.1 Alpha at Mix and it was easily the hit of the show. This version of Silverlight provides all the functionality of the 1.0 version, but adds a significant new feature: Support for the .NET runtime on the client as part of the plug-in.

This is a significant addition and it really changes the focus of Silverlight considerably. In version 1.1 Microsoft has essentially built in a surprisingly complete subset of the .NET runtime that is suitable for operation in the browser client context. According to Microsoft this version of the .NET framework is actually a refactored branch of the full .NET CLR framework, rather than a completely new runtime. When experimenting with Silverlight 1.1 I was pleasantly surprised just how much richness is available in this small footprint runtime which includes features like LINQ, support for Threading, some features of System.net, Isolated storage and a huge chunk of the core System libraries that you are already familiar with in .NET. You get rich string support, Regex, Internationalization, formatting, Stream support etc. Many of the things we take for granted in the .NET CLR are there to let you write and re-use existing .NET code efficiently. While I was working through a few small samples I built playing around with Silverlight over the last few days, I was able to take a bunch of my existing library code and simply use it without any changes at all in most cases and only a few minor adjustments in some others. Right there my productivity increased many fold as I didn't have to re-write some of these utility routines!

Two way interaction: DOM to Silverlight and Silverlight to DOM

There are also namespaces that are specific to coding with Silverlight including a (simplistic) object model for programming the HTML document object from within .NET code. But lest you get too excited about writing all your client side level DOM processing in Silverlight - the HTML object model exposed in the Silverlight .NET CLR is very basic and only exposes generic high level constructs like HtmlElement and HtmlDocument, HtmlElementList etc. There’s no strong typing of individual attributes and you don’t get any browser abstraction as you would with say the MS Ajax library. Still the potential is there to build on top of these base controls to create a browser independent library with .NET code and drive that code entirely through the .NET code you write inside of Silverlight on the client. This means you could potentially build and interact with pure HTML based interfaces but use compiled .NET code to handle all the page logic even if you otherwise don’t use Silverlight’s graphics features as all. I could foresee creating an invisible Silverlight control and use it as the page scripting engine. That would be way cool and not that hard to accomplish *IF* you know how to handle the cross browser issues in the first place. Heck, some enterprising developer might be able to create a front end to the MS Ajax client library even and expose that particular object model. Interesting possibilities here.

On the other end it’s also very easy to create .NET code inside of Silverlight and call this code from within JavaScript. Silverlight exposes the control object and allows access to any named elements in the XAML document via slControl.findName(). From there you can get a reference to any control or the root canvas and fire any methods or access properties on these objects as long as the classes and members accessed are marked with a [Scriptable] attribute. You can even create separate classes, register them with the Silverlight control and expose those objects directly to the client code. This means you can very easily write .NET code for any sort of codig functionality and directly access this functionality with a simple method call from JavaScript. Think of the possibilities with this functionality! It makes it possible to offload computationally expensive tasks into Silverlight’s native .NET code providing drastically improved performance over equivalent JavaScript processing.

CLR on the Client means many, many opportunities!

The runtime on the client has many implications. Even if you don’t plan on using Silverlight’s graphics features you can write processing and even UI logic using .NET code, using the familiar process of using Visual Studio to compile your code and execute and debug it right inside of Visual Studio which can seamless step between server side ASP.NET code, directly into Silverlight client code in a single debug session! Microsoft ships Silverlight 1.1 Tools for Visual Studio Orcas, so it requires a preview version of Visual Studio Orcas to run. It’s also possible to use Silverlight 1.1 with Visual Studio 2005, but it’s a manual configuration of compiler via MS Build and there’s no debugging support.

One of the things that makes the .NET code on the client interesting is that it's essentially a familiar component architecture. Code compiles into a Silverlight .NET assembly and that assembly is deployed on the server and downloaded by Silverlight as needed. Add more features or control libraries in another assembly and it gets downloaded to the client as well. IOW you get an extensibility mechanism for free where you pay for what you use. Microsoft provides the core runtime in the Silverlight core plug in module and the rest can be downloaded separately.

A lot of focus at Mix this year was given to the very visual aspects of Silverlight – hey they demo nicely – and Silverlight really works well for this. Some of the samples shown (especially the Top Banana sample) are pretty amazing given the current status of Alpha for the technology.

But in my opinion the really big news is the addition of the .NET runtime in this platform. While Silverlight still has some growing pains to go through, Microsoft has created an extensible platform here that is based on an existing knowledge base of .NET. You can reuse your skills and your code in many cases on the client. And while the current Silverlight high level implementation is maybe a little on the light side in terms of functionality, by having .NET and the .DLL based downloadable component model, it’s possible to completely extend the client platform. This means developers or third parties can build custom controls and provide missing pieces and high level abstractions that Microsoft has not created yet (or won’t create at all). An open component model is a key feature that should bode very well for the success of this platform.

Silverlight Impressions

In my own experimenting with Silverlight 1.1 over the last week, I found Silverlight very powerful and easy to work with in some ways yet frustrating in others. I can totally feel the potential of this platform through the .NET extensibility and efficiency it provides over screwing around with JavaScript code on the client. The whole process of coding, running and debugging code in this environment is drastically smoother than working with JavaScript (even with the improved JavaScript experience in Orcas).

However at the same time I found the lack of high level abstractions in the UI very daunting. Although I’ve been reading up and experimenting with WPF for some time now, the subset that Silverlight publishes is pretty light especially if you are not a designer type. Silverlight includes all of the core graphics primitives, but without the high level building blocks like input controls or even better formatting features like auto-sizing and scrollable text regions every piece of layout has to be explicitly designed. Buttons, surfaces – even text areas can’t just be dropped but require careful layering to display correctly. To me as a non-designer it feels very difficult to put together user interfaces that require displaying input and text content even (or maybe especially) when using Expression Blend. As it is most of what I work on requires more traditional data entry and display scenarios and that’s something the Mix demos did not show with all their focus on media and rich graphics.

In a couple of days of playing with the technology I was able to build a couple of useful controls (a multi-file uploader and a messaging interface) and while the process of creating the actual code logic for these controls was super easy and no more dififcult than creating a WinForm or ASP.NET control, getting the layout to look even reasonably nice took forever - I spent hours on the most basic layouts and even then they look uhm, crude.

There are two issues here – the lack of high level controls, but also the mere fact that this is a complete free for all – design your UI anyway you want without any sort of UI guidance. This is an issue for somebody like me who’s not a designer and has to struggle with UI in any application. I’m guessing I’m not the only one in this situation.

I think the media and rich graphics features are very important as that's been a missing piece in the Windows puzzle, but I also wonder how many developers are really going to be able to build these rich user interfaces and make them look reasonably nice? We seem to have enough problems getting people to build decent HTML or even WinForms API that aren't using BLINK attributes <s>. I'm sure I'm not the only one who feels pretty lost looking at an empty canvas in Blend and going "Now What?"

And even more pertinently - even if the word is that we'll need designers to have a useful and slick UI experience, how many applications are going to have the budget to actually spring for having designers build UIs? UI Design time is as expensive development time and often even more time consuming. My guess is that 90% of applications have no need for rich media or rich graphics functionality, but instead need basic user input and display functionality. Yet, it sure would be nice to get some canned effects like slide in controls or controls that give visual feedback when hovered over or to display things like Validation etc.

As I mentioned in previous posts I have been playing around with Flash and Flex 2 and one thing that Adobe definitely got right in this toolset is that they ship a pretty good set of controls in the box to make you productive without getting that "Now what?" moment and then fumbling around for a few hours trying to create a 3D looking button and trying to get text to line up properly.

It seems to me there is going to be a pretty serious need to have a high level UI framework that can ride on top Silverlight's base WPF graphics engine. The lack of UI controls is certainly a hotly debated topic on the Silverlight Forums as was to be expected and I think this will be one of the make or break features for Silverlight because of expectations developers have. I suspect a large number of developers watching those rich demos did not realize that all of the windows, sliders, buttons and stackpanels are custom designed and not something that comes in the box! It'd be nice though <s>.

So, on the top of my list of features that I want to see for Silverlight 1.1 are:

Control support
Basic controls for input (Textbox/Editbox, Button, Checkbox, Radio, ListBox (or a more flexible ListView like control), Dropdown. More advanced controls certainly would be nice, but that probably won’t happen for the first release.
Better support for Layout
It’s tough at the moment to work with layouts as the only way content works is positionally through the generic Canvas container. There’s no flow layout and autosize support and content doesn’t even support automatic overflow handling or scrolling. I’d like to see StackPanel and ViewPort supported at the very least.
Support for Styles and Template
Silverlight doesn’t currently support styles or templates. For example, text layout doesn’t support global styling so you have to use individual Font and display formatting on each text element.
DataBinding
WPF’s Databinding support that allows binding just about anything to a property of a control is not supported. This is one of the nicest WPF features, but it’s missing in Silverlight.

It’s important to remember though that for Silverlight 1.1 it’s early in the development cycle so there will be new features added as time goes on. Several people from Microsoft have already hinted at some control support, although there have been no specifics. Feedback is important at this stage so be sure to voice your thoughts on the Silverlight Forums and let Microsoft know what your usage scenarios are.

Microsoft has additional strict limitations they have to deal with in Silverlight: the core engine that they provide has to work on multiple platforms and the version of .NET plugs into Silverlight and so any feature subset both for the graphics engine and CLR must be able to run on all these platforms. In addition, Microsoft is committed to keeping the core Silverlight 1.1 download package to under 5 megs which is an ambitious goal. The current Alpha is 4.5 megs and much needs to be still added according to Microsoft, but there is talk of componentizing the runtime in such a way that the core is small and downloads only the components that it needs.

Personally I’m more concerned over a functional engine than a tiny download size. More than anything it’s important that technology can address the business needs that it needs to solve. I vote for functional first, download size a distant second please.

Forward!

There's a lot to like in Silverlight and I think Microsoft really hit a home run with the .NET runtime on the client. Silverlight also addresses the rich media and graphics shortcomings of the browser quite nicely. It offers the ability to run .NET code on the client to handle client side logic with the familiarity of the rich .NET framework to provide common functionality easily and consistently.

For me the biggest shortcoming currently are the UI limitations. But if I had to put money on it, I’d bet that these kinds of line of business scenarios have got to be high on Microsoft’s radar. There are many developers chomping at the bit to build richer client applications and write more structured code using a .NET language. This is a question I’ve heard over and over from developers over the years, and Microsoft is definitely delivering on that end. With the Silverlight platform and its extensibility I’m positively certain that this technology will be a big hit with developers and find acceptance because of the compelling content that will be created with it. And because it’s extensible it’s an ecosystem that can continue to grow even after an initial release both from Microsoft and from the community and third parties.

But we also have to find the right fit for the technology. Many people will look at Silverlight and think that we can finally be rid of the HTML juggernaut, and replace it all with RIA code, but it probably won't work out quite like that <s>. Some applications will work in this all-out client side, Silverlight model, especially internal applications or applications that aren't heavily content based and don't rely on search engines or advertising. Remember that the whole Web these days is driven by search engines providing traffic and advertising providing revenue neither of which is going to work well with RIA controls, at least not without a completely new model.

Alot will also ride on successful Microsoft will be at selling the technology to get it onto a large majority of computers quickly. There's also the resistance from the anti-Microsoft defamation league that will railing against content using a "propriatary Microsoft technology" I'm sure.

A lot of things have to be thought over in light of this approach to building applications. It'll be interesting to see where all of this takes us especially in relation to HTML. Interesting times ahead - and yet another learning curve...

If you find this content useful make a donation

Posted in Silverlight

Feedback for this Weblog Entry

# DotNetSlackers: Silverlight Adventures
by DotNetSlackers Latest ASP.NET News May 07, 2007 @ 4:09 am

# re: Silverlight Adventures
by Scott Barnes May 07, 2007 @ 4:39 am

And I thought my rants were long! heheh.

This is gold Rick, nicely put and It was worth the read (another golden read from this blog)

-
Scott Barnes
Developer Evangelist
Microsoft.

# re: Silverlight Adventures
by Guy Peled May 07, 2007 @ 6:01 am

That was exactly my thoughts regarding this new exciting technology but I had one more though and that the current examples of Silverlight/WPFe are really fat in terms of bandwidth adding on top of it business logic that will be downloaded in the format of .NET assemblies and lots of componentized XAML sounds that there is room for some speculations about the future uses. I come from the business application development arena and I am looking at this technology from this perspective, it will really be interesting to see if there will be any work done on this level (some thing like flex).

I really enjoyed reading this post,
Guy

# re: Silverlight Adventures
by Wilco Bauwer May 07, 2007 @ 6:10 am

> "There’s no textbox, no button, no list – not even a scrollbar or support for auto-content scrolling of a container, which seems a bit puzzling given Silverlight's Web focus."

You're right that plenty of important controls are missing, but there is a small set of controls available as a separate download. For what it's worth, see http://blogs.msdn.com/mharsh/archive/2007/05/03/silverlight-c-controls.aspx. This includes a button and scroller.

> "[...] the HTML object model exposed in the Silverlight .NET CLR is very basic and only exposes generic high level constructs like HtmlElement and HtmlDocument, HtmlElementList etc. There’s no strong typing of individual attributes and you don’t get any browser abstraction as you would with say the MS Ajax library."

Feedback in this area is very valuable. I think much of the UI OM will depend on the richness of it. Things like templating/databinding, abstracting browser-specific things like positioning, sharing of interfaces between HTML/XAML objects, etc. Having "just" a strongly-typed UI OM so you get intellisense doesn't seem to be worth that much in my opinion. In that case I think it'd make more sense as an optional library people could deploy as part of their app.

# re: Silverlight Adventures
by Abdu May 07, 2007 @ 1:42 pm

When someone wanted a truly rich fast app in IE, one option was to create an ActiveX based on .NET usercontrols. You get the full rich Windows forms functionality. Granted, it works in IE only and the .NET framework is needed on the client but it worked for Intranet apps. (I am currently working on one because Javascript (hence AJAX) is too slow).

All this Silverlight news is flooding my RSS feeds. Can someone out there just point out what Silverlight can do that Adobe Flash can't do. From the point of regular non techie web users, that's all what they care about. We as .NET developers get too excited about a new technology and can't see the forest from the trees (or the hype).

# re: Silverlight Adventures
by Rick Strahl May 07, 2007 @ 2:04 pm

Wilco, looked at those controls. <s> Interesting mainly if you want to build your own but not really all that useful given the hardcoded styling and look. It's a start but not really what I have in mind. Given that control set a few things come to mind: If you end up a 'scroll control' we're still shooting to low level. I don't think I'd want to have to deal with the equivalent of 'owner drawing' a list in my UI code. I remember all that fun with Windows Mobile 1.x applications. I realize it's early in this tool but I really, really hope that base UI controls become an integral part of it. I feel pretty strongly (as you can tell) that that's a vital part of a tool like this. Whether it's native in the core library or provided as an external library doesn't matter but a reasonably rich and immediately productive control kit is vital to so many scenarios.

>Having "just" a strongly-typed UI OM so you get intellisense doesn't seem to be worth that much in my opinion.

I agree. But if you had it as a front end to a richer abstraction that abstracts say the MS Ajax library, then you have something pretty useful. Basic DOM interaction doesn't get you much because of the browser differences. If we're back to browser sniffing and working around DOM issues then there's not much gained, but I think it probably wouldn't be that tough (for a third party maybe) to build a DOM library that is browser safe and can be addressed through .NET code.

FWIW, the code part of the work I've been doing has been a total breeze using Silverlight and I think this is a pretty compelling scenario. HAving this binary interface drive the HTML page is an interesting concept but I could see that making life for client side HTML programming much easier.

> I think much of the UI OM will depend on the richness of it. Things like templating/databinding, abstracting browser-specific things like positioning, sharing of interfaces between HTML/XAML objects, etc.

Templating and at the very least style support is very important IMHO. Right now laying out text for example feels like writing <font> tags - you have to format every little property you set on the actual <Run> you're creating, which feels like a big step backwards after even CSS.

# re: Silverlight Adventures
by Rick Strahl May 07, 2007 @ 2:41 pm

Abdu, ActiveX is evil! <s> Seriously. The security issues are horrendous...

If you want to build rich applications and limit yourself to Windows and IE then you can use XBAP and run the application in full trust. That way you get an application that is truly fully functional and can do just about anything WPF can do. But this is obviously not a broad reach scenario - this works for Intranet or fully authenticated scenarios, but not for general public applications. And if you really have a need for this sort of thing you should consider NOT bothering with the browser at all and just running a full blown desktop app deployed with Click Once. IOW, there are options for building the type of application you're looking for for your full trust scenarios...

The focus of Silverlight is not on that scenario however, the focus there is that it can run cross-browser, cross-platform and potentially be a replacement for a broad reach HTML scenario. There's no dependency on anything else. It won't be as powerful as a full trust application - it can't be for the security restrictions and browser sandbox. But you should be able to build a much richer UI than what you can do in HTML.

# re: Silverlight Adventures
by Rick Strahl May 07, 2007 @ 2:46 pm

Guy 'fat' is relative I think. Sure a thing like the Top Banana sample is going to be pretty beefy because it's basically a whole home made UI framework that's coming down along with data and everything else. But remember that when you run slick HTML based application you are also downloading stuff like this - AJAX client libraries, the UI markup in the HTML, extra JavaScript etc. and you'll continue to download a lot of this stuff. If you run a binary app like Silverlight a lot of this stuff is embedded in the binary and you end up with a bigger first time hit.

But also in a lot of scenarios like Top Banana, you're looking at a one page application - an SDI app in the browser if you will. You don't go off navigating to other pages, so after the initial load there's no more loading while you're using the application.

# re: Silverlight Adventures
by Kevin Zink May 08, 2007 @ 11:51 am

Awesome post, Rick. I'm really excited about Silverlight; I've downloaded orcas and Silverlight 1.1, but haven't had time to play with it just yet.

Reading your review/viewpoint on Silverlight has answered a lot of questions I had about the framework (in particular to the basic UI controls like a textbox). I suspect these will definitely be added in later releases.

As one of the previous commenters mentioned, I'm also really curious to see how Silverlight affects your average joe business application developer. I've created a few websites with Microsoft's new Ajax libraries. I put in a lenient amount of animations and dynamic content (fading, moving, dynamic updates, etc.) and my users thought they were awesome. They're Easily amused, I guess.

At any rate, if Silverlight grows to contain a rich set of prefab UI controls, then it'll enable us developers to throw together a really nice, rich UI in very little time (like hopefully as much time as it takes to throw together a generic ASP.NET app).

I think the ability for developers to rapidly create Silverlight applications will be paramount to the technology's success. I mean, I don't want to be spending hours tweaking my UI controls so they don't look hideous and malformed--hell I have enough problems with plain ol' HTML! I want to spend the majority of my time coding up the behind-the-scenes logic for my application, assuming there is some.

I guess we'll see how things develop... but the current release is definitely promising.

# re: Silverlight Adventures
by Abdu May 08, 2007 @ 1:38 pm

Rick, in my case, ActiveX is used in an Intranet app so there are no security concerns.
If XBAP needs full trust, isn't that a security concern too? At least .NET based ActiveX uses CAS.

XBAP and Silverlight are too new for me and my co-developers so we can't convince management to wait for us till we learn these and be proficient in them and then start the projects that are waiting to be built. Plus management doesn't like to use brand new technologies that haven't been tested and baked in the market place for at least a year when the kinks have been ironed out. (By you in your posts at least :) )

My ActiveX control is for a specific use and it was discovered later in the project that AJAX wasn't going to be fast enough for our purpose and that's when ActiveX was considered.