HTML vs. Silverlight vs. WPF

At Readify we focus on the Microsoft stack - WPF, Silverlight, and ASP.NET. The bulk of our projects are ASP.NET, some are Silverlight, and even less are WPF (though the WPF projects tend to be bigger in scope, so they're probably about even).

Usually the customer has decided on a technology stack before we arrive, and they've engaged us to help plan/design/build/ship the application. Sometimes it's too late to suggest technology changes, but other times we can influence the technology they decide to use.

When I'm faced with deciding on a technology, here is my workflow.

Deciding between HTML and WPF

I'll call out a few points:

  • My default choice is always HTML/web
  • If there's a very good reason to use WPF, then I will
  • Silverlight isn't on here

I'm not just talking about public web applications - I'm also talking about internal, line of business applications.

Here are some examples of where I would choose WPF:

  • A point-of-sale terminal
  • A data capture application for geologists in remote Western Australian deserts
  • An airline flight check-in kiosk

For everything else, the answer is HTML. That might be surprising, since I'm a "WPF guy". The reality is, I recognize that even with technologies like ClickOnce, web applications are dramatically easier to debug and maintain, and have a lower cost of ownership, than desktop applications.

So why isn't Silverlight on the list?

  • Most UI's are much easier to build and maintain in HTML
  • An ASP.NET->Database app is much easier to build than a Silverlight->WCF->Database app
  • ASP.NET MVC creates much more maintainable apps than Silverlight encourages, no matter how many times you shout "MVVM"
  • It will work on all mobile devices

Now, there are a few scenarios where you might be able to convince me that Silverlight make sense. But it is never going to be like this:

What Silverlight enthusiasts love

There is a possibility - high before HTML 5, but increasingly getting smaller - that you might be able to get me to agree to this:

The most we should use Silverlight for

Over time, I think the Silverlight box in that graphic will get smaller and smaller as browsers adopt HTML5 and we stop being so scared of JavaScript.

A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work full time bootstrapping my own product company around Octopus Deploy, an automated deployment tool for .NET applications.

Prior to Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm, where I was lucky enough to work with some of the best in the business. I also worked on a number of open source projects and was an active user group presenter. I've been a Microsoft MVP for WPF since 2006.

05 Apr 2011

Like.

Jack
Jack
05 Apr 2011

Ouch!

Poor SilverLight.

I guess the only difference on my workflow is: - Will I have more than X users? - If Yes then use HTML - If No then use WPF/SL

As with most things in our industry there are no metrics, but I'm guessing that WPF/SL apps are "faster"* to build than web apps.

But at a certain scale the deployment costs / reach implications make it such that a web app becomes the better trade off.

*This is very complex to work out of course, and depends what is taken into account.

Robert Wagner
Robert Wagner
05 Apr 2011

I agree, particularly since in-browser WPF is available, addressing some distribution concerns.

Once use-case you didn't mention was complex UI (or wow factor UI). I worked on a project where a requirement was that the UI had to make the customer go "wow" during a demo (unfortunatly at the expense of usability).

The nice thing we did was implement a "throwable" (think iPhone scrolling in 2D) calendar. I think that would have been hard to do on the web, particularly loading thousands of UI elements per second.

05 Apr 2011

I've worked with clients where I advice them against using Silverlight

That might be surprising, since I'm a "**Silverlight** guy"

But sometimes (often) is simply not the right tool. That doesn't mean that it's not useful at all. If we care about mobile devices or want to reach a broad audience, then Silverlight isn't an option. If we want integration with Hardware or we control the platform, then Silverlight would be a lot of pain compared to how easy it would be with WPF. However, there's a tiny bit in the middle where you need a better UX, don't need the reach of HTML and want to use features that are hard or impossible with the current HTML stack. A nice example of this is SaaS and premium content like games, charts and video on demand.

Often solutions will require the use of different approaches. We could have a public facing brochure website, the app itself in Silverlight for the ease of deployment, but some reporting scenario might be a VSTO Add-in for Excel that uses WPF.

I wouldn't have a 'default' and I wouldn't discard any.

I imagine when you refer to Silverlight you are thinking of the PC/Mac version only. Silverlight for WP7 is an obvious choice if, similar to WPF in the desktop, you need acccess to features not available on HTML or want to provide a more integrated experience with the OS.

05 Apr 2011

Hi Paul

Nice post. My workflow looks similar, I have 2 more "ifs"

  • Sockets over the web --> Yes, Silverlight
  • Team with high Silverlight Knowledge and low JavaScript knowledge --> Maybe Silverlight (some pieces)

.peter.gfader.

05 Apr 2011

Miguel,

A nice example of this is SaaS and premium content like games, charts and video on demand.

This is where I think my second example - build 90% of it in HTML, but use a Silverlight component for the charts - fits in. Even most SaaS applications shouldn't be 100% Silverlight. I think we need to stop thinking about Silverlight applications, and think about Silverlight applets - tiny fragments of UX that you drop in for that 10% scenario.

I imagine when you refer to Silverlight you are thinking of the PC/Mac version only

Yes. But Phone Silverlight is to Desktop Silverlight what WPF is to Desktop Silverlight - they're different runtimes built for different scenarios. The only thing they have in common was they were both called "Silverlight" :-)

05 Apr 2011

Peter, do you think Web Sockets in JavaScript will change that?

05 Apr 2011

@Paul

Peter, do you think Web Sockets in JavaScript will change that?

Yep, that might change that, in a couple of years though ;-)
As far as I can trust in these stats http://caniuse.com/#feat=websockets

PS: I like your general statement:
Its not HTML VS. Silverlight, but HTML AND Silverlight

Corneliu
Corneliu
05 Apr 2011

Paul,

I have to dissagree with your decision tree. I don't see any reason why a POS would be WPF instead of HTML/JS/CSS (I just build a POS originally in WPF and then rewrote it in HTML/JS/CSS and I could not be happier). HTML: - Extremly easy to style any random piece of your UI with zero interference betwen style and the rest of the code - Extremly easy to construct styles on top of styles: - SimpleButton->TogleButton->CustomTogleButton->ProgressButton->RandomButton with almost zero duplication. In WPF you need to copy 20 pages of XAML for that - Extremely easy to apply different Themes (just look at the WPF Themes on CodePlex if you want to throw up when you look at the XAML. Why do I need 10 lines of XAML to do a hover effect?). - Use a million jQuery libraries - Be able to have real "aspects". I apply 'myClass' css class to an element and I know it will get a behaviour because I can do $('.myClass').DoRandomBehaviour(). Way better separated than WPF - Can "scale" or resize based on resolution nicer. It took me 2h to "write" a layout optimized for 1024x768 based on my old layout optimized for 800x600. And "optimizing" means lots of changes in sizes, positions and number of ui elements visible. So the "Need to Integrate with Hardware" is my only reason why WPF would (maybe) be an option.

Corneliu.

05 Apr 2011

@Corneliu, I actually agree with you - I think WPF/XAML fail on many fronts compared to the CSS/JS/HTML trio. But I do think the internal web server model that you used in that application is a little much to expect most companies to implement.

That said, I wonder if it's something you could spin into an open source component. I'd love to be able to use ASP.NET MVC and Razor to build my desktop applications - currently Magellan is my best attempt to port the experience.

Nick
Nick
05 Apr 2011

As far as my current client is concerned they are way happier with Silverlight.

Some like Jeremy Likness would agree as well.

I'd agree with him as well.

But HTML5 and MVC etc look like making good strides forward. At least it brings some form to the mish mash HTML.Javascript has been in the past.

Looking forward to using it myself...

Nick
Nick
05 Apr 2011

Coincidently Jeremy Likness has posted his latest views on Silverlight and Html 5 tonight.

He has somewhat, sensibly, moderated his views.

http://csharperimage.jeremylikness.com/2011/04/silverlight-5-beta-here-html-5-sterling.html

AnonCoward
AnonCoward
05 Apr 2011

So why isn't Silverlight on the list?

  • Most UI's are much easier to build and maintain in HTML
  • Often times as devs we don't sell WPF/SL technologies well enough for our customers to see the benefits. Sure, most UI's which are quite boring can be done in Web, but UI's that stand out and have 'wow' factor, I think are much easier to build in WPF/SL than trawling through reams of CSS/js/HTML.

  • An ASP.NET->Database app is much easier to build than a Silverlight->WCF-Database app ASP.NET
  • Agreed

  • MVC creates much more maintainable apps than Silverlight encourages, no matter how many times you shout "MVVM"
  • I think the pendulum swings both ways here.

  • It will work on all mobile devices
  • Sorry but I Disagree - while SL is only on WP7, Mono has plans to put MoonLight on Andriod and already has MonoTouch. Sure, it's not there yet - but neither is the HTML5/JS mobile frameworks.

    06 Apr 2011

    Paul, I think you've missed a few key decision points.

    As other have discussed if you want a user experience that's not completely mundane then you should lean towards WPF. Its extermely rare to see a browser based enterprise app that's truly engaging.

    If you have users that are using the application for more than half and hour a day doing non-trivial operations then you should use WPF. Seriously, inflicting a browser hosted app on a user that going to spend a good part of their day 'living' inside the app is poor form. I've had plenty of browser based apps inflicted upon me by various clients - most that I only have to use for 10 minutes a week - and even that's hard to bare.

    @Cornelius - a browser based POS solution - you should be ashamed :-). Despite the fact that most POS systems have a requirement to work when disconnected they are required to be highly performant in terms of usability. Maybe you achieved that (despite your reputation I'm sceptical) but I'd suggest to any of my clients that the job would be much easier and with a better end solution if done in WPF.

    Personally I think the decision tree is much easier to do the other way up. If you need extended reach or platform independence then go HTML. Otherwise go WPF.

    06 Apr 2011

    +1 - my thoughts exactly Paul.

    Carl Scarlett
    Carl Scarlett
    06 Apr 2011

    Because technologies (and their capabilities) grow and change over time, when a new project comes along you really have to re-evaluate what the most appropriate solution is -at that time-. I think any architect/developer worth their salt will use the most appropriate technology for the task at hand.

    As usual, it's an interesting time to be a developer. There's a lot of overlapping areas on the HTML/Silverlight/WPF map and without careful consideration of the problem it can be difficult to guage the most appropriate technology to use in the solution.

    Personally, I'm wondering if the implementation of HTML5 will be truly standard across different browsers. In my (somewhat naiive) opinion, because browser capabilities are so subject to differences and change, I would much prefer the unmoving ground of a framework like Silverlight in a widely distributed app. Of course, it all depends on your target audience, deployment issues, etc, etc.

    No matter what choice you make, there will always be compromises. Just make sure you have collected enough information to give you the best chance of choosing the right option at the time. And for pete's sake, no religious debates!

    06 Apr 2011

    I don't think its a question of being "scared" of JavaScript it's more along the lines of why use it at all? I mean, JavaScript is a freaking ugly language to do work in most of the time combine that with CSS / HTML mutations that are going on and well it gets messy. If you're a solo pilot then sure, JavaScript may work for you, but scale that out to teams and it just gets unwieldy - it's why folks are often found gravitating towards WPF/Silverlight/FLEX/FLASH because at least with these languages the client UI layer is kept in some form of contractual binding manner - in that even with low maturity levels of developer(s) you still have to pass through a compiler for basic 101 syntax / and at times semantic checks in your code.

    JavaScript is a case of run, stare, tweak, guess, debug, write, refresh, stare, tweak, debug etc style workflow(s).

    HTML5 realistically only offers up more tags to geek around with, there's still a long march ahead of us for CSS and JavaScript vNext to get its legs. If ECMA4 was blessed tomorrow as being the vNext JavaScript - Sure, I could get behind it but why take 3 steps back just for the sake of plugin constraints today being shifted into tomorrows browsers?

    All thats really happened now is the boundaries have moved. Browsers will still fork, its how they differentiate.

    Jose Fajardo
    Jose Fajardo
    06 Apr 2011

    Using Silverlight in a mashup page is the main usecase for the types of Silverlight experiences I build. I've have rarely ever built a full page Silverlight app for a client, only in cases where they were for low spec devices that would not be able to run WPF and needed COM level access to hardware.

    Alot of Kiosks i've built for are very low spected machines..

    The majority of my work comes from web portals that need the following functionality

    1. Rich PivotViewer/Deepzoom experiences, talking hundreds/thousands of images that need a fluid experience to navigate thru.

    2. Heavy duty file uploader, being able to upload hundreds of files and use techniques like recovery during fails, restart from last session, client side hashing/virus checking before transmission, chunking transmissions..

    3. Complex printing/print previewing of data & UI pieces that goes beyond what the browser can handle (memory footprint wise and printer configuration wise). Printing in browser is a terrible user experience, and pushing the print work to a server is not a vaild solution in alot of cases. Sometimes we want to print on the client and have a great experience doing it..

    4. Complex Image editing requiring GPU pipeline activity and large memory footprints for processing.

    5. Complex 3D visualizations

    6. Complex charts

    7. Inline realtim social interactions with users, chatting, shared editing. I don't believe that websockets will fill this need, we need a more solid communication package like what is in Silverlight to deliver this in browser. We need a way to embed the same piece across possibly many pages in the portal and deliver a beautiful UI/UX that goes beyond what SVG/CSS/Canvas can deliver.

    Jose Fajardo
    Jose Fajardo
    06 Apr 2011

    All the above scenarios need to keep the user in the context of the web page they are on..

    All these scenarios are perfect for Silverlight!

    I understand that your biased against Silverlight BUT my experiences are completely opposite to yours!

    I respect your views BUT my opinion is that there are increasingly more scenarios where Silverlight makes sense over HTML5/WPF especially in browser.

    I believe with the whole movement into 3D GPU world this will even become more apparent.

    And i won’t even begin to talk about the Browser fragmentation, HTML5 implementation fragmentation out there.

    I respectfully disagree with you!

    06 Apr 2011

    Hmm - we've had very good luck implementing RIAs with jQuery and Canvas (works on most browsers, not sure about IE8/9). Also, Firefox 4 is available (along with several other current browses like Opera) on Android, so I'm not sure what AnonCoward is talking about (saying that HTML5/JS isn't there on mobiles)... maybe not on WinPhone7, but iPhone and Android are there.

    As for Silverlight being "multiplatform", er... unless you consider "a few different versions of MS Windows" to qualify, then no, it's not. Moonlight is not (nor will it ever be) a suitable platform for real development, as it will always be Silverblight's poor cousin (in terms of access to MS-only APIs, development investment from MS, etc.

    As a free and open source software developer, there is no question I've yet come across for which the right answer is Silverlight. I wouldn't want my customers to be dependent on something so vulnerable to the whimsy/incompetence/patent trolling of Microsoft.

    06 Apr 2011

    Sorry but I Disagree - while SL is only on WP7, Mono has plans to put MoonLight on Andriod and already has MonoTouch. Sure, it's not there yet - but neither is the HTML5/JS mobile frameworks.

    SL was a web deployable tech is not on WP7, but may be later in the year. Novell don't have plans to bring MoonLight to Android (that I'm aware of), nor to iOS - what they are planning, and what they have done, is MonoDroid and MonoTouch, which are mono wrappers/bindings around Dalvik and Objective-C that run on the respective platforms.

    There were talks, originally, to try and bring a XAML UI to MonoDroid, but it was ultimately decided using the existing XML UI system was time better spent.

    Paul is right - HTML is the only way to get an "app" working on all mobile platforms, including BlackBerry, WebOS, etc.

    Amin Kayyali
    Amin Kayyali
    06 Apr 2011

    Hi Paul,

    i think : JavaScript(including JQuery) + CSS + 4+ Team members = mess. Building UI using HTML,CSS and JQuery is time consuming specially when it comes to maintenance.Fix it here and break it there.

    Also comparing "HTML+ DB" vs "SL+WCF+DB" isn`t that accurate , coz most current web applications nowadays use the provider/consumer pattern, whether your service provider is a WCF service or just a simple class with contracts.

    Regarding mobile apps, twitter is a proof that having a client app is much user friendly than building a mobile version of your site.

    Richard Reukema
    Richard Reukema
    06 Apr 2011

    Hmtl 5 will do better than it's previous version, but to will fail like all other multiple-vendor software implementations. Do we really have to learn that lesson again?

    Nick
    Nick
    06 Apr 2011

    Actually Paul isn't being serious

    Nice social experiment...

    SL all the way :))))

    meni
    meni
    06 Apr 2011

    Richard Reukema, so you consider HTML4 a failure? I thin k you wanted to say HTML dev is hard, but other then that, your comment leaves me Speechless....

    06 Apr 2011

    @Nigel,

    An application that is used for hours on end by users is definitely a case that would cause me to lean towards WPF. Call center applications, high volume data analysis, etc., can easily be justified as WPF applications.

    That said, those applications tend to have many features bundled into them that are used much less regularly, which might be better as HTML applications (i.e., build two apps - one for the features people use all day, the other (web) for features they use once a week.

    06 Apr 2011

    @Carl Scarlett

    Well said. My goal isn't to say "never use Silverlight", just that I found myself having trouble justifying (to myself) why I should recommend Silverlight on almost every project. It's not that I won't use it - just that I'll always question myself when I do.

    06 Apr 2011

    @Jose,

    Those scenarios you gave are good examples of my second screenshot - the HTML application that uses Silverlight sparingly, where it makes the most sense.

    In your scenarios I didn't see a single example that would justify Silverlight having a DataGrid control, or forms support, or validation. The controls wouldn't be there if there wasn't a market for them. Why are customers buying into the hypeware around this? What amazing visualization are you achieving using a Silverlight TextBox rather than a HTML input?

    The assumption that I'm biased in this isn't true. I just find myself staring at requirements documents, for an application someone has decided should be Silverlight, and constantly wondering "why?"

    06 Apr 2011

    @Nick,

    I am serious :-)

    I'm glad your customer is happy with the choice to use Silverlight. And I'm sure if you explained the application to me in detail, and the context of the business, you could probably justify it.

    The point of my article is that in my mind, you need to justify using Silverlight (and WPF). Otherwise, the answer should have been HTML. If you were able to justify Silverlight for a specific feature, did 100% of the application really need to be Silverlight, or could 80% of it (the boring parts) have been HTML? If so, as a general rule, I'd expect HTML to have been a better answer.

    06 Apr 2011

    @Richard Reukema, @Jose, @Scott Barnes,

    I'm not suggesting you stop doing video in Silverlight and switch to HTML5. I'm not saying stop using Silverlight for pie charts and use canvas (I did say I'd consider those options more and more over time, so Silverlight may become less relevant).

    I am saying that if your Silverlight application is full of tab controls and TextBoxes, then you are really going to struggle to justify that to me. You can do a TextBox in HTML 4.01, it works on every browser, and a monkey can maintain it. You can even build a DataGrid (we call it 'table'). What possible justification do people have for using DataGrids in Silverlight?

    Jose Fajardo
    Jose Fajardo
    06 Apr 2011

    It depends on what functionality you want the textbox to present to the user and the experience you want to convey. Also it's up to us to think outside the box and possible influence the client in directions they never thought of, which includes talking/showing them possible new user experiences. They may like it or may hate it BUT I like to push clients visual expectations into all sorts of weird directions (whilst still meeting there original requirements)

    A search textbox, much like bing search/google search, whilst looks and behaves great in HTML I would love to see a much more visually rich implementation in Silverlight. I'm not suggesting I would re-write it and force people to use it over the HTML version, what I'm suggesting is if the user does have Silverlight then enable them this enhanced experience.

    [bare in mind these are just quick ideas that may or may not be usable functionally]

    Maybe as you type into the silverlight enhanced search box 1. It makes nice glowing effects around the text box representing something that makes sense to the user/business ??! Of course we try to limit this so as to not distract the user 2. Context based animations/sprites that flow around the textbox that land on search results to help direct the users eyes to important/relevant fragments of information. [basically extending how we currently highlight words etc. just making it more suttle and visually appealing] 3. Extend intellisense to possible start showing visual elements, animations, rich characters etc. 4. Add more 3D context to the intellisense results, tastefully ofcourse. 5. etc. [pushing the experience of what people expect from a flat textbox into unknown territory]

    [1/2]

    Jose Fajardo
    Jose Fajardo
    06 Apr 2011

    Also Silverlight doesn't need to completely replace the Search functionality it can act to inject nice experiences behind the existing HTML5 content. Like it can traverse the DOM just as easily as JQuery and place nice visual enhancements behind the HTML content (suttly).

    Now I know that your thinking, this is just a textbox, all the user just want's to do is get from search term to result as quick as possible. True BUT you'll be suprised with how much people's tollerance for complex visuals have changed over the last decade. Movies have made us start accepting 3D space, we've trained our senses to ignore fast distracting blinking adverts and focus on more subtle animations all on the same page. Our appetite for high visuals have changed (for good or bad is debatable)..

    If Silveright is not a good fit for a customer, ill go tell them and suggest something else (html5, flash, wpf, sharepoint ... whatever). BUT each technology has it's merits is all I'm suggesting!

    And to respectfully answer your question on "I just find myself staring at requirements documents, for an application someone has decided should be Silverlight, and constantly wondering 'why?' " - maybe your not seeing silverlight for what it can truly do. And I say that not to mock you, but because it's hard to see the true worth of Silverlight if your not a designer first developer second.

    [2/2]

    Brian Ensink
    Brian Ensink
    06 Apr 2011

    What about an app like Creately (http://creately.com/tour)? That is currently all Flash but could easily have been Silverlight. And it fills the entire browser window. I think it is a legitimate use of a plugin and am curious to hear what you think.

    Jose Fajardo
    Jose Fajardo
    06 Apr 2011

    In terms of a "DataGrid" - I've seen some pretty complex datagrid requirements from customers, hierarchical, multi-content type grids that allow filtering,sorting even on non-text based fields.

    One only needs to look at teleric/component one/infragistics grids to see the functionality bubbled up in those controls. That is the type of functionality that customers have asked me to build for them in there silverlight apps.

    Ofcourse I agree with you that if a customer wants a very simple datagrid table then Silverlight is overkill BUT thats not the types of grids customers are asking from me.

    Sometimes a customer has very complex functionality (business rules/visual rules) in there screens, hierarchical controls that affect each other, coplex drop down selectors etc, nice suttle animations that boil down complex business rules into simple to understand visual ques. In this case where there is a need to link a datagrid to all these other controls then a simple datagrid is justified.

    Again if its simple forms and not much need for complex taste animations/visual ques then ofcourse I'd recommend to keep it HTML.

    I agree with you that people are biased towards Silverlight, I really don't know where they got that from BUT I and others like me try hard to educate people to make the right choice.

    BUT I just think that us looking at the world thru HTML5 designed pages that havent changed much in the last decade is a bad thing. We need to move forward in our designs and thats where Silverlight really excels.

    I have been looking heavily at CSS3 and HTML5 especially Canvas and WebGL BUT the story for creating thes truly immersive experiences is too far out of reach for most people. I'm really hoping to see some amazing HTML5 tooling from Microsoft that will be the equivalent of Blend, and if it's as productive as Blend then Im hoping we'll see mass adoption of HTML5.

    06 Apr 2011

    Disagree. Silverlight is and should be default way to build desktop and web and to some part mobile applications. I think that WPF will actually disappear and become Silverlight 6 maybe. You can see Google trends, just compare "Silverlight,WPF". As far as html5 is concern, Script# is the way to go in order to reuse your existing .NET code. Silverlight > WPF (will be in a year or two if not already), Silverlight >> Html5. Script# > JavaScript.

    guruparan
    guruparan
    06 Apr 2011

    We have a product (commercially software) purely done in WPF (browser app/Full trust)

    Though we speak of most of other ideas/techs (asp.net or html 5 websockets etc etc), at end of day, we dont want to do maintenance*, rather than spending our precious time in investing new features to our product.

    We are planning to go ahead with SL5 by this year or q2 next year.

    • Maintenance -> Including a simple textbox & adding a new column in datagrid needs to conform with all those Javascripts which eventually cannot be even found while building the app (build error), nor it will skip during the testing or QA, and sadly those obvious unknown (but missed) errors will through up in production and eat our brain during nights/weekends!
    06 Apr 2011

    What possible justification do people have for using DataGrids in Silverlight?

    You can't easily load millions of rows in a HTML table (without the browser starting to struggle), but you can quite easily do that in a Silverlight Datagrid ;-)

    I have seen that, and yes I asked the question what this is for and who is going to use this.

    Nick Zdunic
    Nick Zdunic
    06 Apr 2011

    For those wondering about the viability of Monodroid, whell some are going for it

    Check out CSLA on facebook - http://www.facebook.com/CslaNet

    07 Apr 2011

    @Peter,

    That is a good point. However I doubt you would just rely on Ui virtualization - the data is probably async anyway in which case you could use JS. I can't help but think if the requirement is "load > 100" records into a datagrid, your UX is wrong, no matter what tech you use.

    07 Apr 2011

    I can't help but think if the requirement is "load > 100" records into a datagrid, your UX is wrong, no matter what tech you use.

    Agree!
    No user will ever scroll through a list longer than that.
    I see that so often though... #scary #demos

    07 Apr 2011

    What about integrating into Sharepoint? Silverlight provides a nice web part wrapper. Silverlight offers the most flexibility with desktop, web, mobile and soon xbox. With GPU acceleration and COM support and kinect API support etc. There isn't really much more you can ask from Silverlight compared to WPF for a business application.

    07 Apr 2011

    I can't help but think if the requirement is "load > 100" records into a datagrid, your UX is wrong, no matter what tech you use.

    Agree.
    Scary, that we see this so often though

    07 Apr 2011

    One more comment to vote up Silverlight: SL is a good way for porting desktop applications to Mac and Linux and to have them available on the web; later, if you need it you can port it on mobile platform using Script#, MonoTouch, MonoDroid. Silverlight is much faster for developing applications. IMHO, writing .NET code can't be compared to writing JS code. Just another scenario I've encounter the other day: you should use IIS GZip to compress data coming into your Ajax app. That's ok! But what about the other way? How can you compress data in JavaScript and send them to web server to decompress and use? I achieve that using SL/WCF in half an hour by using the same .NET (open source) code on the server and on the client. Let's see your Html5/JS solution in half an hour? What is your compress rate? Do you have JS Zip library? How did you decompress data on the server side, by rewriting JS code into .NET code? Have you actually achieved that in Html/JS?

    SL is and will be a full package. FixWpf.org stuff should be fixed. While WPF/E has not succeeded, it will be at least .NET everywhere (using SL, Script#), which Java seems to fail - JavaFx just don't exist.

    Intranet apps, prototype apps (LightSwitch?), I guess MS Office for Mac will be Silverlight, Sharepoint apps, I would say most of desktop apps should be SL, complex Ajax/Web apps should be SL, and Flex/Air stuff should be SL :). Even apps that can't wait for Html5 to be implemented in more browsers should be SL, first.

    Html5 should be used for web sites and where you need truly cross platform app, even on some new mobile phone, or you can't rely on the fact that some users need to install SL and that's very bad for your business. No doubt Html5 will grow and will be used more and more. Google Trends shows that SL is currently more popular than Html5: http://www.google.com/trends?q=silverlight%2Chtml5 So the timing is also important for proper decision: http://ishtml5readyyet.com/

    07 Apr 2011

    What makes Html a hard sell for me is always the poor IDE support. Despite Visual Studio 2010 having some great Intellisense, Javascript and not so much CSS now are a pain and frankly a bore to work with. You're also, by default, left with testing in at least 3 browsers if you consider yourself any decent, if not almost all of them if you can. Why would I do that if I could just code for Silverlight once, or Flash even? That's what a silverlight app, your first scenario, would always give me.

    Right now the web for me is "Do I need this on a mobile platform where I don't want to learn the specific language like Java or Objective-C? If not, do I want to keep the deployment cost to a minimum?" We've used a full blown silverlight-recreated-from-WPF to solve the latter question because we didn't want to fool with ClickOnce for an extremely rarely used app.

    I realize the web is different but have we really created an ecosystem that prides itself on pain as a barrier to entry? Has the linux culture of "make my man page read like rocket science speak your grandma will never understand" really prevailed here? I mean I'm for a little geek chest thumping but I seriously question some of these hamster wheel scenarios.

    I guess I'm saying if I had to quantify web development from a usability standpoint I would say for me it is completely unusable. Can I make it work? Yes. Will I want to punch your baby after I'm done? Oh hell yes. You can guarantee it.

    Bryan
    Bryan
    08 Apr 2011

    C# skills transfer to a plethora of contexts. Javascript skills transfer mainly between browsers (assuming you have a standardization layer like jQuery).

    XAML skills transfer between browser-based applications and Windows applications; HTML skills transfer mainly between browsers (assuming you know how to code around idiosyncrasies.)

    WCF skills transfer to most inter-process communication scenarios across multiple process types; ASP.NET endpoint skills transfer to web processes.

    Instead of asking the question "what justifies Silverlight?", imagine asking the questions from the other side of the coin. What about my particular project justifies:

    A mobile site over a native app?

    Wide-ranging interoperability and standards compliance?

    The friction of using different languages on client and server, one of which is not strongly-typed or compiled and has different, web-specific reference and deployment semantics?

    Cultivation of a set of skills that only apply in the context of web applications, as opposed to utilizing and sharpening existing skills for a much wider ecosystem like .NET?

    The answers to these questions always be the same for you, but it is still important that to ask them about every new project context. Nothing about HTML/CSS/JS is inherently better than Silverlight; treating Silverlight like a second-class citizen which needs to be justified more than the web triad is as big a mistake as assuming Silverlight serves all applications equally well.

    Andrew Newton
    Andrew Newton
    12 Apr 2011

    Hi Paul, thanks for sharing your perspective. I am yet to find a "need" to use Silverlight in my organisation at this point.

    I do have one project coming up where we need to build a GUI for people to input data while they are visiting clients in their home. So they want to be able to "download client details for day", then essentially work "offline" all day, then come back to the office and sync up all the data. However, they said it would be nicer if they had 3G and were able to connect when possible to work "online". So I am weighing up between Silverlight and WPF on that one. Any thoughts appreciated.

    The only other argument I have for Silverlight at the moment is with the advent of Lightswitch. I have not decided if/how Lightswitch would fit into our Development team yet, as a minimum it could be a good prototyping tool. But maybe there is a case for allowing "power users" to create their own applications using Lightswitch instead of creating Access Databases like they do now and maybe we could support them in that (we stopped supporting Access a few years ago and it has greatly increased out workload on re-writing all these little apps for 1-2 users).

    So unless some tool like Lightswitch (or Lightswitch itself) could produce a HTML output then that might be one type of scenario where Silverlight will live on and prosper.

    Another interesting tool is VisualWebGUI. I have done some research into it but basically you can produce a UI that is accessible as a DHTML or Silverlight with the same codebase. So that begs the question, apart from maybe a slight performance improvement for the client (MAYBE) - why would you bother deploying it as Silverlight if the DHTML version does exactly the same thing?!

    13 Apr 2011

    Hi Paul,

    Sorry, I’m sure this is true for the projects you’ve been working on, but I think you've over simplified this.

    There are lots of SL projects here in London. It's a very attractive option for large banking projects. This isn’t just limited to internal software platforms either. It’s common for clients to access certain banking platforms via the web.

    1. Push

    As it's already been pointed out, push based notifications are important to consider. Some “last mile” middleware vendors already have out of the box SL support. It’s a perfect fit.

    1. Concurrency

    Web sockets might allow you to deliver asynchronous messages, however I believe SL is better equipped to deal with concurrency. When it comes to concurrency SL has all the same features available as .NET except it’s in the browser. That’s incredible!

    You just need to look at Reactive Extensions JS vs. SL implementations to realise that Silverlight is the better option here. It’s not just SL is more capable. The programming model is way better.

    I’m not saying this can’t be done in JS/HTML, but at some point I think it becomes cheaper to do it in SL.

    Maybe to your workflow you could add a final if check.

    “If business requires web application & developer wants multi-threading?” - go to Silverlight.

    1. Web & Desktop

    It’s also common to provide web / desktop variants of the same product, offering similar but perhaps not identical functionality. As it's already been pointed out this brings WPF / SL combo into play. It’s nice if both solutions can share much of the same codebase.

    Nick Zdunic
    Nick Zdunic
    14 Apr 2011

    @James Miles

    Good timing on your post as I just spoke to a colleague over Skype who has been working at RBS and others and yes Silverlight is the rage.

    Chris Newey
    Chris Newey
    26 May 2011

    Paul

    I think your flow chart is inverted. Would you say that your html/js/css solution is more powerful, flexible, and maintainable than wpf? I think anyone with an ounce of sense would agree that wpf is the more capable technology. So the question becomes: does my problem justify the use of an inferior tool? In my circumstances there have been few times that it has been reasonable to NOT use wpf. Mostly it's been public facing views that need to be consumed by the masses. This is certainly not the typical case for LOB type applications. Here is my assertion: whatever you can do in html/css (in terms of ui), a good wpf developer can do better and faster (and in a more maintainable way). I just can't wrap my mind around the fact that some people actually CHOOSE to employ a browser in situations where they don't have to.

    Vahan
    Vahan
    30 May 2011

    I agree HTML/CSS/JS also AJAX it is best way to build web applications it is easy and powerfull for web I am use PHP . And for desktop applications only WPF/C#.