Why We’re Going With HTML(5) Instead Of Silverlight

142 commentsWritten on March 6th, 2011 by
Categories: ASP.NET MVC, Silverlight

I recently had to research which UI technology would be the best choice for the applications that my client is going to build in the next couple of years. This is a .NET shop, so there are 2 major directions you could move into: standards-based web development, or Silverlight. When you have to recommend one over the other, you ideally want to be able to back up your choice with more than just some opinions. So we made a list of candidates and did a POC for each one. Then we came up with a list of criteria, grouped in a bunch of categories. The criteria were all assigned a weight, and we scored each of them for all candidates.

In this post, i want to go over the categories of criteria, and discuss our findings. I'm also going to share the spreadsheet so you can go through the numbers yourself. Depending on your needs or your opinions, you can change the weights and the scores and see how that affects the outcome. I removed some of the criteria that were specific to my client, but it didn't have a significant impact on the outcome. For this post, I also limited the candidates to ASP.NET MVC 3 in combination with the jQuery family (jQuery Core, jQuery UI and jQuery Mobile) and Silverlight.

Here's a quick listing of the categories and some of their criteria (for the actual list, check the spreadsheet... the link is at the end of the post):

  • User experience (compelling UI, accessibility, intuitive/ease-of-use, accessible from multiple devices, accessable from multiple platforms)
  • Infrastructure (easy/flexible deployment, monitorability)
  • Security (safe from XSS, CSRF)
  • Performance (server footprint, client-side resource usage, asynchronicity, UI responsiveness, initial load times)
  • Code/Architecture (maturity, reusability of validation logic, simplicity, maintainability, flexibility, power, testability, i18n, feedback cycle, learning curve, potential efficiency, rapid application prototyping, readable URLs, extensibility)
  • People (limits the number of required skills, mindshare, documentation, community support, commercial support)
  • Strategic (future-proof, standards-compliant, differentiator, backing, vision)
  • License (do we have access to the code?)
  • Cost
  • Tools (IDE support, availability of extra tools, free 3rd party component availability, commercial 3rd party component availability

Depending on what you or your organization requires, some of these might not apply to you. Perhaps there are other criteria that you find important and that we missed. Nevertheless, i think this is a pretty comprehensive list which covers most of the factors that you need to think about when making this kind of decision.

This graph visualizes how both technologies scored, grouped by category:

I'm sure there are quite a few things about that image that surprise you. The first thing you might be thinking is "how can Silverlight score so badly when it comes to User Experience?". The answer to that is quite simple: if your users aren't using a desktop/laptop with Windows or OS X on it, there is no experience to be had at all. Users that require assistive technology are out of luck as well since accessibility support in Silverlight is still very poor. If you hold those factors into account, it really doesn't matter much that you can easily make Silverlight applications incredibly flashy (pardon the pun). Besides, most people get bored and annoyed with excessive animations rather quickly, so you're often better off not to overdo it. With that in mind, jQuery UI and HTML5 will easily meet your needs for that kind of stuff.

Another area where Silverlight scores very poorly is the strategic department. The fact that it's not standards-compliant obviously hurts a lot here, but there's more to it than that. First of all, the mobile story (again) pretty much kills it. Android and iOS don't support it. We already know it's never going to work on iOS and as long as it doesn't work on iOS, Android has no reason whatsoever to provide support because Silverlight simply isn't important in the grand scheme of things to any of the important players. Microsoft hasn't even announced a Silverlight browser plugin for WP7 yet and who knows if it will? That means that Silverlight web applications aren't usable on any mobile device right now, except for slates running a full Windows OS which looks like its only a tiny portion of the market. Secondly, despite its original tagline of "Lighting up the web", it appears that Microsoft only has about 3 scenario's in mind where it still actively pushes Silverlight: internal business applications, video streaming and native WP7 development. While internal business applications are certainly a large part of what we're going to do in the next couple of years, we're also going to build things that are available publicly and to a large variety of people. Going with Silverlight for the internal applications and HTML(5) for the public-facing applications wouldn't be very cost-efficient either since that means we have to train our developers for both cases. And it wouldn't make much sense anyway since HTML(5) is a great fit for internal business apps as well.

But, as you can see, there are areas where Silverlight scores better than ASP.NET MVC 3 with jQuery. For instance, when it comes to Tools, you can't deny the fact that Visual Studio and Blend cover a lot of ground when it comes to the whole Silverlight developer experience. At the very least, you can mostly stick to your familiar integrated environment, whereas with standards-based web development, you're likely to spend some time in Firebug or Google Chrome's developer tools instead of sticking almost entirely with Visual Studio. I personally don't mind (at all actually) to use other tools than Visual Studio, but there are quite a few .NET developers who do prefer to stick with Visual Studio. Which brings me to the People category. The biggest benefit that Silverlight has over standards-based web development is that you only need to know C# and XAML. With standards-based web development, you have to know HTML, CSS, JavaScript and the language of your server-side technology, in this case also C#. This might impact your ability to find new developers so Silverlight does have sort of an advantage there. Though i'd argue that you're better off in the long term with people who are willing to step out of their comfort zone instead of clinging to what they know. From a security point of view, Silverlight also scores better because you don't really have to worry about common issues such as XSS, CSRF and other vulnerabilities that are common in web-development.

So we have 3 categories where Silverlight scores better than ASP.NET MVC3/jQuery but that's far from sufficient to close the gap. Based on the weights we assigned to the criteria, the maximum possible score is 732. ASP.NET MVC3 with jQuery scored 568. Silverlight scored 304. Obviously, the results will vary depending on what you find important. Which is why we asked an analyst from one of those large IT research & advisory companies to give us some feedback on this. The analyst agreed entirely with our findings and our data, and confirmed that his company is recommending moving towards HTML5 to all of their customers. He even went as far as to say that Silverlight is hard to recommend, unless you're not targeting any mobile users and the applications are internal-only and you've already invested in the technology. I can't provide a link for any of this yet, but a paper about this will be published soon so i'll either link to it when it's out (if it's publicly available) or at least reference it.

I encourage anyone who is faced with the same decision to use the spreadsheet and modify it to your needs (adding more criteria, changing weights and/or scores, whatever) to see which one is the best fit for your situation. You can download the spreadsheet here.

« Highly Recommended Book: REST In PracticeReminder: My NHibernate Course Is Coming Up »

This entry was posted on Sunday, March 6th, 2011 at 19:11 and is filed under ASP.NET MVC, Silverlight. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

Newer Comments →
  • Daniel

    +1 for HTML(5)

  • Ollie Riches

    I’m not sticking up for Silverlight, but there are several illogical and naive assertions:

    ‘ The fact that it’s not standards-compliant obviously hurts a lot here, but there’s more to it than that.’

    You either ARE going for standards compliant or not – Silverlight like any other plugin based technology will be discounted, but if you are not then why do you keep mentioning it?

    Also has HTML5 been passed as a standard yet?

    ‘Which is why we asked an analyst from one of those large IT research & advisory companies to give us some feedback on this.’

    When you pay any kind of analyst for the right to ask a question they’ll read your research and tell you what you want to here – see financial ratings agencies and their contribution to the global credit crunch.

    • http://davybrion.com Davy Brion

      compliance with standards was not a must-have requirement, but it’s certainly a benefit

      as for analysts only telling you what you want to hear… not according to my client’s experiences. they routinely present them with questions like this and the feedback hasn’t always been positive

    • http://scarydevil.com/~peter/ Peter da Silva

      HTML5 is not a “thing” to be passed as a standard. It started out that way, but people started looking at related or similar standards and saying “that’s an HTML5 technology”. So, a lot of the part of what people are referring to as HTML5 already exist. Some of them have been around for a while. They work. Some of them are still coming down the pipe… they’re enhancements that will be available in the future. I’m sure that Silverlight will have enhancements in the future too (if you think about it, it would be a bad sign if it didn’t).

      That, I surmise, is why the title reads “HTML(5)”, not “HTML5″.

  • http://twitter.com/ntcoding Nick

    I think Silverlight has a better UI experience than you give it credit for. It has support for Windows Multi-touch (albeit not as grand as WPF) which is a theme gathering pace now the technology is becoming available.

    I’m not so sure how multi-touch (Natural User Interface) experiences will work on the web.

    Great article – thanks for the insight into your processes.

  • http://thezendev.com Dan Martin

    Great post. Whether you prefer HTML5 or Silverlight, you can at least appreciate the details behind the decision that you made.

  • http://twitter.com/peterhoogers Peter Hoogers

    I agree and this is what I have been saying since Silverlight came out. Even in the pre-ASP.Net MVC era, where your only real option for web development provided by MS was WebForms (ugh) and people were wetting their pants at the sight of shiny presentations by MS evangelists, heavily investing in Silverlight for client applications never seemed like the brightest idea to me. I even remember a discussion (albeit some time ago) where I was the con and you the pro-SL factor ;-)
    The growing markets of non-PCs that do webbrowsing (iPads, smartphones, heck, even fridges!) has only added fuel to the amount of insanity when choosing SL for internet applications.

    HOWEVER… The intRAnet case…
    If, like you say, you find yourself in a .NET shop where you:
    - are mainly doing internal applications
    - have (full) control over your clients’ hardware and software (hell, you still require Administrator rights to install the SL plugin)
    - have developers that already have a large C#/WPF skillset
    I think going with Silverlight for webapps here makes a lot of sense (if not the most). Narrower skillset required == easier to find people. And in a lot of environments, this is something not to be underestimated.

    Also; one thing I am missing in this analysis is maintainability though. I have no doubt that whatever functionality you can develop in Silverlight, you can do in HTML.
    However, in the case of UI-heavy applications, due to the very nature of both programming models, I think the HTML solution will be exponentially more complex to comprehend afterwards. This is something I try to keep in mind in whatever I create; “how easily understandable is this for the guy that will have to do maintenance programming after me?”. For me, Silverlight wins this section hands-down because of ease of debugging + no mixture of technologies to deal with.

    At our department, we’re doing mainly internal development. All developers have a WPF/SL skillset and unless there is a blocking constraint (externally facing and/or support for non-PC/MAC clients is a requirement) we choose Silverlight for webapps. This has worked for us so far.

    on a side note: why MS didn’t include a SL plugin in their new WP7 OS really is beyond me.

    • http://davybrion.com Davy Brion

      “However, in the case of UI-heavy applications, due to the very nature of both programming models, I think the HTML solution will be exponentially more complex to comprehend afterwards.”

      I’ve seen my fair share of XAML and Silverlight code and i really think ASP.NET MVC + HTML + jQuery leads to much easier to understand (and thus maintain) code. I have no doubt whatsoever that people can create absolutely incomprehensible monstrosities with HTML and jQuery. But then again, i’ve seen that happen with XAML and Silverlight as well. As always, your mileage may vary and it depends etc… :)

      • http://twitter.com/jmarbutt Jonathan Marbutt

        I would disagree. I have built and worked with many teams on very large Silverlight applications and ASP.net MVC, HTML, JQuery apps. XAML can be extremely powerful when done correctly and paired with the correct architecture it is much easier to maintain and test. But the key like you hinted towards is that it has to be done correctly. Any technology can be done poorly and many people do that both in asp.net, silverlight, php or whatever.

        But the main problem is that most developers working on large .net apps are not JQuery/Javascript experts who need to work with something that they are very familiar with. This is where Silverlight fills a niche, give them the distribution power of the web app, but with a client side that is closer to what they are use to.

      • http://twitter.com/_Mr_E Brandon Collins

        Are you aware of tools such as MEF and concepts such as MVVM? Not to mention the fact debugging javascript is a massive pain in the ass?

      • http://twitter.com/UXMagic Don Burnett

        I have done this to Davy, while that may be your opinion that’s not my reality at all..

      • Davidmaster

        i would disagree also,that may be happended by any other reasons.for most of the important. we should improve ourselfves and keep going.

    • Shawn Unisoft

      I think, on the whole, both windows forms and wpf have been overlooked for internal apps. I find am still banging out pure web applications, pure internal, and cannot understand the bias against thick client.

  • Valeriu Caraulean

    What about browser compatibility with HTML (5)? When you’re all HTML you have to deal with it. Standards are cool, but implementation may differ. Silverlight (when available) will run everywhere without tweaking a byte.

    Wouldn’t maintenance of cross-browser compatibility (for 3 big players) lower productivity and results of web-developers?

    PS: I’m not a web developer, just interested in topic…

    • http://davybrion.com Davy Brion

      Well first of all, Silverlight doesn’t exactly run everywhere… only on PC’s and Macs

      As for browser compatibility, the situation is getting better and better with time, though there will always be some issues obviously. The extent to which you’re forced to deal with this depends on whether or not you stick to the parts that are known to be implemented by all the major browsers. If you use something that doesn’t work in some browsers, fallback scenarios are usually not that hard or too time consuming to implement. I wouldn’t be surprised if it’s actually less effort than having to deal with the myriad of memory leaks in Silverlight.

      • Jason Christian

        Silverlight runs on Linux too – so the desktop is pretty well covered. I can only assume that the platforms you consider missing are mobile platforms (iOS, Android, Symbian). Which could be an issue if you expect a significant amount of mobile visitors.

      • Telmo

        I should have read the rest of your replies. I understand now that this was not a biased report at all. This was a flaming session against Silverlight. Comments such as “myriad of memory leaks” is a clear sign indicator that you did not perform any kind of fair analysis at all and already had the outcome in ind before you typed the first paragraph. But just for giggles here is something…

        In google: memory leaks javascript = 403,000 results + memory leaks jquery = 575,000 results + memory leaks html5 canvas = 52 700 results TOTAL: over 1 million hits

        versus

        “memory leaks silverlight” = 311,000 results

        Not saying its an accurate indicator but it sure beats generic “myriad” statements.

        • http://davybrion.com Davy Brion

          the important difference here is that with jQuery, you’re not required to use long-running pages so the impact of a leak is often a lot smaller than it is with Silverlight

      • http://twitter.com/UXMagic Don Burnett

        If you are having memory leaks with SL maybe you aren’t setting things up correctly in the beginning and using the right tools..

        • http://davybrion.com Davy Brion

          i’d love to see a post how you can avoid memory leaks entirely in Silverlight :)

          • developer

            I’d love to see the exact example that led you to memory leaks. We’ve developed a couple of LOB applications and I can’t imagine doing them in javascript. I wouldn’t mix user experience with cross-platform support either - these things are totally different pieces of the puzzle.

    • Dmitri

      That is why iQuery is mentioned, not just Javascript: jQuery library is browser-neutral, with incompatibilities taken into account by jQuery developers (God bless them)

  • http://twitter.com/cubas_carlos Carlos Cubas

    I agree w/ most of your points. I myself did one of these analysis earlier this year and found similar results.
    #yam

  • http://www.facebook.com/caidong Charles Cai

    Some biased opinion in the article. You can easily target ALL major leading mobile devices using C#: Silverlight for WP7, MonoDroid for Android, and MonoTouch for iPhone (except Nokia and BlackBerry, which are on the decline anyway).

    You can share most of your server side code and GUI logic code except GUI itself, which is platform specific. We architecture our server side to use standard RESTful pull and/or HTML5 compatible push (e.g. WebSocket or Server Event Source) technologies, and XML/JSON to make sure eventually HTML5/jQuery client can access without major rework on the server side.

    Toolings of HTML5/jQuery are not as good as Silverlight and we have to deliver to business productively now.

    Charles

    • http://davybrion.com Davy Brion

      if you’re going to do a separate UI for mobile devices, while you also already have a typical web interface for desktops/laptops, wouldn’t it make more sense to use the same technology (jQuery Mobile for instance) for the mobile variant? You’d be able to reuse more than merely the server-side code, not to mention the benefits coming from the familiarity with the technology.

      Also, you can’t reuse the Silverlight/XAML you’d write for WP7 on MonoDroid and MonoTouch… so again, that’s more required effort if you’d want to support all 3 of them.

      Besides, if you truly need native performance on mobile devices, i’d say you’re better off going all the way and using the recommended development platform for each device instead of going with something like MonoDroid or MonoTouch

      • http://twitter.com/UXMagic Don Burnett

        Another fallacy, it is possible to do this if you plan correctly.. My company shows user experience teams how to do this and write once and deploy multiple places. In fact I am teaching a course in this at my local community college. Windows Phone 7 doesn’t lock you into their UI patterns..

        • http://davybrion.com Davy Brion

          i’d love to see a post or something that shows how this can be done

  • Josh Robb

    The number one reason for me not choosing Silverlight is related to it’s Support Lifecycle. Microsoft only gaurantee 12 months notice before they EOL any release of Silverlight. http://support.microsoft.com/gp/lifean45

    Basically – at any time – you can be given 12 months notice to upgrade your app to the latest and greatest version of SL (irrespective of compatibility, deployment etc) or loose support.

    To build tech demos with this is fine. To deploy apps into multiple organisations with this kind of constraint is insane.

    • Scheveningen

      that doesn’t make sense, as Silverlight is always backward compatible. eg if the user has Silverlight 4 installed, your Silverlight 2 application will still work.

      • Josh Robb

        12 Months after V5 comes out – the V4 dev tools are unsupported.

        If your corporate clients with locked down desktops have not deployed V5 then your stuck. Use unsupported tools – or release a V5 version which can’t be used by X% of your users.

        • http://twitter.com/Pete_Brown Pete Brown

          The support comes in the form of GDRs – update releases sent out multiple times during the product’s lifecycle. If you have a locked-down desktop, you won’t get the GDRs anyway, so there’s no real loss.

          At some point, Microsoft stops producing GDRs and instead incorporates the fixes into the next (or by that time, current) release.

          Runtimes are backwards-compatible. In fact, they have “Quirks mode” to make sure that behavior (not bugs) stays consistent with the version you built against when the user has a more recent runtime.

          Note also that the V4 tools could create V3 and V4 apps. Presumably V5 tools will enable V5 and V4 (possibly V3) applications as well.

          Are browser vendors providing patches for the previous versions once the new versions are out and stable? According to Wikipedia, Chrome wasn’t releasing back-patches to previous versions. With the exception of a 3 day overlap in 9.0.597 and 10.0.648 (which could also happen with Silverlight given the releases are typically closer than 12 months), their version numbers and release dates are in sync.

          We’ve seen what happens when you provide support for a product for way too long *cough* IE6 *cough* :)

          Pete Brown
          Microsoft Community PM
          (unofficially speaking, that is)

        • http://twitter.com/UXMagic Don Burnett

          That’s not very fair Josh, I know many situations and businesses that I have been in where this is not the case at all.. Most folks (including myself and others that support Silverlight support older versions..

  • Scheveningen

    One thing you should consider is that you can successfully create a MVC3 / Silverlight application. I have done this and it is very flexible. This approach allows you to swap in html / silverlight and doesn’t commit you to the UI technology so much.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #806

  • Matt

    Nice article.
    MVC + JQuery are fantastic and I have always been a bit weary of Silverlight as a platform. I work with customers where Accessibility is a must have and standards must be stricly followed. It would be a hard sell to get our customers to adopt silverlight without a really good reason and like you said, take away all the flashy animations and what do you have???

    MVC + HTML 5 get my vote. If only they could finalise the HTML 5 standard before 2022 or when every it should be ready!

  • http://pulse.yahoo.com/_QP35HTSTDJTNIOOT4TWIR5ZRAY Adrian

    I wonder why you didn’t considered the automatic testing capabilities of both technologies as an argument to the comparison. For me it would be very important to have a fully testable application, done without headaches.

    • http://davybrion.com Davy Brion

      it’s in the criteria spreadsheet… in short: web developments scores better than silverlight because it’s easier to do fully automated browser tests and there’s also more community knowledge around it. Of course, when it comes to everything behind the actual UI, both are equally testable

      • http://twitter.com/jmarbutt Jonathan Marbutt

        Visual Studio has a testing framework built in that you can use templates for Silverlight to do UI testing. With Javascript, you still have to worry about every browser being different. We have run into problems with javascript on large applications where 3rd parties on client computers cause trouble because they are intercepting exceptions or just causing code to be ignored. So with Javascript you really need to test every possible configuration. Silverlight works no mater how you look at it after you have done the testing.

  • Sander Schutten

    What I really miss here is ‘what’ you are building. There’s no simple HTML5 / Silverlight comparison possible, because it all depends on what you’re doing. If your intent is to build an internet facing website that needs to be available to as much people as possible, off course you’d go with HTML5. If you want to build a graphic intensive application for an intranet scenario where you need to use multi-touch, there’s no way you’d even consider HTML5.

    Furthermore is the problem with these kind of things that you’re always biased when grading these technologies. From what I read and see in the spreadsheet, it’s abvious that you personally favor HTML5, so it’s not a fair comparison. E.g. you give UI responsiveness a better score for HTML5 when compared to Silverlight, with the reasoning that for Silverlight it depends on memory leaks and cpu/gpu. Off course, the same goes for HTML5 with the difference that Silverlight by nature is faster because it doesn’t use a scripting language like JavaScript. And I would also assume you would grade based on a good implementation, since complexity and skillset should be a different grade.

    Oh, and let’s not forget that HTML5 isn’t final yet and there’s no browser available that implements the full (current) featureset, how is it possible to give it a higher grade for license and strategic?

    • http://davybrion.com Davy Brion

      The ‘what’ could be anything, though multi-touch is not in the picture. Graphic-intensive is a dubious requirement… unless you’re absolutely sure that intensive graphics are necessary, you’re often better off not to go to far with it.

      “Off course, the same goes for HTML5 with the difference that Silverlight by nature is faster because it doesn’t use a scripting language like JavaScript.”

      The ‘language X is faster than language Y’ is often a meaningless argument… it all depends on what you’re doing with it. And if it really matters that much to you, keep in mind that all browser vendors are investing pretty heavily in improving their JavaScript performance.

      “how is it possible to give it a higher grade for license and strategic?”

      The source code of asp.net mvc is freely available… so is that of jQuery. With Silverlight, it’s not freely available. They’re both free to use, but access to the source is a rather clear benefit from a license perspective IMO. As for the strategic part, i think i’ve covered that pretty extensively in the post already

      • Sander Schutten

        I personally think you can’t decide on a technology that fits all scenarios, that’s why I brought up the question of what you need to do with it. I can perfectly understand that what your company needs to do with it is a better fit for HTML5, but if I were a company with experienced Windows Forms developers that develops intranet apps I would perhaps choose otherwise.

        I agree that a language doesn’t determine speed, but the point I’m trying to make here is that I find it strange to believe that HTML5 has a better UI responsiveness than Silverlight. I agree that browsers are getting faster at interpreting JavaScript, but their not even close at the speeds you get with Silverlight or Flash. I just think it’s silly to say that Silverlight has worse UI responsiveness than HTML5 because it may contain memory leaks and heavy animations. Doesn’t the same apply to HTML5 as well? If you have a heavy animation in HTML5 (that might not run on your GPU depending on browser implementation), is the UI more responsive than Silverlight?

        It’s personal if you like having access to the source. I don’t like it or actually don’t care too much. Having access to the source can mean you make changes to it as well. If you do that regularly (which I guess, else why would you need it anyway) you end up with a version of the software that is slightly different from the actual source. This eventually makes it more difficult to upgrade to later versions.

        • http://davybrion.com Davy Brion

          “Doesn’t the same apply to HTML5 as well? If you have a heavy animation in HTML5 (that might not run on your GPU depending on browser implementation), is the UI more responsive than Silverlight?”

          that is indeed likely, but the animation aspect is rarely overused in html apps
          with silverlight, a lot of people like to overdo it a little, or maybe the controls that you’re using are just a little bit to intensive on the gfx side. I know you can make Silverlight feel very responsive, but it quite often just isn’t all that responsive when it’s run on the user’s machine with far lower specs than the machines the developers use. At that point, you’d be surprised to see how quickly it loses it’s responsiveness and actually starts lagging in its interactions. Obviously, the memory leaks only make this worse if you keep in mind that not all of your users will have the same amount of available ram as your spec’d out dev machine

          “It’s personal if you like having access to the source.”

          it’s a good thing you can change both the scores and the weights in the spreadsheet then ;)

          “If you do that regularly (which I guess, else why would you need it anyway) you end up with a version of the software that is slightly different from the actual source.”

          it’s not about wanting to make changes to it… it’s more about being able to quickly figure out what’s going on behind the scenes when you run into problems and need to figure out a way to fix it or work around it

      • http://twitter.com/Pete_Brown Pete Brown

        If it could be “anything” then you’ve left out entire classes of apps requiring desktop, peripheral and other integration.

        I suspect the set is significantly smaller than that. If the customer said “tell me what to use to build anything going forward” then they asked the impossible. Tell then to use C/C++, as that’s about the only universal constant :)

        Pete
        Microsoft Community PM
        (unofficially speaking)

        • http://davybrion.com Davy Brion

          would you like to speak officially on why you’re not mentioning WPF for apps that require desktop, peripheral and/or other integration?

          • http://twitter.com/wiredprairie Aaron C

            (I assumed Pete was addressing the ‘multi-platform’ aspect of your original criteria, thus WPF isn’t an option).

            • http://davybrion.com Davy Brion

              that’s assuming that those integration features aren’t mostly targeting Windows clients

          • http://twitter.com/Pete_Brown Pete Brown

            If you’re targeting just Windows, then absolutely WPF is a good option. I mentioned C/C++ specifically in the context of “build anything” and multi platform and device support. You can also use Silverlight with COM (and p/invoke in SL5) if you want to retain some x-plat support, but you need to balance how much integration you do there as you don’t want your app to be nothing but platform API calls that could have more easily been dealt with via the .NET framework.

            If you were targeting only Windows users to begin with, I’d assume you’d pick something more native to the platform, as opposed to x-plat HTML.

            Pete
            Microsoft Community PM

  • Vvega

    as always: check the requirements and then choose the right tool
    We are building a web app that will be used in the itranet of our customers. we have to interface with word (open word file and upload it to the server if the user made changes)
    How can this be done with HTML5? The only choice is to use SL with OOB. DUe to the fact that the web app is not used in the internet, i can “force” my customer to install the SL plugin.

    • http://twitter.com/AndrewNStewart Andrew N Stewart

      I’m dealing with this by creating a small word vsto plugin that will send the altered word document back to the server. Just because you need to integrate with word once, doesn’t mean your entire application should be take a dependency on silverlight/wpf just the parts that need it do.

  • Anonymous

    I do have questions regarding the criteria you have specified.

    How, exactly, is “compelling” and “intuitive” related to framework rather than implementation?
    What benchmarks and tests did you run to measure performance? Did you break down each of your criteria and run tests against them?

    Looking at your spreadsheet, it seems you were determined to score SL low and are presenting this as a rationalization of a choice you had already made. Which is fine, but not quite as objective as you would like it to appear.

    • http://davybrion.com Davy Brion

      A compelling UI is one that draws attention and keeps you interested… with all of the features that Silverlight offers, i’d argue that is better suited for this particular criteria. You’ll also notice in the spreadsheet that Silverlight indeed scored higher than MVC3/jQuery for this.

      intuitiveness and ease-of-use are can be aided or hampered by a framework… it can be minor issues like how easy is it to set tab order correctly, or default buttons on a page and stuff like that. You can indeed make anything intuitive and easy to use, the question is just: what extra effort (no matter how tiny it might be) does it take to get there?

      “What benchmarks and tests did you run to measure performance? Did you break down each of your criteria and run tests against them?”

      no because that wouldn’t really tells us anything more than we already know… when it comes to server footprint, silverlight scores better because you can leverage the statefullness of the client. For client-side resource usage, google for “silverlight memory leak”… it’s quite depressing. CPU usage on slower machines isn’t exactly great either. There was a lot of silverlight development at my previous employer and we routinely noticed high memory and cpu usage… I think quite a large group of Silverlight developers would agree with that (if they bother to check at least). And as for initial load times, waiting for a XAP file to download is just a horrible first experience.

      “Looking at your spreadsheet, it seems you were determined to score SL low and are presenting this as a rationalization of a choice you had already made. Which is fine, but not quite as objective as you would like it to appear.”

      Those numbers were agreed upon by four of us… if SL scored low, it’s not because i wanted it to score low. Feel free to change the weights and scores to something you find more accurate and i’d be happy to hear how well Silverlight scores for you.

      • http://twitter.com/wiredprairie Aaron C

        Speaking from experience, it’s still difficult to write a rich JavaScript application in all web browsers that doesn’t use seemingly unnecessary amounts of RAM and CPU, and worse, leak memory. This is compounded when the app is used for many hours in a day without closing or navigating to a new page (much like a rich application). We’ve written many tests showing current FF, Chrome, and IE8 all can leak memory like there’s no tomorrow. :) (the good news is that IE9 seems to not suffer from many of these issues!)

        • http://davybrion.com Davy Brion

          we’re not planning on using the “everything can be done in one page” model anytime soon so we’re not expecting that to be an issue :)

          • http://twitter.com/wiredprairie Aaron C

            That’s an appropriate choice in many cases, especially when not trying to emulate a traditional installed application.

  • http://twitter.com/bartczernicki Bart Czernicki

    I have two issues with your stats:
    - performance…Silverlight can scale to 8 cores on the client, will have 64-bit support in Silverlight 5, GPU acceleration already baked in, 3D etc. This of course depends on the application, but Silverlight is faster than JavaScript almost always in local computational code.
    - Code/Architecture…that is debatable, but having business logic/DTOs that can be easily shared between server/Silverlight/WPF/other in C# to me is pretty big advantage in terms of code/architecture.

    Otherwise I pretty much agree…my breakdown would be:
    - Silverlight: LOB, intranet apps, integration with specific types of apps (i.e. Business Intelligence)
    - ASP.NET MVC3: cross-platform, web applications that fulfill a complete web strategy (mobile devices and PCs) and potentially invests in future HTML5.

    • Theburger

      Bart, you run a very pro silverlight website, so no surprise you have beef with a blog that doesn’t look favourably on Siliverlight.  However I’ll address your two points:
      1) Multithreaded, GPU support, great if you want to re-implement the IE9 fishtank demo.  For real work intra/internet apps that don’t require that level of graphics and/or threading, this isn’t a large advantage, unless you are going to deliberately write something like that to run on the client.  Then use Silverlight for that segment of functionality.  A large percentage of clients in the real world are still running on single or dual core machines.
      2)Code/architechture – your point is irrelevant.  We have a web app that runs a C# backend for the domain and dal and the UI consists of both Silverlight and HTML/jquery components. 

  • http://twitter.com/Pete_Brown Pete Brown

    I like both MVC and Silverlight. Between me, Jon, Joe and Jesse, we have really good coverage of both on my team. While I applaud the effort here, this appears, at least on the surface, to be a case of fitting data to a pre-drawn conclusion. You left a number of clues throughout the text showing your bias towards HTML5. I’m not saying that’s bad, just that you need to be up-front about it.

    Here are my personal (non-official) opinions :)

    User Experience: Outside of the developer community, most people cannot currently use HTML 5 applications. They simply don’t have compatible browsers. That will change over time, we all hope :) Linux is something like 1-2% of the desktop market – surely that shouldn’t result in an almost 100% drop. On devices, most have found that native applications seem to perform best and provide the best UX, hence all the ObjectiveC apps on iPhone. Certainly HTML and HTML5 will continue to make gains here.

    You *will* be developing more than one version of your UI for the years to come. Your mobile UI will (hopefully!) be different from your desktop UI. Each mobile browser will have its quirks, just like each desktop browser, so you’ll be back in test-everywhere land. HTML5/CSS3/jQuery is an awesome step forward, but it doesn’t solve everything.

    Strategic: If you’re planning to develop mobile applications as your primary target, this makes some sense. However, keep in mind that you’re unlikely to develop the *same* mobile app for multiple devices using the same UX in any case. It would be great if this were the norm, but it isn’t for the majority of cases.

    Performance: Not sure why Silverlight scored so low here.

    Code/Architecture: Surely this is pure speculation. You can design really good applications in either technology. Both have great architectural patterns. This looks like a personal preference and probalby shouldn’t be on the graph.

    License: You have access to the MVC3 code. You don’t have any more access to the ASP.NET and .NET framework code for *modifiction* than you do with Silverlight. While I love that MVC3 is open, in this context, this seems like another red herring.

    People: What about requiring developers to learn not only .NET, but also jQuery/JavaScript? You’ve doubled the developer knowledge requirements, but only show a small delta between the two.

    In the end, I’m happy you’re using any of our current and strategic products. However, graphs like this get picked up by the general community, and folks who aren’t invested enough to make their own decisions just take this as gospel. I encourage others here to look at the requirements for their own applications and future dev (for example, most IT devs will never build mobile apps, as much as they’d like to) and make their own decisions. I imagine you’d agree :)

    Pete Brown
    Microsoft Community PM
    (speaking unofficially)

    • http://davybrion.com Davy Brion

      “Linux is something like 1-2% of the desktop market – surely that shouldn’t result in an almost 100% drop. On devices, most have found that native applications seem to perform best and provide the best UX, hence all the ObjectiveC apps on iPhone.”

      have you checked out the mobile edition of Basecamp?

      “You *will* be developing more than one version of your UI for the years to come. Your mobile UI will (hopefully!) be different from your desktop UI. Each mobile browser will have its quirks, just like each desktop browser, so you’ll be back in test-everywhere land. HTML5/CSS3/jQuery is an awesome step forward, but it doesn’t solve everything.”

      as i’ve mentioned in a previous comment: wouldn’t it be better to provide one mobile version in a technology that you’re already familiar with from your regular web interface than to provide an iPhone version, an Android version, a Blackberry version, and a WP7 version? HTML5/CSS3/jQuery doesn’t solve everything, but it appears to solve a lot more than Silverlight currently does.

      “Performance: Not sure why Silverlight scored so low here.”

      again, as i mentioned in an earlier comment: For client-side resource usage, google for “silverlight memory leak”… it’s quite depressing. CPU usage on slower machines isn’t exactly great either. There was a lot of silverlight development at my previous employer and we routinely noticed high memory and cpu usage… I think quite a large group of Silverlight developers would agree with that (if they bother to check at least). And as for initial load times, waiting for a XAP file to download is just a horrible first experience.”

      “Code/Architecture: Surely this is pure speculation. You can design really good applications in either technology. Both have great architectural patterns. This looks like a personal preference and probalby shouldn’t be on the graph.”

      the majority of the Silverlight community uses MVVM, which we find unacceptable so if we were to go with Silverlight, we’d have to build and maintain a client-side architecure. That is indeed a personal preference, but it sure as hell is one that is very important to us. I know that actual code quality isn’t always a concern to PM’s at Microsoft, but you really ought to consider its importance to us, the people who actually work with code every day.

      “License: You have access to the MVC3 code. You don’t have any more access to the ASP.NET and .NET framework code for *modifiction* than you do with Silverlight. While I love that MVC3 is open, in this context, this seems like another red herring.”

      again as mentioned in one of the previous comments (you know, you could have saved both of us some time if you had actually gone through them): it’s not about wanting to make changes to it… it’s more about being able to quickly figure out what’s going on behind the scenes when you run into problems and need to figure out a way to fix it or work around it.

      you may not know about this, but if you want to find out why your silverlight code is leaking memory all over the place, it sure is useful if you can go through the code which event handler is never unsubscribed in a core silverlight control.

      “People: What about requiring developers to learn not only .NET, but also jQuery/JavaScript? You’ve doubled the developer knowledge requirements, but only show a small delta between the two.”

      the developer knowledge requirements are indeed ‘doubled’ but you seem to forget the fact that the community support is much larger for HTML/CSS/jQuery… you don’t just benefit from the .NET community’s knowledge on these things, but also from the Ruby/PHP/Java/etc communities. That is a huge factor that you ought not underestimate too quickly.

      “I encourage others here to look at the requirements for their own applications and future dev (for example, most IT devs will never build mobile apps, as much as they’d like to) and make their own decisions. I imagine you’d agree :) ”

      yes, that’s pretty much exactly what i said in the last line of my post… perhaps you missed some parts of that as well, like you did with the comments :s

    • http://davybrion.com Davy Brion

      “Linux is something like 1-2% of the desktop market – surely that shouldn’t result in an almost 100% drop. On devices, most have found that native applications seem to perform best and provide the best UX, hence all the ObjectiveC apps on iPhone.”

      have you checked out the mobile edition of Basecamp?

      “You *will* be developing more than one version of your UI for the years to come. Your mobile UI will (hopefully!) be different from your desktop UI. Each mobile browser will have its quirks, just like each desktop browser, so you’ll be back in test-everywhere land. HTML5/CSS3/jQuery is an awesome step forward, but it doesn’t solve everything.”

      as i’ve mentioned in a previous comment: wouldn’t it be better to provide one mobile version in a technology that you’re already familiar with from your regular web interface than to provide an iPhone version, an Android version, a Blackberry version, and a WP7 version? HTML5/CSS3/jQuery doesn’t solve everything, but it appears to solve a lot more than Silverlight currently does.

      “Performance: Not sure why Silverlight scored so low here.”

      again, as i mentioned in an earlier comment: For client-side resource usage, google for “silverlight memory leak”… it’s quite depressing. CPU usage on slower machines isn’t exactly great either. There was a lot of silverlight development at my previous employer and we routinely noticed high memory and cpu usage… I think quite a large group of Silverlight developers would agree with that (if they bother to check at least). And as for initial load times, waiting for a XAP file to download is just a horrible first experience.”

      “Code/Architecture: Surely this is pure speculation. You can design really good applications in either technology. Both have great architectural patterns. This looks like a personal preference and probalby shouldn’t be on the graph.”

      the majority of the Silverlight community uses MVVM, which we find unacceptable so if we were to go with Silverlight, we’d have to build and maintain a client-side architecure. That is indeed a personal preference, but it sure as hell is one that is very important to us. I know that actual code quality isn’t always a concern to PM’s at Microsoft, but you really ought to consider its importance to us, the people who actually work with code every day.

      “License: You have access to the MVC3 code. You don’t have any more access to the ASP.NET and .NET framework code for *modifiction* than you do with Silverlight. While I love that MVC3 is open, in this context, this seems like another red herring.”

      again as mentioned in one of the previous comments (you know, you could have saved both of us some time if you had actually gone through them): it’s not about wanting to make changes to it… it’s more about being able to quickly figure out what’s going on behind the scenes when you run into problems and need to figure out a way to fix it or work around it.

      you may not know about this, but if you want to find out why your silverlight code is leaking memory all over the place, it sure is useful if you can go through the code which event handler is never unsubscribed in a core silverlight control.

      “People: What about requiring developers to learn not only .NET, but also jQuery/JavaScript? You’ve doubled the developer knowledge requirements, but only show a small delta between the two.”

      the developer knowledge requirements are indeed ‘doubled’ but you seem to forget the fact that the community support is much larger for HTML/CSS/jQuery… you don’t just benefit from the .NET community’s knowledge on these things, but also from the Ruby/PHP/Java/etc communities. That is a huge factor that you ought not underestimate too quickly.

      “I encourage others here to look at the requirements for their own applications and future dev (for example, most IT devs will never build mobile apps, as much as they’d like to) and make their own decisions. I imagine you’d agree :) ”

      yes, that’s pretty much exactly what i said in the last line of my post… perhaps you missed some parts of that as well, like you did with the comments :s

      • http://twitter.com/Pete_Brown Pete Brown

        Thanks for the reply David. I’m not sure why the attitude. I read all the replies that were posted when I wrote this. I didn’t find the answers to the questions I posed here.

        MVVM: Not sure why you find it unacceptable. That’s your choice, though. It should have been made clear in your post, though. The first reference to it is in your reply.

        Performance: Your reply about the memory leaks was not here when I wrote my initial reply. Maybe I type too slowly.

        “I know that actual code quality isn’t always a concern to PM’s at Microsoft”

        Uncalled for. I am dissapoint. This could have been a rational discussion.

        Pete Brown
        Microsoft Community PM
        (speaking unofficially)

      • Guest

        Just a small comment since I don’t have time to read all this…
        If you design your Silverlight apps so people have to wait for XAPs to download, you’re doing it wrong. There are numerous ways to get around this so there’s no initial loading time.

      • http://twitter.com/Pete_Brown Pete Brown

        To be clear: I am happy that you are going with MVC. I just want to make sure other people coming here are very clear on how this decision process worked and how it may or may not apply to them. I am not saying you should have gone with SL or something else.

        If you take mobile out of the picture (again, completely depends on what you’re building), the scores are much closer. That’s a useful data point for folks making a similar decision. Similarly, if you take out the rumor-based ones, and some of the ones that are speculating about performance and memory usage using old data.

        Since I was clearly remiss in not reading the spreadsheet, here are some of my observations from that data:

        Memory leaks: basing long term strategy on a to-be-fixed bug (or bugs) seems ill-advised. Up to you. Keep in mind that the major data template bugs previously reported were fixed in a GDR.

        High CPU Usage: You’ll find similar things across other browsers when you try and do advanced animation. I wouldn’t say Silverlight is particularly prone to it compared to JS. You just hear more about it as SL animation has been out longer than JS/jQuery animation. Saying Silverlight is prone to this is no different than saying Browser X is prone to it.

        UI Responsiveness: Again, an unfair ding against Silverlight. Browsers aren’t going to be much different here.

        Initial load time: While you can certainly mitigate this with app partitioning with MEF and with assembly caching, it is more complex than an HTML solution. Note that a heavy HTML page with similar graphics payloads and with most logic all in jQuery without separate pages (not a model I like, but one which is common) will have similar load time issues.

        Feedback cycle: Rebuilding a xap, especially in a partitioned application (if your app really is that big) doesn’t take much time. Yes, it’s longer than posting a .js or .html file to the server.

        Reusability of app logic: Either use portable assemblies, or simply create two projects with linked files. Once set up, it’s very clean and easy to maintain. You also have 100% control in that you can add conditional compilation or partial classes to make up the difference. This does not require RIA services. I do think the jQuery story here, as I understand it, is better, but it’s not an all-or-nothing.

        Data Annotations aren’t really business logic. They’re basic annotations / validation. You’ll find they’re useful for just that. Same is true in Silverlight.

        Mindshare: WPF programmers, Silverlight programmers. Also add into the mix ex-Flash designer/developers. While I won’t argue that there aren’t more HTML devs in the world, I think this compares favorably when you get into what you’re looking for as gleaned from the spreadsheet (devs with cross-plat experience, MVC pattern, understanding of REST, CSS etc.). If you’re saying you’re likely to get quicker answers on Stack Overflow, that’s likely true. There are about 1.8x questions for asp.net MVC vs. Silverlight, but about equal if you add in WPF.

        Linux support: This is a really small percentage of the marketplace. Moonlight supports SL3 and much of SL4. Folks have taken non-trivial SL4 apps and had them just work.

        Rumors: Yes, you can ignore rumors. They’re just that, rumors. I wish we as a company did a better job dispelling those. While I hate that this took points off from three different line items, I can’t fault you alone for that.

        There are other things that aren’t covered in your spreadsheet that are in SL4 and/or SL5: Do you need to create reports? Do you need to access local system files? Do you need to integrate with the system and call COM components or APIs for escaping the sandbox? Do you want to be able to work offline? Do you need webcam/mic/3d support? Integration with legacy services and things like ws-trust? Networking on a background thread? Integration with local copies of Microsoft office (or other automation-aware programs)? Those may not be important to you; I can’t say without know what *types* of apps you are targeting.

        Pete Brown
        Microsoft Community PM
        (speaking unofficially)

        • http://davybrion.com Davy Brion

          “If you take mobile out of the picture (again, completely depends on what you’re building), the scores are much closer. That’s a useful data point for folks making a similar decision.”

          that’s why i encouraged people to change the weights and scores to see the best fit for _their_ scenario ;)

          “Memory leaks: basing long term strategy on a to-be-fixed bug (or bugs) seems ill-advised. Up to you. Keep in mind that the major data template bugs previously reported were fixed in a GDR.”

          it might be ill-advised, but it’s based on 2 years of seeing more leaks being introduced with each new version instead of seeing the number of leaks reduced. I also hope you don’t think the data template bugs is the only one. i still get a bunch of people on this site every day with the search engine phrase “silverlight memory leak”

          “Note that a heavy HTML page with similar graphics payloads and with most logic all in jQuery without separate pages (not a model I like, but one which is common) will have similar load time issues.”

          i agree that you can easily create slow loading pages if you include too much javascript code, but you’d have to add _a lot_ of it to make the initial load as bad as most silverlight apps

          “Data Annotations aren’t really business logic. They’re basic annotations / validation. You’ll find they’re useful for just that. Same is true in Silverlight.”

          What Data Annotations does offer you, is a way to get basic validation both client-side and server-side with very little effort. In Silverlight, there is no other way (unless i missed it) to get ‘automatically’ validating controls outside of using INotifyDataErrorInfo, and that requires you to manually take care of all of the details in the setters. Not exactly a convincing solution IMO. And no, we’re not interested in dealing with this through codegen either.

          “There are about 1.8x questions for asp.net MVC vs. Silverlight, but about equal if you add in WPF.”

          to keep things fair, we’d also have to factor in the fact that there are differences between Silverlight and WPF and that it’s not rare for those questions to include answers that begin with “this works in WPF, but not yet in Silverlight”

          “Linux support: This is a really small percentage of the marketplace. Moonlight supports SL3 and much of SL4. Folks have taken non-trivial SL4 apps and had them just work.”

          i find that very hard to believe, though i guess it depends on your definition of non-trivial… as i said in a different comment, Moonlight would require you to do browser testing and there’s no way to automate that for Linux => big PITA

          • jay-dubb

            I am in agreement with Pete Brown. There is just too much attitude in this article/comments. Upon reading the comments, please notice that Davy Brion has yet to agree to any of the well thought out criticisms or comments pertaining to a lively discussion of 2 different technologies. What you will read (IMHO) is a very snappy, biased reply to any discussion. To read comments that attack others and not provide an engaging conversation turns my stomach. Davy Brion, I will not read anymore of what you write. I now finish writing this ashamed I even spent the minutes reading this dribble.

            • http://davybrion.com Davy Brion

              i’d be more than happy to agree with something i find convincing
              but i have no reason to agree with “these-are-not-the-droids-you’re-looking-for”-handwaving

              and obviously, nobody’s forcing you to read what any of the things i write :)

              • Anonymous

                “i’d be more than happy to agree with something i find convincing”
                There’s a difference between disagreement and civil discourse.

                “and obviously, nobody’s forcing you to read any of the things i write :) ”
                Good point. Too many good tech blogs w/o the douchey replies. Don’t waste your time in reply. Bye.

    • http://twitter.com/AndrewNStewart Andrew N Stewart

      Hi Pete.

      It isn’t a problem of not supporting linux as your right for 1-2% desktop penetration it’s not worth the hassle and for mobile phones your going to have to redevelop the front end for the tiny screen. The question is how do you support the iPad and it’s many competitors which have 1024 x 768 resolutions and dont run windows or mac osx. These devices can quite happily run the same desktop web application as your windows desktops.

      You can’t ignore the exec who comes in with his shiny iPad and asks why he can’t use the company software.

      Andy

  • http://azzlsoft.com Rich Miles

    Cute chart, but it screams of confirmation bias. You shouldn’t marry yourself to a technology. Choosing Silverlight or HTML5 or something else should be dictated by the nature of the application, the environments it will be used, and your existing knowledge base. Your spreadsheet is so vague, I’m not certain it answers anything.

    Is it one application that is sold to multiple customers. Is it custom per customer? Intranet or internet? What percentage of users are mobile? Do mobile users need the full set of functionality or a small subset? Is it database driven? If so, what database technology(ies) do they use? Do they report on the data? If so, what is the reporting solution? There are lots of questions that this spreadsheet doesn’t answer.

    The bottom line is to choose the right tool for the job. If you have to make a complicated yet overly generalized spreadsheet to decide what technology you’re going to use, you’re probably doing it wrong.

    The bigger question you should be asking is why you’re a .NET shop.

  • Pingback: DotNetShoutout

  • http://www.facebook.com/profile.php?id=809232165 Rob Fisher

    Doesn’t linux have an open source implementation of the Silverlight plugin called Moonlight? Wouldn’t that resolve your issue of Linux has no Silverlight experience at all?

    • http://davybrion.com Davy Brion

      it doesn’t have a complete SL4 implementation, and who knows about the implementation of the SL3 features… they claim that it’s complete but still

      simply put, if you want to be sure that it runs properly on linux, you’d have to do browser testing for that specific version, and good luck finding a way to automate those tests

  • Fallonmassey

    Yikes! It’s statements like this that make me wonder about you.

    “The answer to that is quite simple: if your users aren’t using a desktop/laptop with Windows or OS X on it, there is no experience to be had at all. ”

    What user, especially a business user, exists that doesn’t use, and know that desktop apps make web apps look weak?

    I don’t know about you, but the way we look at things is a bit different.

    First, we KNOW that the back end is going to be almost IDENTICAL for whatever the client is, so a large part of your development is already covered.

    Now, it’s just a matter of building whatever client works best for the client. Currently, I wouldn’t use Silverlight for any client with internet facing applications, 70% penetration is totally insuffieient, or any apps that target mobile users. However, for the administration of those apps, I would use Silverlight, and for any internal(intranet) app.

    The bottom line is that this is a dumb exercise, the conclusions are KNOWN facts, so the result is akin to saying the Pope is Catholic… it’s no news, just attention seeking, IMO.

    • Kmanick

      I agree,  I seriously doubt we will ever see a version of a tool like SQL server management studio in html5 runnning on my phone? The tools you pick should be defined by the job requirements.

  • http://twitter.com/UXMagic Don Burnett

    As a graphics guy I have some serious problems with HTML 5, my problems there involve doing everything in Javascript and the events model or lack there of with the HTML 5 canvas tag (Apple contributed that and come on it’s 10-15 year old technology not something we should expect in 2011.. We shouldn’t have an HTML language at this point that requires javascript to do any of the things that HTML 5 does today.. I started life designing for netscape navigator with Dreamweaver 1.0..

    Also the problems with supporting CODECS with the Video Tag and Cross Browser differences..

    http://www.uxmagic.com/blog/post/2010/11/06/Supporting-the-HTML-5-Video-Tag-with-Fallback.aspx

    http://www.uxmagic.com/blog/post/2010/11/06/AI-to-Canvas-by-the-Mix-Online-Folks.aspx

    The biggest areas I really disagree with your chart actually has to do with the areas of performance, code/architecture, and user experience.. I do think you may not be factoring in some considerations having to do with cross browser UI and performance consistancy with HTML 5 in user experience across the HTML 5 browsers..

    I would be very interested if you do a post comparison after you have actually done a cross html 5 browser implementation. I believe that things aren’t as rosey as you think they are with this and there are serious inconsistancies that are as bad as HTML 4 and javascript were..

    I am not saying you should go with flash or silverlight, but I think your picture of the problems you’ll encounter across HTML 5 Javascript and CSS across different platforms (especially mobile html 5 implementations yes you safari). The picture isn’t as much a clear choice as you are making it..

    I have been doing web design and development professionally since 1996.. I really feel the advantages you are suggesting here aren’t as rosey especially around tooling as you expect. Enough so that it may negate your graph when you actually get into it.

    I remember in 1998 when someone was making these pronouncements about HTML 4 and the industry wouldn’t co-operate even though web standards were “hailed” then. You’ll still be hindered by extra development costs across mobile html 5 browsers off the bat. Some even due to security issues..

    Either way I really hope you follow up to be fair with the inconsistancies you find across html 5 browserdom including speed issues databases and webstorage.. There just are a number of things here you are just completely leaving out of the equasion here..

    • http://davybrion.com Davy Brion

      i have no doubt that we’ll run into issues related to multiple browsers implementations and the like, so it’s not like we’re expecting a totally rosy future because we’re going with HTML

      i’m not saying that HTML(5) is perfect… we just came to the conclusion that it’s more suitable for us than Silverlight

      • http://twitter.com/UXMagic Don Burnett

        I should probably also disclose that I am an Expression Blend MVP and you might remember me as the content guy from Microsoft’s original phizzpop.com site, so I am purposefully avoiding the comments relating to Silverlight (my own opinions are very well represented by others here)..

        It really is important to note that everyone should consider using the best tools for the job. I am not going to “pile on” with the other comments. I would just say all of this to make sure everyone posting (Silverlight proponents or not) and remind everyone that there is probably a difference between something you’d deploy to a mobile device as a web page, versus even a mobile app, versus a platform app..

        Apple really had a great strategy with the iPad to not allow Flash and Silverlight on it even for app development so they wouldn’t loose development marketshare to other platforms..

        I really expect besides web applications and things for sale on proprietary “app stores” the future of stand alone software is a bleak one..

  • http://twitter.com/josephcooney Joseph Cooney

    I’m not really a Silverlight guy, but your low UX score for Silverlight doesn’t really make much sense. If you’re going to punish a platform for a non-existent experience then HTML5 scores really badly for people without electricity & people running older browsers. A more sensible way to do it (IMO) would be to say this is our target demographic. Of that group X% can access silverlight content and Y% can access HTML5 content. Do you know what these numbers are for your target audience and where they’re likely to be in the coming year(s)?

    • http://pulse.yahoo.com/_Y7J4PTFMP3IB5WYEBYXNUKKP7U Anonymous

      Jeez… i suspect that SL provides a pretty crap experience for people without electricity too. I propose it’s not unreasonable to expect people to have an up-to-date browser, just not reasonable to demand IE on a desktop.

      • http://twitter.com/Pete_Brown Pete Brown

        You realize Silverlight doesn’t require IE, right?

        As for up-to-date browser, you need to go by your target audience. If you’re targeting the broad web, the browser versions out there vary quite a bit.

        Pete

  • http://twitter.com/CSPSolutions CSP Solutions

    We believe this depends on the type of application you want to build, Silverlight is powerful and can help in developing a thick client.

    Depending on the type of computation and data caching you want to do on the client side, some client application are better build using Silverlight, especially client applications that need to access client machine efficiently, especial now you can call com dlls from your Silverlight, so imagine what you can do!

    If the client layer is going to be thick client by design, it is good to shift to Silverlight, to have this layer managed in a more efficient way.

    Using Silverlight can be much easier as well, because of the support and eBooks available, and all the tools from Microsoft that can help you build professional business client layer.

    For web applications, with simple forms and listing, using Silverlight in them is not necessary, and you can use HTML 5 and powerful client side libraries like J query, to create the animation and effects you want, and have them load directly cross platform, and faster than Silverlight.

    Is Silverlight good for mobile applications, this depends if you are developing mobile applications, that you want to sell over many platforms. For sure Silverlight is not a good candidate, HTML 5 is the promising road in this domain.

    Using Silverlight or not, is matter that depends on the requirements you have.

  • http://twitter.com/wiredprairie Aaron C

    “And it wouldn’t make much sense anyway since HTML(5) is a great fit for internal business apps as well.”

    Many enterprises are reluctant to upgrade to modern HTML(5) web browsers, especially if the old one “works.” What is the target browser today vs. tomorrow for your platform? I’d expect many enterprises to maybe have IE8, but only if they need to. Although jQuery can provide a nice abstraction layer, it doesn’t add things like a a 100% reliable canvas, SVG, fast JavaScript compiler, etc. FF, Chrome, etc., still aren’t enterprise ready. It’s on a road map for Chrome with hints of features popping up.

    That’s what makes this a much more difficult issue for many developers. What do my “customers” use for a web browser? It’s probably not the same browser developers use. :)

  • http://pulse.yahoo.com/_VAGSGY6B6VUWCJP6Q3UD4AZOTY Greg and Yasmin

    Android 3.0 Honeycomb is looking to allow for SL5

    • http://twitter.com/UXMagic Don Burnett

      There has been a build of flash player on most android OS devices since 2.2

  • http://twitter.com/wiredprairie Aaron C

    This was my rant about Silverlight back in November after the BobMuglia firestorm.

    http://www.wiredprairie.us/blog/index.php/archives/1162

  • Bob

    “If your users are not using a desktop/laptop with Windows or OS X on it”.

    It sounds like your users are perhaps iPad users? If they are then why the heck are you thinking of going with HTML? You need to build a native app and get it into the app store.

    In my opinion any scenario on the iPad which involves me having to run Safari is an instant “FAIL”.

    In fact, I think you can generalise this situation to “If you want a great experience on device X then build a native app for device X. If you don’t care too much about the experience then build with HTML and then try and test it in every combination of the browsers for device X”.

    It’s worth saying that Steve Jobs is publicly quoted as saying EXACTLY THAT with respect to Flash. He said “no way does someone else’s API get between our devices and our developers” and so you can perhaps ponder as to why he’s so vocal about Flash and so quiet about HTML. My hint would be because he knows that Flash represents a thread to his native stack whereas he knows that HTML doesn’t.

  • Mamosi

    Your graph has some highly disturbing, almost offensively wrong values.

    You need to reconsider some numbers in comparison to MVC3/JQuery:

    - SL UI experience
    - SL Performance
    - SL architecture
    - SL Licence
    - SL strategy

    Choose whatever technology you want, but for the love of yourself, don’t tell anyone about your graph.

  • Greg

    For shame for posting an “unbiased” piece that is anything but.

    It is invalid to discredit Silverlight for not being available on mobile devices while not mentioning that HTML5 is not available on ANY device since the standard is not implemented universally, yet.

    Source availability should not be considered at all as this can also be seen as a negative for security. It can also lead to non-standardized look and feel if the code base could be modified. Not everyone is on-board with the open-source movement.

    The ratings for “Strategic” are reversed. Silverlight provides a strong foundation for project planning and includes structures like MEF (Managed Extensibility Framework) to provide for future growth of a product. HTML5 is not even a complete standard and is not implemented the same by any browsers available today. How is it remotely fair to give HTML5 a perfect score when “perfect HTML5″ is not even defined?

    Code Architecture is another area where the scores appear inaccurate. The notion that HTML5 can score higher than Silverlight in an area which includes topics like maintainability, testability, and maintainability is laughable. As a developer of both technologies I can assure you that testing and debugging any HTML-based application is a nightmare compared to the same process in a Silverlight/.NET environment.

    What this article provides is a strongly biased opinion masquerading as fact.

    • http://lucisferre.net Chris Nicola

      I was curious where in the article he said unbiased so I did a quick search, and low and behold it brought me to your comment. Interesting how that worked.

  • Lee

    I am not sure what the fuss is about. They picked HTML5, and the author has his justifications. Everyone has their own reasons for picking this or that. Move on people.

    • http://davybrion.com Davy Brion

      some people just don’t want to hear bad things about technology they like and they get all emotional about it *shrug*

      • http://twitter.com/Pete_Brown Pete Brown

        Now now. That’s being unfairly dismissive.

        Pete

      • Mohib Sheth

        I think the same can be said as “some people just dont want to hear negative feedback on their analysis”.

        The moment you pitched HTML5 as “standards-based web development” was enough to tell the article was just a rant without any bias. HTML5 is not a standard, Period.

        Also, how come just one “analyst from one of those large IT research & advisory companies” view is enough to proclaim HTML5 is better than Silverlight, is beyond my understanding.

        • http://davybrion.com Davy Brion

          like it or not, it will be a standard… and do you really think it’s only about HTML5? It’s as much about ASP.NET MVC3, jQuery, CSS and _regular_ HTML than it is about HTML5

          also, this post was about why we are going with a HTML based solution over silverlight… i didn’t say it’s the best fit for your situation too… in fact, i encouraged you to change the weights and the numbers as they pertain to your situation

  • Pingback: Html5 & Silverlight– an opinionated post–‘what if’ « {Steve!=null}

  • Anonymous

    No they have problems when people make a technology seem overly limited, or that it fails to accomplish tasks. Sorry to say but I think your making the wrong decision, but whatever. What my company does and it works wonders. Is to build everything with Silverlight. Then port the user interface to the platforms used by our clients. If you keep mono based technology in place when building your back-end. IE stay away from using libraries mono doesn’t currently support. It takes almost no time to rebuild the front end. So why rebuild front ends for different platforms? When you can build just one front end / application right? Well not actually true, cause you have to rebuild the front ends for the various platforms already. Good luck if you think you can build a web app that looks good on the desktop and is user friendly on a mobile phone. Can you get it to work, yes but from experience I can tell you now, clients want a clean and fast mobile experience. So you either hamper your desktop web version, and dumb it down so it works for mobile, or you keep it as planned and mobile users complain about response, and having to scroll and how the menu system doesn’t look / work right.
    Instead of spending time finding / training all of your developers to learn jquery and javascript, Pick 2 of them, and have one learn iOS and the other Android. Have them pick up on mono coding, and you will be much happier with the results. You can provide awesome mobile experience, and great desktop experience. Hit our web app with a desktop / Mac get the silverlight page with all the bells and whistles that runs super fast. (85% of our users do it this way) If you out in the field and need to tag a few pieces of the application, load the app we built for it. Poof mobile customized, have android no problem, got Ipad no problem, got android no problem. All super clean and small code, already loaded onto the phone. Key there, your not streaming the whole UI your just making data calls, which saves on the users bandwidth costs, with companies starting to charge more and more for bandwidth this starts to add up as well.

    Overall the point is while its a nice thought or belief you can build once see everywhere, Html5,Css,javascript/jquery, is really just a myth. It has marginal support on Mobile OS, and it doesn’t work to just take CSS and have it attempt to scale based on screen size and orientation. It looks really poor when you try it.

    • Mike

      One axis I was wondering about here: If I make an HTML5 application that has a lot of client-side code in it, am I giving away my (clientside Javascript) code? In Silverlight, I am not .. I can Dotfuscate it and ship code to the client without giving it all away.

      Is there a way to get around this in HTML5?

      I’m thinking primarily of a realtime game, which HTML5 seems capable of handling, but I certainly don’t want to give away my code.

    • Fred

      and how does your silverlight app go running on an android or ios device?

  • Craig

    First, I like both SL and ASP.NET MVC. I think they both have their place in the world and developers need to stop running around with the latest and shiniest tool like it’s a hammer looking for a nail. After reading your article I wondered how far I’d have to scroll through the comments before the pro-SL crowd started decrying your decision. It was further than I expected.

    I think you actually undersold the skills needed for a good SL developer. I don’t think XAML is that easy to learn and, IMO, the tools still aren’t that mature. If you’re planning on hiring UX design specialists that’s a different story, but it seems most shops I’ve encountered want jack-of-all-trades developers. MVVM (although you stated in a comment you didn’t like it) seems to be the best way to build SL applications, and it has a learning curve as well as, to a new developer, it appears that “magic happens here.”

    I’m not at all questioning your decision. I’m assuming you made it because it was the right decision for your application. Everyone needs to make their own decision for their own applications, and to criticize someone else’s decision because they didn’t make the same decision your would have is unprofessional.

  • Craig

    First, I like both SL and ASP.NET MVC. I think they both have their place in the world and developers need to stop running around with the latest and shiniest tool like it’s a hammer looking for a nail. After reading your article I wondered how far I’d have to scroll through the comments before the pro-SL crowd started decrying your decision. It was further than I expected.

    I think you actually undersold the skills needed for a good SL developer. I don’t think XAML is that easy to learn and, IMO, the tools still aren’t that mature. If you’re planning on hiring UX design specialists that’s a different story, but it seems most shops I’ve encountered want jack-of-all-trades developers. MVVM (although you stated in a comment you didn’t like it) seems to be the best way to build SL applications, and it has a learning curve as well as, to a new developer, it appears that “magic happens here.”

    I’m not at all questioning your decision. I’m assuming you made it because it was the right decision for your application. Everyone needs to make their own decision for their own applications, and to criticize someone else’s decision because they didn’t make the same decision your would have is unprofessional.

  • Anonymous

    It’s like Charliee Sheen is making a technology recommendation. I like HTML5 because WINNING!

  • Tran

    This is a wonderful post. Thank you so much for the details and analysis approach. Excellent!

  • http://www.facebook.com/davidbubu David Shulman

    Excellent , insightful post.
    Tanks Davy

  • http://www.facebook.com/davidbubu David Shulman

    Excellent , insightful post.
    Thanks Davy

  • http://twitter.com/philippe_carlo Philippe Michiels

    Actually, Microsoft seems to have realized this earlier-on, quote: “Right now there’s a faction war inside Microsoft over HTML5 vs Silverlight. oh and WPF is dead.. i mean..it kind of was..but now.. funeral.”

  • Telmo

    Thanks for this great analysis but having gone back and forth with my development team for the last 4 months as to which technology to bank on I would have to strongly disagree with many of your points.

    User Experience
    The fluidity of Silverlight in comparison with CSS 3/HTML5/jquery is much greater. Silverlight takes advantage of both the Mac/Windows graphics card for rendering. Part of the user experience is the ability to render the same way regardless of which browser you use. So far, I have yet to encounter two browsers that handle the new “standards” of HTML 5/CSS3 the same way. With HTML 5 your only hope of achieving any type of similar user experience is to write a lot more code to ensure that you can have simple rounded corners in all versions of all major browsers.

    With respect to “assistive technology”, you can have better and more control over the sound card, video input (i.e. multi touch or pen based), and better control over zooming and scaling for the visual impaired due to graphics acceleration. In HTML5 you have… a zoom control in all browsers that many times resize text and iamges at totally different scales and depending on the browser can result in actually worse rendering.

    Standards Compliant
    You claim that Silverlight is not standards compliant. Why does “standards compliant” mean that it has to work on Android and iOS? Lets take Android as an example, where each release of the OS seems to be highly incompatible with the previous. Or the fact that Flash does not work on iOS – is Flash non-compliant? Very broad definition.

    Code/Architecture
    So let me get this straight… Javascript code running on several different engines using jQuery as a second layer, with CSS for styling mixed with HTML 5 and most likely a lot of exceptions based on which browser you are suing, all open to the end user for modification using any kind of HTML/CSS/JS inspection tool is better than Silverlight with .NET (C# or VB) which can be compiled into a single library (although not unbreakable much more secure). Code behind mixed with UI code and behaviour code is a much better architecture than a industry proven (Apple, Microsoft, etc.) model-view-controller architecture such as Silverlight. I totally disagree with this assessment.

    License
    Do you have access to the code? Which code the one that you write? This is a nonsense criteria. You write your own code in C# or VB with Silverlight. You write your own code with jQuery, CSS and HTML. It is no different.

    only need to know C# and XAML? Well lets not forget VB one of the oldest languages around. And by the way, you dont need to use Visual Studio if you do not want to. Very much like HTML, you can use your good old notepad++ for XAML or Blend or a few other XAML making tools.

    Perhaps you should step out of your comfort zone and try Silverlight. You might like it. Otherwise I will see you in 2013 when you are still trying to make your HTML5 business application 100% cross browser compliant using AJAX spinning GIFS. Welcome to 2011!

    Finally, if you are truly going to do a “fair” assessment between web technologies, why is Flash excluded from the mix? Adobe has been pushing Flex as a business development platform and obviously Flash as a front end “flashy” tool.

  • Jono

    Well, despite my personal opinions on the subject (I would tend to go the Silverlight route, and indeed have a large greenfields project I am pushing through on the tech) this article has produced some good discussion (amongst the odd flaming and ignorant remarks) around the merits of either option.

    It really is dependent on the project, but everyone also has a personal preference that will sway their recommendations. I, for one, like to recommend clients away from PHP, but if they want to go that way, I am happy to accomodate (I moonlight – I certainly wouldn’t recommend a .NET house investing time into a PHP project for a client that was guaranteed to be a loss-maker!) Apples with Oranges perhaps, but I did start my web dev on PHP and still do a lot of it.

    I do like that this discussion has brought up many valid points around standards compliance, shortfalls in development resource and experience, development tools, community, support (especially around the SL memory leak), and more. All of these points should always be considered when implementing Risk Management in any (large?) project. Pro and Cons should be weighed up against each other, and a score (like in the graph) is a more than valid way to decide on a final direction.

    Every project is different, but the merits of comparing tech is often overlooked – at least there WAS a comparison done!

  • http://robinosborne.myopenid.com/ rposbo

    Many thanks for an extremely interesting and informative article. I like how you’ve approached each technology to give a rating in various areas based on your intended use of that technology.

    However, I can’t quite understand why you’ve received so many bizarre comments telling you your opinion is wrong..

    • stdio

      I guess this is partly due to the uncertainty of the future of Silverlight. Microsoft’s attitude is rather ambiguous. This makes Silverlight developers more sensitive to (even slightly) negative comments against the technology they already invested on heavily.

    • http://twitter.com/Pete_Brown Pete Brown

      If you read the comments, you’ll see that it’s not at all what you’re saying. The issue isn’t the conclusion or his opinion, it’s the supporting data and the bias. Simply changing the weights is insufficient as the bias is built into the criteria itself.

      It’s also not about sensitivity as stdio below says (another unfortunately dismissive comment that misses the boat) it’s about being objective and transparent.

      Pete

      • http://davybrion.com Davy Brion

        the thing… i don’t have a problem admitting the weaknesses of HTML(5). However, you don’t really see the Silverlight defenders admitting weaknesses in their chosen technology.

        But what do i know, i’m the one who’s biased, right?

        • http://azzlsoft.com Rich Miles

          Your comments certainly make you seem biased.

          Certainly there are flaws with any technology. The problem is that you haven’t framed the discussion around the applications you are building or your target audience (the users). You have framed the conversation around “THIS technology is better than THAT technology” without giving any real context.

          There are very clear cases where HTML/CSS/ECMAScript is going to be a clear winner over Silverlight. There are clear cases where Silverlight is a better decision. There are a few cases where they overlap but those are more likely due to poor requirements gathering than a weakness of either technology.

          In all seriousness, if you expect a large number of mobile users then you should be strongly considering native applications.

          • http://davybrion.com Davy Brion

            i’d argue that you are one of the very few in this discussion that hasn’t shown a bias yet.

            “You have framed the conversation around “THIS technology is better than THAT technology” without giving any real context.”

            nope, i said that THIS technology is better for _us_… big difference

            “In all seriousness, if you expect a large number of mobile users then you should be strongly considering native applications.”

            if that market wasn’t so fragmented, that would be the most logical choice. But creating a UI for iPhone, Android, Blackberry and WP7 is just not doable for us. Even Facebook is going with one web-based UI for their future mobile clients… and they’ve got a lot more resources than we do.

  • http://www.exgeekblog.com Franck Jeannin

    More on Silverlight versus HTML5 at http://www.exgeekblog.com

  • Kul Pirate

    I totally disagree.

    1. As for user experience – currently Silverlight has around 70% market share in the web industry (taken from RiaStats and StatsOwl), how much market share do HTML 5 compliant browsers have? around 50%… so in terms of market share you have a better chance that your user will be able to see your Silverlight application rather than your HTML 5 application.
    Not to mention that if your user is in the 50% that don’t have a HTML 5 browser his transition to a new browser is much more cumbersome than installing a plug-in (most browsers installations even require an OS restart!)
    In the long run – 5 years in the future, maybe HTML 5 will pass in terms of market share – until then (in the next 2-3 years) it is less relevant.
    2. “cross-platfrom” is utterly bull-shit. There is no major (or even mediocore) web application out there that builds the same application for both the regular web and the phone (even with HTML 5) – take a look at Facebook, Netflix and almost every other “application” out there, this is because the experience on the phone and in a regular PC/Mac is entirely different from the phone – you need touch support (which doesn’t nativly exist in HTML 5), different GUI (uses GUI related to the OS) and you want native API’s support from that phone – any developer that tries to “bend” his application to work on everything will surely fail. And in that spirit – you built several applications (sadly) – one for the iPhone, one for the Android, one for the WM7 and one for the Web, and in that area Silverlight can save you some time that your client code base will be similar between WM7 and the web.

    There are many other things you wrote I strongly disagree with – but I don’t want to turn this into a “book” comment, so I will keep it with the above main concepts that you appear to be missing.

    I think the choice between HTML 5/Plug-in cased technology like Silverlight or Flash has a lot more to do with the specific application you are building (which you mentioned is a minor difference), in my book I would rate other things much more than others:
    1. How fast it will take you (which is relevant to your specific expertise) to build the application in a .NET client application (silverlight) compared to doing it in HTML (and also, how easy it will be to maintain/upgrade/improve the code).
    2. How long does your code need to last (it is OKAY to re-build your client application after 5 years, any application code that lives beyond 5 years usually sucks ass – take a look at recent GUI developments like multi touch that didn’t exist 5 years ago, for example).

    All the rest is mumbo-jumbo, because the differences between the two technologies are pretty small, so – like anything in life – pick the right tool for the right job – and in this case if you are heavy into .NET C# development and you don’t have a crazy requirement that your code will last 10 years – go with Silverlight, if you always were an HTML based web developer – go with HTML 5.

    Life is grey – sucess/failure will come regardless of your technology choise.

  • http://mattcasto.myopenid.com/ Matt Casto

    Thank you for your post. Most people only throw out their opinion or don’t bother posting to the internet the results of their research (I know I didn’t) but its awesome that you not only shared your research, but you shared your spreadsheet for others to tweak.

    I would say that one major category left out is offline capabilities. I’m currently developing a Silverlight 4 Out Of Browser application because my client needs rich functionality at times when an internet connection isn’t available. I have great hopes for HTML’s AppCache and local storage, but current support is pretty tenuous – IE 9 RC still has no AppCache support at all!

  • Sedgewick

    My intranet has ipad users these days. Don’t go to many meetings where one isn’t present. We just finished ripping out a silverlight solution for this very reason. The enterprise is no longer the domain of windows only, choose wisely.

  • http://twitter.com/ADefWebserver Michael Washington

    I think this shows that people need a HTML representation of business data. However, ALL of the application does not need to be in HTML.

    For example, a Student Information System, to manage students in a school. The majority of the application will be used by Staff in the school. They will not be doing their work on an IPad.

    However:

    1) Teachers in the classroom may want to take attendance on an IPad
    2) Parents may want to see the progress of their children on their IPad

    My solution will be to make the application in Microsoft LightSwitch (and save 75%+ in time and cost) and create HTML front-ends for #1 and #2.

    I describe the process here:
    HTML (including HTML 5) and LightSwitch at the same time?
    http://openlightgroup.net/Blog/tabid/58/EntryId/163/HTML-including-HTML-5-and-LightSwitch-at-the-same-time.aspx

  • McEnergy

    I don’t understand your comment about the accessibility support in Silverlight. Every Silverlight control has a UI Automation peer built into it to make it very easy for any assistive technology to use it. It also happens to be great for testing. What are you basing your comment on?

    • http://davybrion.com Davy Brion

      UI Automation framework hardly works on OS X

Newer Comments →

Meta

Recent Posts

Categories