Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

Silverlight/.NET vs Flash/Flex (or not) and My Silverlight Wishlist

Pete Brown - 17 August 2008

I was going to present an analogy using different types of cars, but more often than not, the analogy breaks down on some key point or carries some baggage that just doesn’, and folks start picking apart the analogy and assuming it still applies to the real discussion. The only way to get a perfect analogy is to just talk about what you’re talking about :). So anyway…

Why is it ok to bark about the Microsoft desktop "monopoly" and then say Flash is great because it has 95% browser share? I call shenanigans. There is more than enough room in the industry for both Flash/Flex and Silverlight (and others) -- neither one should need to be a monopoly to succeed.

Lately, I’ve seen a lot of Flash vs. Silverlight posts on various sites. (To the person who thinks this is just about your post, it isn’t <g>). I usually do my best to stay out of those, because I think the “vs” story is too deep for any one person to accurately portray, but once in a while, I step in. Plus, once you’ve invested any amount of time in one of the technologies under discussion, you completely lose the ability (or at the very least, the perceived ability) to look at the comparison objectively.

It upsets me when I see folks gush over one technology by trashing the other. It makes it next to impossible to take any of their other arguments seriously. Silverlight and Flash/Flex are both very good, very capable development platforms. Both have a lot to offer. It’s not like one is crap and the other is great. It’s also not like either of the two companies can claim corporate sainthood.

For each project at each company, you have to ask yourself which technology is right for that project and that team. You may find, for example, that the RIA you’re building is a great target for Silverlight, but that ad that everyone must see when they hit your site really should be in Flash. You may find that having a house full of .NET developers leads you to naturally pick Silverlight for the productivity gains, or that the asset pipeline in Flash is just right for your creative folks.

That said, just because your shop uses Adobe tools for graphics design doesn’t mean it has to use Flash for RIAs – you can pull in your PNGs and JPEGs from Photoshop, and export your Illustrator files to xaml (either using Expression Design or using Mike Swanson’s XAML exporter) You don’t need to completely retool to use Silverlight. Nor would you want to; Adobe clearly has the upper hand when it comes to the bitmap and vector design tools.

I’ve spoken with some really smart folks who work with Silverlight, WPF, Flash, Flex and AIR every day, and they have good and bad things to say about both Silverlight/.NET and Flash/Flex (don’t trust anyone who has only good things to say about any specific technology because either they don’t use it enough to hit the warts, or they have too much invested in that technology to notice the problems). These are the folks that understand that there is more to the picture than a religious war.

So, without doing a comparison with Flash and Flex, despite the title of this post, here are some of the things I do and don’t like about Silverlight. Sure, there are lots of things here you can do in both technologies using different approaches (I consider the basics of LINQ to fall into that bucket), but this isn’t about that. This is just a list from someone who has Adobe CS3 installed, but who hasn’t done anything with Flash other than the most basic things.

What I Like about Silverlight

  • Subset of WPF. WPF is the premier windows desktop UI technology, bar none. You can build some amazing applications in WPF that were either not possible, or took too much effort in the past using mashups of windows forms and GDI+ and DirectX/OpenGL. I love that Silverlight is a subset of WPF and that the skills (and most of the code) transfer between the two.
  • .NET. When I code on the server, I use .NET. When I build desktop applications, I use .NET. Now I can code in the browser using .NET. When you can use the same tools and languages to develop across target platforms, you gain an incredible amount of productivity.
  • The Xaml editor in VS2008 is great. Intellisense (introduced in VB5 CCE, I think Intellisense is second only to syntax highlighting for making it easier to code) makes learning Xaml a snap. I’ve heard a lot of complaints about the Xaml editor, but it has worked well for me for some time.
  • Services are simple to use in Silverlight. From my discussions with other people, the idea of “just add a reference and the proxy is autogenerated” is pretty foreign in other development platforms. In the MS world, we just take this for granted.

There really is a ton more I like about Silverlight, but I don’t want to bore you with a gushing love poem :) Suffice to say that there is a lot more I like about Silverlight than dislike. I wouldn’t have dedicated all my free time (and most of my work time) for the past year and a half to it if I felt otherwise.

What I Dislike (or “My Silverlight Complaints and Wishlist”)

I’ve been writing production Silverlight applications since the 1.1 alpha (I mostly skipped 1.0), and as you can imagine, I have a few things I dislike and a few things I’d like to see implemented in the runtime and the tooling. The various Silverlight and tooling teams have done an amazing job getting as far as they have, but the job’s not done yet.

  • Audio playback for short events and loops. The audio playback mechanism in Silverlight doesn’t currently work well out of the box for event sounds (think gunshots in a game) and looping tracks (like background music in a game). There are workarounds for all of these things, but I would like to see support for this baked right into the platform. Supporting wav files would be a really nice addition here. The ability to create a stream and just have the audio processor play the bytes would also be extremely cool.
  • Business Application Starter Kit/Template. Once some of the things below are addressed, I’d like to see Microsoft (or the community) create a set of VS templates for standard bizapp scenarios. Similarly, I’d like to see a VS wizard to convert a Silverlight app to WPF Xbap or v.v.
  • Browser Networking Limitations. The browser imposes some serious restrictions on networking. The most annoying to me is the number of available simultaneous downloads. When you’re downloading thumbnails and queuing up video at the same time, you can run into non-fatal but annoying problems where some content makes it and others fail (presumably a time out) without any real warning.
  • Lack of Call-Based Security. I’d really like to see some support for passing credentials with service calls. This will help make Silverlight a true SOA-aware client. Granted this is more often useful for inside the firewall use-cases, but I get asked about this all the tame. While I’m at it, let’s have SOAP faults and some of the WS-* things that make the current services implementations so much more robust than they used to be.
  • Cross-Domain File Needed for RSS Feeds - Yuck. While I understand the underpinnings of this (How on earth would Silverlight know you were retrieving an RSS feed unless it already retrieved it), it is annoying that the vast majority of blogs are inaccessible to Silverlight and Flash. You might say “well, just stick a client access policy up on the server”. Well, Eugene Osovetsky has given me a good wake up call on why that is a bad idea, and I finally get the problems there. Basically, you don’t want to have this file opening up html forms for cross-domain access, or the app could spoof you, access your cookies etc.
  • Current Xaml Design Surface in VS2008 is bad. It’s read-only for the moment, but suffers from numerous beta problems like choking my machine, crashing the IDE, failing to render content etc. I expect this to be fixed by RTM (it has improved with Beta 2), but it is a problem right now. Blend will probably always be the design surface you want to use, but sometimes I want to just stay in one tool for more than a few minutes :)
  • Text Performance. Text performance in Silverlight isn’t that great right now. I expect some of it to be resolved in RTM, but right now you can take a serious hit if you animate something which has text in it. Most users won’t notice unless your app is overloaded with text, but I do.
  • Lack of Bitmap API. If you have a programmable bitmap API, and the ability to render Xaml to a bitmap, you can create just about any effect you might want. I’ve seen some cool implementations where PNGs are created on the fly, but that’s not quite what I want. Bitmap API will also make games much easier to write.
  • Per-Frame Callback. Another thing I’d like to see. Sometimes the app your writing will fight with Silverlight when it comes to rendering. This rarely happens on regular RIAs, but I was writing a Commodore64 emulator and felt the pain of both the lack of callback as well as the lack of a bitmap API. Granted, in a retained-mode system, you shouldn’t need this. However, sometimes Retained Mode isn’t quite what you need to solve the particular problem you have.
  • Offline Support. I love WPF. I think it is really the best choice when it comes to building an offline or occasionally connected application. (It’s also the best choice if you are targeting only Windows users). That said, the ability to write a cross-platform application so that it can be dragged off of a web page, or actually installed with an icon and the usual flare, is very appealing. I don’t consider this the blocking issue that many make it out to be, but I think it is important from a competition standpoint at the very least.
  • Client-Side Validation Framework. ASP.NET has validator controls. Silverlight needs something similar (ideally integrated with Binding) to make it easy to roll your own client-side validation display / notification using a standard framework. This is something that can likely be added on, with some sort of decorator model for the controls themselves.
  • Windowing / Navigation Model. For folks building fairly standard business applications, the lack of a window or navigation model is one of the first hurdles they must jump. I’ve done a little bit on my own with event bus and navigation patterns, but there can definitely be more done in this space. I think this would be a great CodePlex project as I believe the majority of the infrastructure is already in place.
  • Uniform Configuration Model. The clientconfig used for the WCF client is useful, but I’d like to see a regular app.config model that includes everything. Right now, on deployment, I need to tell folks to modify multiple configuration files to set production service endpoints as well as other production variables. Sure, I could hand-code the config file and feed that into the WCF client, but I’d prefer to see something uniform across all types of configuration in the application.
  • Better Codeless Prototyping (or more in Xaml). Right now, a designer has to do a fair amount of code to visualize a Silverlight application. Some of that has to do with binding, some with triggers, others with commands. I’d like to see Silverlight allow for more of the functionality to be defined using Xaml, so a designer can mock up the application without having to understand C#/VB/whatever.
  • Intellisense on Style Setters. I have no idea how you’d do this, but the string-based nature of the style setters makes mistakes both easy and common (and they can be extremely hard to track down). I’d like to see some intellisense on setters in styles and templates.
  • Bitmap Fonts. By the time they’re implemented, they may be out of style, but bitmap/pixel fonts can look really good when you’re using small text for labels or whatnot. The fonts in Silverlight tend to get a bit mushy at small sizes, although I understand there are some potential fixes on the way.
  • Alpha Channel Video. It would be nice to be able to play alpha video over the rest of your UI when building assistants and just plain cool effects. Think a video of a person walking across your UI pointing out things, without the UI being stored in the video.
  • Non-Affine Transforms. or “Simulated 3d”. I’m not sure that I need full hardware-accelerated 3d, but it would be nice to do something like coverflow (or whatever comes next) without having to deal with stitching.
  • Binding to Anonymous Types. I understand the issues here related to reflection and security, but you lose some of the power of LINQ if you always have to create strong types to hold the results in order to allow binding.
  • XPS and Printing. I’d like to see these implemented together so we can create real reporting solutions in Silverlight. This isn’t a show-stopper, as there are ways to print HTML, but this would be a nice to have for many applications. I don’t print as much as I once did, but I do print diagrams, maps+directions, and even the occasional report.
  • An RTF/HTML Rendering Control. This goes more to text manipulation. There are free third-party solutions available for RTF/HTML rendering, but I’d like to see Microsoft create a robust one that could be used for RSS readers, mail clients etc.
  • TextBlocks with Selectable Text. I’m putting this one on here as the last item, because I go back and forth on it. We’re used to desktop applications where you can’t select the text, but when something’s in the browser, you just naturally want to copy/paste text from it and into other apps. Not a deal-killer, but a nice to have. You can work around this with read-only textboxes, but those don’t support some of the same features as TextBlocks, and have other overhead.

Oh, and anything unique added here must be back-ported to WPF to maintain compatibility :)

Things I Consider Non-Issues

Here are some common complaints/concerns that I personally consider non-issues because of the types of applications I typically build, and the discussions I’ve had with other community developers. Note that I don’t represent the team or Microsoft, so just because I don’t consider something a big issue doesn’t mean they’ve written it off or have a similar opinion.

  • Lack of GIF support. Most folks moved away from GIF when the whole unisys patent lawsuit came out. The alternative offered was PNG, an open format that supports a lot more than what GIF ever could (with the exception of animation, but the web has far too many animated GIFs as it is). When Microsoft was slow to support alpha channel PNGs, everyone complained (me included) that they ignored the new standard in favor of some outdated. Now that Microsoft has a technology that supports PNGs rather than GIFs, there are complaints there too. Yuck. Give up your 256 color GIFs or use a server-side proxy to convert them to PNGs if you must.  I guess if you’re just displaying images from other sites, this could be an issue for you, but I haven’t run into that myself.
  • Lack of support for FLV (flash video). I can see how supporting FLV would be nice, but is it really necessary? In the long term, when both Flash and Silverlight reach similar levels of adoption, cross-support of proprietary video formats will probably not be a differentiating factor. I won’t complain if it shows up in the product some day, but I don’t see a compelling long term case for it. I do see a short term/transition case, but it seems a high price to pay for a transition technology.
  • Inability to Elevate the Sandbox. I think it’s good that Silverlight is as locked down as it is. Microsoft always gets nailed on security (even when it is not their fault). They took the right approach here and decided to release Silverlight in a tight state and then look at places where it can be safely extended later.
  • Asynchronous Networking. I think async is a good thing. I also posted an entry on how to chain networking calls if you need to take an action after some specific number of them complete. I will admit that allowing sync calls from a background thread would be a nice touch, but I’m glad they aren’t allowed from the UI thread.
  • Small Control Set. This will be fixed by the community, by Microsoft and by third-parties. I remember back in the early days of VB when the out of the box control set was really small. We always had to turn to overpriced VBXs (later OCXs) to handle it. Given that history, Silverlight has a decent control set out of the box, and according to a post from Scott Guthrie a while back, more are coming. The third parties have also stepped up, some even offering their controls for free. Nice!

There are other, more controversial things, that I’m going to leave off for now (like PPC support) as I, like all of you, can only speak for my projects and my customers, and my colleagues.

What do you think about the two technologies? What’s on your Silverlight wishlist?

       
posted by Pete Brown on Sunday, August 17, 2008
filed under:        

17 comments for “Silverlight/.NET vs Flash/Flex (or not) and My Silverlight Wishlist”

  1. Fallon Masseysays:
    This is a FANTASTIC list, however, your last two items, IMO, are HUGE, and shouldn't be ignored.

    In modern visual platforms, there are 4 basic food groups. Video, Text, Graphics, and Audio(VTGA). Without a solid text engine, this platform will be the equivalent of SL 1.0, just more functional.

    MS needs to deliver a robust text engine, and selectable text in a browser is no where near optional. It will be confusing to end users, and a complete pain when performing normal operations.

    Try being functional for one day without having to copy and paste some text from one place to another. Now imagine it was GONE... yeah, you'll get my point.
  2. A Seattle Based Developersays:
    I agree with many things in this post, but wanted to offer a couple of thoughts.

    The problem with "Client Side Validation" is you still need to perform backend validation because your server never can trust incoming data. Typically I'll let the client side do extensive "user friendly" validation that will offer useful, well written suggestions. Since I let the client side handle "user friendliness" I can afford the luxury of letting the server side return nasty, user-unfriendly errors and failures because if the server is getting the error, it means the user was trying to work around my client side framework and in a way "deserves" a nasty retort.

    What would be awesome is to get the existing methods of XAML/.NET validation to work in a way that can bounce stuff off the server via AJAX calls (eg: "hey server, is the login 'username' taken?" or "hey server, can you look up the user_id for 'someuser' for me?"). Dunno how that would look and I'm sure somebody will hook up a framework that interacts with their backend framework/language and silverlight.


    The biggest "problem" with Silverlight right now is how stripped down and spartan their data/property binding is compared to their big brother, WPF. At least in Beta 2, I cannot derive from a DependencyObject and even if I could, the method calls for registering a property are quite a bit more stripped down (where is my ability to pass in a default property value or a coercion callback?). Not matching WPF in makes it hard for me to port my existing user controls and class libraries into my silverlight applications. I'd have to touch pretty much every class library I've written to get it to register dependency properties in silverlight.
  3. Pete Brownsays:
    @Fallon

    I totally agree with your comments around text. That's one reason why the selectable TextBlock is on my list. When I go to a web page that has done sone javascript/layering funkiness to disallow selecting text, I get really annoyed.

    Pete
  4. Pete Brownsays:
    @A Seattle

    The trimmed nature of Silverlight when compared to WPF definitely takes some getting used to. It's my hope (and assumption) that that gap will close over time, at least compared to the current state of WPF and Silverlight. WPF will likely always be ahead, but SL should only be a couple steps behind.

    As to validation, this is the same problem we've had with asp.net client-side validation and even with windows app validation (validate in the client and at the service level). I'd love to write the validation code in one place and have it execute in both, but at the very least, I'd like to have a framework in place to allow me to do client-side validation (and validation error notification) in a fairly standard way. This should be easy to add-on, but I simply don't have the bandwidth to do it. I'm hoping this is something Microsoft or the community as a whole tackles in the future.

    Pete
  5. Richardsays:
    Top of my wishlist is that microsoft open up silverlight properly so that 3rd party implementations of the playback engine (e.g. Moonlight) are not based on a restrictive and revocable license. Until that happens I'll consider Silverlight as yet another MS Bait and Switch scheme. (Sorry if I sound bitter but I personally got screwed when MS canceled MFC for the Mac).
  6. junihorsays:
    That's a very good article, especially the wish-list part. Seeing where Flash has struggled, I think MSFT needs to address how to avoid SilverLight being abused the way Flash has been. In the past when you went to certain website loaded with too many Flash contents, it's distracting and annoying. If the Flash content is badly coded, the browser and the CPU could be dragged down to an unbearable halt, which is probably why FlashBlock ranks as one of the top FireFox add-ins. It's a difficult issue because on one hand MSFT certainly wants SilverLight to be widely used while on the other abuse would bring quite a bit of negativity.

    Regarding the reception, I think overall it's been positive. I was worried that these Olympics SilverLight streams would demand too much bandwidth, but so far so good. Hats off the people who make it happen. It's, however, not surprising folks from Flash camp came out with some sour grapes ("we still have 95% install-base"), and those from Ajax, noticeably Mozilla and Google, threw out some FUD ("MSFT has an agenda / wants to fight open web"). You kinda expect it anyway.
  7. Pete Brownsays:
    @Richard

    It is what it is. Sorry you were burnt with MFC, but I think this is structured quite differently from anything else done in the past. Not to mention that the technology is so different (porting MFC was far more problematic as it was very heavily tied to Windows, whereas Silverlight was designed to be cross-platform from day 1)

    I doubt Novell would have signed up to do this unless they felt they could both make good on the promise to deliver and be covered in a way that would benefit Linux users for quite some time to come.

    From talking with multiple people on the team and in other parts of Microsoft, Bait and Switch is not the mode here. They are genuinely interested in producing the best product they can, and ensuring it works cross-platform. If you delve into the Novell partnership at all, you'll see just how much Microsoft has helped the moonlight team.

    Pete
  8. Emmanuelsays:
    Great article. You missed one. Application start-up time. Most simple applications i have seen on the web starts-up pretty fast (under 3 sec) but increase the size of the app a bit and you will say a big jump in download before the application starts. I hope MS does a lot of optimization with good compressors to reduce this. I was surprised by MS Health Care apps demo (check it out at http://www.mscui.com/PatientJourneyDemonstrator/ ). They load very fast and that speed would be great but I know the data behind the app is a mock up. Because of that, I cannot use that as a sign of hope.
  9. Pete Brownsays:
    @Emmanual

    Thanks. Startup time (and the splash screen) is something you have a ton of control over. It really is directly proportional to the size of the app you're downloading and the number of elements you're instantiating.

    You can pre-load a shell xap, and load modules as-needed (or just in the background) to make the app start up quicker.

    While I always want to see Microsoft spend time on performance, I think this one is mostly in our hands.

    Pete
  10. Timmy Gsays:
    for my wishlist: a rich text editor. I know there are 3rd party controls for this but from an MS strategic standpoint, I'd think they'd want to make it as easy as possible for developers to start storing user rich text as xaml. Once you store something in xaml, you'll probably be stuck with MS technology for as long as you need that content (I know, its just xml but sticking with MS is likely to be the path of least resistance). From my experience, it often boils down to just these kind of things (displaying legacy data) that dictates what technology is used to create new apps. Which is also probably why people want an html display control in SL today.
    Oh and not thinking in terms of MS world domination: frankly, xaml is way better than the alternatives to rich text (html and rtf... yuck!)
  11. Timmy Gsays:
    I couldn't resist making another comment: What do you think of SL and Flash vs. the other choices (Web 2.0 & WPF)? In my opinion this is a greater question in terms of where the industry is heading than SL vs. Flash. SL & Flash seem to have all the major things going form them by having the deployment and accessibility benefits of Web 2.0 apps with the power of desktop apps. It seems to me that Web 2.0 and WPF will be relagated to special needs only applications. Apps that need higher permissions, ultra-powerful graphics...etc might stick to WPF and apps that need to be run on cell phones...etc might need Web 1.0 or 2.0. The rest will be RIA and right now that means either Flash or SL. Do you concur that Flash and SL are becoming the new "default" language choices and others will mainly be "use only if needed" choices?
  12. Pete Brownsays:
    @Timmy

    By Web 2.0, I'll assume you mean some of the cool things that have been going on the Javascript world. (web 2.0 is really about social content and other headier concepts, even though it often gets applied to design ideas).

    If I had my druthers, all applications targeted to Windows users would be WPF. It's just so much more productive than most web programming.

    For where I think Silverlight fits in: Silverlight is a couple things 1. a great broad-reach RIA technology for the web and 2. a stepping stone to WPF. I say more about that in my post "Why Silverlight 2.0 will Change How We Build Applications" from January 2008. Basically folks that should build desktop apps will start with Silverlight, hit some limit, realize how easy it is to port the code/skills to WPF, and then find themselves able to target desktop when it makes sense, and browser when it makes sense.

    Silverlight is more readily adoptable due to the tiny footprint and ease of per-application deployment (the xap is just content, not an MSI or something). Microsoft has taken steps in .NET 3.5 SP1 to make WPF easier to deploy. It remains to be seen how much uptake there is there.

    Javascript is javascript. While there have been incredible gains there in the UI space, for the most part, it is still "write once, test everywhere", which is a real problem. In addition, compared to Silverlight and WPF, it is an extra skillset, and not one everyone wants to major in. I'll also say that for most non-trivial applications, a Silverlight xap will be much smaller than the html + javascript that has to hit the client for equivalent functionality.

    One other point. I've just about finished writing a Silverlight Facebook application. I got about 1/3 the way throught that application and realized that all the RSS parsing code I had in the Silverlight client really needed to be server-side both to allow for cross-app caching and to serve the same content up through asp.net. I literally just moved the class files from silverlight up to the asp.net app and recompiled. It just worked. Try that with any other RIA or web technology.

    Pete
  13. Fallon Masseysays:
    @A Seattle Based Developer

    The problem with client side validation that bounces the validation off of the server is that it would be best done with sync calls. To do that with async calls is a mess.

    @Pete Brown: On your FaceBook app, I TRULY understand and appreciate what you said. We are able to share business logic and classes on both client and server without any loss of generality. It's a beautiful thing.

    I think I'm in love... with a platform(lol).

Comment on this Post

Remember me

4 trackbacks for “Silverlight/.NET vs Flash/Flex (or not) and My Silverlight Wishlist”

  1. Mirrored Blogssays:
    Post: Approved at: Aug-18-2008 SL vs Flash/Flex (or not) and my SL wishlist http://community.irritatedvowel
  2. Community Blogssays:
    Martin Mihaylov on Resizing the SL Object, Dan Wahlin on the Grid and a Flyout StackPanel, Robby Ingebretsen
  3. Community Blogssays:
    Martin Mihaylov on Resizing the SL Object, Dan Wahlin on the Grid and a Flyout StackPanel, Robby Ingebretsen