Jose Fajardo

Silverlight and WPF

20090420 Monday April 20, 2009

Silverlight 3 Out of Browser - Quick Rant

 

SL3 Out of Browser (OOB) is very impressive for a pre-version 1. It is clean, simple and most importantly consistent with everything else in SL3. Basically it will require little effort for a developer/designer to create out of browser Silverlight apps.

BUT personally I am very disappointed with this feature ! :(

Let me tell you why, and for any MS people out there reading this please know that I appreciate the hard work that you guys are doing and this is only a personal opinion not directed at anyone in particular....

After a weekend of playing with these pieces I came to a couple of sad demoralizing truths :

1. Sandboxing . MS finally gives us the ability to take our Silverlight applications out of the browser, but guess what they still want us to treat the application as if it was in a browser ?! If I wanted my application to behave like it was in a browser I would of kept it in there in the first place.

I was looking for a solution from MS that would allow me to take my SL app and have it run like a full desktop application across OS (Windows/Mac/whatever..) and have access to OS level resources.

2. No HTML Interop - I've heard that the MS guys are working hard to get a solution in place for this for post SL3, but I just wanted to say that it is a big pain point for me. Basically at the moment going OOB I lose mouse wheel support and access to xmlhttp.. Nice :(

3. Inability to customize the chrome. I know the decision here was based around security but for a technology that is all about user experience and to not allow us to change the fundamental user experience "chrome" just sounds crazy to me.

As mentioned in point one MS have given us the ability to take our apps out-of-browser BUT one of the main reason's for doing that is because we don't like the look of our app in a browser. Again not only do you want us to make our apps behave like browser apps (sandboxing) but you also want us to keep them looking like a browser app (browser chrome).

Not only can't I change the chrome but I also can't programmatically change the dimensions of the chrome, this is a big deal for me because some of the experiences I’m envisioning  involve dynamically resizing the chrome (in a very tasteful way). Think widgets that start small like a bottom right aligned toaster popup that when clicked expands to a full blown RIA..

4. Still limited to the browser networking stack rules. One of the most painful things about Silverlight is my inability to use a lot of third party web services because of Silverlights strict adherence to the browser stacks networking verbs of GET/POST. I was hoping that OOB would allow for other verbs, but alas that was not to be. This is a big pain point especially for hi-REST situations :(

......

So that's my main complaints, and I know that I differ in opinion to a lot of my other SL peers (Shawn, Michael, John etc) but that's a good thing ... i think..

So from what I can see the only advantage I get with going OOB is

1. More function keys to listen for on keydown/keypress

2. A shortcut link to my app

.. is that it ?! I think so :(

I know that MS are erring on the side of caution here, and probably have had entire business units dictating to them what they can/can't do (legal, windows OS, WPF) etc. BUT in my eyes MS had a massive chance to really innovate with this feature, but they didn't (or weren't allowed). Instead they went with something "SAFE and SECURE". That’s not what I was looking for :(

I have to end by saying that Silverlight 3 is an amazing release we just happen to disagree with this one feature, OOB.

So back to creating my first very cool looking out-of-browser-but-in-browser app!

p.s. Thanks Laurent for the correction, Laurent Bugnion actually agrees with me on these points too :)

 

Posted by josefajardo | Apr 20 2009, 11:10:42 AM EST
XML