I WILL point out this though- the PO doesn't really know the difference between an SL app running in browser or a JavaScript site. All they know is you are running a "web app", and that's what they want.

To be fair, our current PO was burned before by a thick client app because of deploying patches- she doesn't want to experience that again. Fact is that can easily be dealt with, but once you've been burned you don't want to go down that road again. When we decided to take our app out of browser, she had to be assured that we'd be able to update the application seamlessly (which we will have no problem doing). I think the update issue is a large reason people choose web apps, but there are correct ways to deal with this that do not involve running in a browser.

On a different note- I'll also mention that as great as I think SL is as a technology, there are a lot of surrounding technologies in the MS stack that I believe are very misguided. It seems that everyone I hear talking about SL is trying to write apps in a way that hides (from the developer) the idea that you are actually writing an app communicating over the web. This was what made asp.net trash (you try to abstract the disconnect nature of developing a web page, and you get developers who don't understand the consequences of some very natural decisions) and I see it with a lot of the stuff that is being pushed for Silverlight. Out of browser or in browser, there are fundamental difference between an app running with all of its resources locally available, and one that has to communicate over the web in order to do its business. You cannot treat these problems the same no matter how hard you try, and it seems MS keeps trying to help developers out by giving them tools to do exactly that.