Silverlight VS WPF [modified]
-
Somehow, my boss hgot it in his head that Silverlight would be a viable technology to deploy an enterprise-level application. We've just spent the last 6 weeks creating a WPF demo, and I'm not in favor of changing to Silverlight at this point. Can anyone with specific knowledge comment on the pros/cons of using Silverlight over a desktop WPF application? I want a clear and un-biased comparison of the two.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001modified on Tuesday, May 26, 2009 6:50 PM
John Simmons / outlaw programmer wrote:
I want a clear and un-biased comparison of the two.
Urgentz ... pleze.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
Somehow, my boss hgot it in his head that Silverlight would be a viable technology to deploy an enterprise-level application. We've just spent the last 6 weeks creating a WPF demo, and I'm not in favor of changing to Silverlight at this point. Can anyone with specific knowledge comment on the pros/cons of using Silverlight over a desktop WPF application? I want a clear and un-biased comparison of the two.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001modified on Tuesday, May 26, 2009 6:50 PM
John, The development team I'm currently on is facing similar issues, minus the "boss" part. Here's what I can tell you: 1). There is very little cross-over between WPF XAML and SilverLight 2). SilverLight 3.0 is really closer to be "LOB ready", don't waste time with 2.0 Other issues: 10 SilverLight Gotchas, with SilverLight 2.0[^] But again, from what the "guys" on my team have mentioned, I would skip 2.0 and concentrate effort on 3.0.
:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTL -
It's just a shame that they aren't browser independent.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Well, these days there is no excuse of writing browser dependent code. The Javascript libraries are extremely powerful and encapsulate lot of complexities away.
-
Rama Krishna Vavilala wrote:
IT departments love web based applications over desktop applications as it usually means a lot of time saved to them in support and deployment.
That's the promise. Sadly, the reality often falls far short and there's just as much pain in supporting said application, having followed a vastly increased development time as you spend so much time working round web app limitations.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
ollowed a vastly increased development time
I don't agree with it necessarily. My experience in terms of rapidity of development has been: VB6 / Winforms > ASP.NET > ASP.NET with jQuery/ExtJS > MFC > WPF > SilverLight. If I want to develop something really quick and dirty and short lived form/grid based LOB app, I invariably choose winforms. However, I have found that in a complex - long lived project the choice of technology itself plays very less part in the development time. Because each technology comes with its own set of problems.
-
Somehow, my boss hgot it in his head that Silverlight would be a viable technology to deploy an enterprise-level application. We've just spent the last 6 weeks creating a WPF demo, and I'm not in favor of changing to Silverlight at this point. Can anyone with specific knowledge comment on the pros/cons of using Silverlight over a desktop WPF application? I want a clear and un-biased comparison of the two.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001modified on Tuesday, May 26, 2009 6:50 PM
You already know, like Pete, I love this stuff too. A year ago I laughed and joked with everyone at the thought of me doing web apps... now it's my main business, all using Silverlight/ASP.NET/WCF. I'm not going to answer your question - I think you know you have to research the pros and cons, and better yet, try it yourself. I will say, however - PLEASE beg your boss not to do it. I don't want to see your posts here (after you've been working with WPF) as you realize painfully how much Silverlight IS a SUBSET of WPF...the lack of rich WPF databinding in markup alone makes me cry (luckily I like writing actual code anyway)... Please....no...
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Somehow, my boss hgot it in his head that Silverlight would be a viable technology to deploy an enterprise-level application. We've just spent the last 6 weeks creating a WPF demo, and I'm not in favor of changing to Silverlight at this point. Can anyone with specific knowledge comment on the pros/cons of using Silverlight over a desktop WPF application? I want a clear and un-biased comparison of the two.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001modified on Tuesday, May 26, 2009 6:50 PM
Actually now that I've reread your entire post and not just the topic (because comparing Silverlight to WPF is, well no comparison), I'll answer...
John Simmons / outlaw programmer wrote:
the pros/cons of using Silverlight over a desktop WPF application?
Cons: 1) The sandbox 2) Very small subset of the .NET framework (although for certain app types, there's plenty) 3) It runs in a browser. 3.0 has offline capability, but it's still in a browser Pros: 1) It runs in a browser. but it runs in more than one browser on more than one platform. 2) Deployment. There's no easier deployment - including ClickOnce Now, if you're convinced you want or need a browser based app, perhaps because it's cross platform and deployment is easy, then there's even more pros: 1) You can leverage existing .NET skills, like C#/VB.NET on a browser platform 2) The Silverlight runtime provides a subset of .NET, so interacting with existing desktop .NET based applications (like using WCF and/or ASP.NET) can be much simpler. 3) Silverlight apps actually run code on the client, unlike other web technologies like ASP.NET (and Silverlight code runs faster than js). Depending on the application, and with a thoughtful design, this can benefit web app performance by allowing distribution of CPU load between server and client.
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
You already know, like Pete, I love this stuff too. A year ago I laughed and joked with everyone at the thought of me doing web apps... now it's my main business, all using Silverlight/ASP.NET/WCF. I'm not going to answer your question - I think you know you have to research the pros and cons, and better yet, try it yourself. I will say, however - PLEASE beg your boss not to do it. I don't want to see your posts here (after you've been working with WPF) as you realize painfully how much Silverlight IS a SUBSET of WPF...the lack of rich WPF databinding in markup alone makes me cry (luckily I like writing actual code anyway)... Please....no...
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
I will say, however - PLEASE beg your boss not to do it. I don't want to see your posts here (after you've been working with WPF) as you realize painfully how much Silverlight IS a SUBSET of WPF...the lack of rich WPF databinding in markup alone makes me cry (luckily I like writing actual code anyway)...
If there was a site available that listed the things you probably won't like about WPF (and/or Silverblight), at least I would have gone in with my eyes open instead of being utterly surprised at how much it still sucks after three years. And truth be told, it's not so much WPF itself as it is the tools. Since I already knew Silverblight is a subset of WPF, and since I already know that the WPF tools suck, it just goes to reason that developing for Silverblight is going to suck as well. For those reasons, you won't get any of the same "Why Silverblight Sucks Today" messages that I've already gone over for WPF. However, if some new suckage raises its ugly head, I will most assuredly expose it to the light of day. In fact, I already have a new suckage item regarding Silverblight, direct from Microsoft. I guess you'll just have to deal with it and try to talk me down if I get too agitated. Remember, I don't want to hate this stuff, but Microsoft hasn't taken any steps - at all - to ease my pain. I can handle tools that are merely adequate, but when they just plain suck ass, it pisses me off.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I guess I should have used the joke icon.. here another useful answer - The reasons why you should use silverlight over WPF is one that only your boss and I know. We cannot share the buisness secret with a commoner. [A Serious Answer]: if you google Silverlight vs WPF you get 2.5 Million result! This is from my bookmark: BLOG[^]
-
Bassam Saoud wrote:
[A Serious Answer]
Quoted from that blog; "The maddening answer is (of course): it depends!" The link you pasted says it depends, whereas you say it "rocks". Now which of the two do you want?
I are troll :)
i was making a joke damn it :)
-
Pete O'Hanlon wrote:
Sadly, the reality often falls far short and there's just as much pain in supporting said application, having followed a vastly increased development time as you spend so much time working round web app limitations.
Same thing happens in desktop apps. Count the calls to
DoEvents()in a legacy VB app, and you'll get a feel for how much time the author spent fighting, rather than working with the threaded, event-driven model of Windows desktop apps...Shog9 wrote:
Count the calls to DoEvents() in a legacy VB app
No I won't. ;P Seriously though, I agree with Pete, browser development is seriously limited, it is supposed to be. That is not at all comparable to the limitations of the Programmer using the tools. The invention of the Web and Browsers was never intended to be used as a replacement for client/server desktop applications. The pains we are currently going through is no more than squeezing a balloon where we transfer the problems associated with installing/maintaining local software to a whole new set of problems that are generated using browser development. The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches. There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit. I am fairly confident that history will view this as a an all to common failure.
-
Shog9 wrote:
Count the calls to DoEvents() in a legacy VB app
No I won't. ;P Seriously though, I agree with Pete, browser development is seriously limited, it is supposed to be. That is not at all comparable to the limitations of the Programmer using the tools. The invention of the Web and Browsers was never intended to be used as a replacement for client/server desktop applications. The pains we are currently going through is no more than squeezing a balloon where we transfer the problems associated with installing/maintaining local software to a whole new set of problems that are generated using browser development. The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches. There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit. I am fairly confident that history will view this as a an all to common failure.
led mike wrote:
The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches.
Sure they do. Or rather, they can - don't think of it as HTTP+HTML vs. C++ native app running as root/admin, think of it as a VB app running as a limited user: you've accepted certain limitations in exchange for a framework that lets you do certain things more easily / provides extra security for your users / etc. Folks did some rather complex apps with VB, but still the framework was never designed for multithreading, access to system APIs, etc. In both cases, as soon as you step outside of what was easy, what was envisioned by the designers (data-entry forms / static text pages...), things got weird and difficult.
led mike wrote:
There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit.
IMHO, the primary difference with the Web stuff is that we're not in control. After decades of writing apps that - given the right choice of language and library - could pretty much treat the user's system as their own private playground, we're back to writing server software that has only very limited control over the terminals it must use for interacting with users. You really can't publish system requirements for a web page if you want it to have a broad audience; for an internal app, you might be able to mandate a certain browser version and perhaps also screen size and color depth, but ultimately the user still has final say over more factors than you do, and if you don't accept that then both of you will suffer for it. And... I love it. Because the truth of the matter is, for every desktop app that understood the responsibility that came with the power to control everything, there were scores of apps that saw it as a invitation to abuse that power, to reach in and screw with my system in rude ways, place arbitrary restrictions on how i could use the app itself, or fail to play nicely with other apps. It's forced developers to learn to write scalable software, after decades of "threads are hard, let's call DoEvents" attitudes. And it's put the users back in control of their own data and their own hardware.
-
led mike wrote:
The inherent limitations of HTTP/HTML have no comparable limitations in desktop development and likely tip the scale when comparing the two approaches.
Sure they do. Or rather, they can - don't think of it as HTTP+HTML vs. C++ native app running as root/admin, think of it as a VB app running as a limited user: you've accepted certain limitations in exchange for a framework that lets you do certain things more easily / provides extra security for your users / etc. Folks did some rather complex apps with VB, but still the framework was never designed for multithreading, access to system APIs, etc. In both cases, as soon as you step outside of what was easy, what was envisioned by the designers (data-entry forms / static text pages...), things got weird and difficult.
led mike wrote:
There are certainly perfectly good scenarios demanding browser based applications. However the current trend completely ignores the choice of desktop versus browser even in situations where the criteria clearly suggests desktop would be a better fit.
IMHO, the primary difference with the Web stuff is that we're not in control. After decades of writing apps that - given the right choice of language and library - could pretty much treat the user's system as their own private playground, we're back to writing server software that has only very limited control over the terminals it must use for interacting with users. You really can't publish system requirements for a web page if you want it to have a broad audience; for an internal app, you might be able to mandate a certain browser version and perhaps also screen size and color depth, but ultimately the user still has final say over more factors than you do, and if you don't accept that then both of you will suffer for it. And... I love it. Because the truth of the matter is, for every desktop app that understood the responsibility that came with the power to control everything, there were scores of apps that saw it as a invitation to abuse that power, to reach in and screw with my system in rude ways, place arbitrary restrictions on how i could use the app itself, or fail to play nicely with other apps. It's forced developers to learn to write scalable software, after decades of "threads are hard, let's call DoEvents" attitudes. And it's put the users back in control of their own data and their own hardware.
Shog9 wrote:
there were scores of apps that saw it as a invitation to abuse that power, to reach in and screw with my system in rude ways
Agreed. I guess I am looking at it from a developer perspective of being forced to deal with all the limitations of a browser based scenario because of management decision based on nothing. Then after all that extra work they change the requirements to included writing files to the client machine and want the application to run in offline mode, yes from the browser. Keep in mind that there is almost zero level of real server based activity (like a database) in this application. It's just a giant Dilbert environment that I work in. No amount of stories can help someone realize the level of stupidity that we deal with on a daily basis. You absolutely have to be here to even begin to grasp it.
-
Shog9 wrote:
there were scores of apps that saw it as a invitation to abuse that power, to reach in and screw with my system in rude ways
Agreed. I guess I am looking at it from a developer perspective of being forced to deal with all the limitations of a browser based scenario because of management decision based on nothing. Then after all that extra work they change the requirements to included writing files to the client machine and want the application to run in offline mode, yes from the browser. Keep in mind that there is almost zero level of real server based activity (like a database) in this application. It's just a giant Dilbert environment that I work in. No amount of stories can help someone realize the level of stupidity that we deal with on a daily basis. You absolutely have to be here to even begin to grasp it.
