Do you like Silverlight? Why? Really?

So, we’ve heard a lot of news about Silverlight recently from Mix 09. Great to see the platform evolve — but what’s the future?

Personally, I’m skeptical. I think there are several main problem areas in my eyes when it comes to developing with/for Silverlight:

  1. There are things that Silverlight can’t do. In past versions, it was much easier to list the things that Silverlight can do, but this is fortunately changing.

    Still, now Microsoft seems to use “business applications” as a guideline for the feature set. Well, for some definition of “business application”, that is. I think there’s still no printing support, and if my customer has the requirement of using a bar code scanner with my application, at the very least it’s going to be a PITA to make that work. If it’s possible at all.

    I have heard somebody say recently that this is not a problem, because Silverlight covers the important core and whatever is missing isn’t hard to do yourself. I call BS on that. Why have we spent many years adding all this functionality to the .NET Framework, if we don’t need 90% of it? Even if it’s possible or even easy to do some stuff manually — we haven’t created this framework just to drop it now and reinvent it all the time.

    In the end, my personal point of view is that there would have to be very compelling reasons for me to consider using a platform that restricts what I can do. Platforms with similar restrictions have been around for a very long time and I’ve always been hesitant to use them, because there’s a big lock-in effect associated with using such platforms.

  2. There are even more things that Silverlight can’t do. I mean, different things. Have they put in the whole of the Color enum yet? Last I heard, there was a lot of stuff missing from Silverlight that would make development very painful — like enum values, method overloads and the like. I imagine it will be much like learning a new framework… whatever knowledge of the .NET framework you have already, you will stumble upon restrictions of this kind continuously.

    Of course the idea behind this is sound — restrict the size of the framework, and the effort needed to port it, by reducing functionality in a clever way. But that approach is not compatible with making the resulting restricted framework the next silver bullet platform. Again, BS.

  3. A Silverlight that is getting more full-featured in certain places (like data or graphics support) competes even more obviously with WPF. What an extremely stupid thing to do — the availability of two different platforms with so many similarities has been confusing enough to most people the way it was before Silverlight 3. For almost all use cases, a WPF application deployed as an XBAP has the exact same end user appearance that a Silverlight application would have — but of course it would take you much longer to create the Silverlight app, because WPF benefits from the complete framework.

    Now some people are trying to resolve the chaos in their minds by saying WPF is dead. Once more, BS. Dead? How does that work? Visual Studio 2010, dead? Blend, dead? Ridiculous. The situation has just become more confused, that’s all. That’s what the world is like, deal with it.

  4. The evolution of Silverlight is absolutely chaotic. We’re on the third version within two years, and please go compare Microsoft’s vision statements with current reality. I understand that these things happen, and I can even guess at some of the reasons, but at the same time, am I going to base my own projects’ future on a project like that? Hm…

Maybe Silverlight is going to evolve over time to be as full-featured as the standard .NET framework. If that’s the target though, why do the extra work in the first place? The .NET framework was supposed to get us out of DLL hell, now we’ve got two different .NET Frameworks. What’s good about that, please? Hm, let’s see, here are the advantages that Silverlight has:

  1. It is cross platform compatible. In other words, MS have taken the time to make it available on the Mac — you be the judge if that’s the same thing as saying it’s cross platform compatible.

That’s it. No, really. Now, is that important to you? Is that very important to you? Let’s summarize again.

Pro Silverlight:

  • Runs on the Mac as well as Windows

Contra Silverlight:

  • A PITA to write any code against, due to missing functionality wherever you look
  • No support for certain very important use cases of business apps, only existing solution “do it yourself”. Of course some of the stuff that’s been announced at Mix 09 isn’t really there yet…
  • No support, not even announced, for important use cases of non-business apps. File system access. Compatibility with your favorite database system. F%$#ing hell, last time I heard, you couldn’t control the fricking right mouse button!! (!!!!)

So — do I like Silverlight? You might be surprised, but I do kind of like the idea of Silverlight. But on the other hand I think that Microsoft is making some extremely weird decisions about it, and that the whole excitement about it is 99% marketing. In the past year or so I’ve become very much disillusioned with the Silverlight efforts — Microsoft want to compete with Adobe, and fuck the strategy, and everybody who’s building their business on the basis of MS technology, or the reliability of their statements and commitment to their technological inventions.

Here are some questions for you:

Do you like Silverlight?

Do you agree that the reason you like it is that it promises Mac compatibility? If not, please enlighten me what important reason I’m missing…

If Mac compatibility is so important to you, why haven’t you been using Mono for several years? Or have you? Why aren’t you still using Mono instead of contemplating Silverlight? Or are you?

13 Comments on Do you like Silverlight? Why? Really?

  1. Let’s step out of the box for a moment, though. For a line of business application, now that the new features have crept into SL 3, it’s going to be a little easier to write for those. None of your business logic is going to reside in the presentation layer in the first place, so Silverlight becomes nothing more than a pretty dumb (but very pretty) user interface that just interacts with the user. Are you really going to need Linq to do that? Probably not. You are going to request some basic data to display to the user and then get some input and then shove that back to your web server. The web server is going to be doing all the crunching and spinning and then tell the Silverlight components what to do next.

    I don’t think anyone was thinking about trying to make a complete LOB application in one single Silverlight download. If they were, then maybe they shouldn’t be LOB programmers.

    I have not used a lot of Silverlight yet. We make LOB applications and when I try to figure out what we need to use and how we need to use it, everyone here wanted to try out Silverlight and I told them no, until I saw the new features in SL3. Now it’s time for me to do some research on those new features and find out what we can and can’t do with it so I can figure out if it will work for us.

    Here is what is important to us concerning our applications:
    1. Stellar user interface that is very easy to use and navigate, but also very pretty too look at (since our users have to look at our application all day)
    2. Very easy to install and run.
    3. Works efficiently.

    We currently ship a windows forms application. It looks nice because we use Developers Express controls. We made it run very efficient and well. The only thing lacking now is the easy to install part. This really friggen sucks. And I imagine it will also suck bad with WPF simply because of our constant release cycle that seems to happen every 3 – 4 months.

    So what’s the next step for us that solves that problem? Web based. What’s the problem with web based? THE USER INTERFACE BLOWS!

    So if we can combine a very rich user interface with the ease of install/update of a web application, that’s the solution for us.

    If that is the goal of Microsoft and if they have to ship new revisions every 4 months, GO FOR IT! The state of web applications today just suck. The user interfaces are absolutely abysmal and unfriendly. If Silverlight can help us fix that, then that’s what we will love about it.

    Incidentally, bar code scanners will work in Silverlight 1.0. We have never used anything other than keyboard wedge devices for the simple reason that they will work anywhere.

    Like

  2. Hi Aaron,

    Thanks for the feedback. Unfortunately, I still can’t really see that point of view… let’s see:

    > Are you really going to need Linq to do that?

    I don’t know (for the sake of this argument – in fact I use LINQ (to Objects) everywhere, all the time), and that’s not relevant from my point of view. The point is that we have a platform that has LINQ, and to move away from it I need some *very* strong arguments.

    > The only thing lacking now is the easy to install part. This really friggen sucks.

    Well, that is just not my personal experience. Click Once works perfectly for me and has done so for a considerable time. But even if click-once wasn’t perfect, it could be improved/fixed at a fraction of the cost involved in creating a new platform.

    > So if we can combine a very rich user interface with the ease of install/update of a web application, that’s the solution for us.

    That’s the interesting point in the end, I think. So you’re saying you’re prepared to drop a vast percentage of overall developer productivity for a better installation experience? Amazing. It seems like a rather wild statement to me that Silverlight is the only solution to that problem, even if you don’t like Click Once.

    Like

  3. ClickOnce will never work for us in any way shape or form. Our customers have their own database servers. If we make database changes that we need to apply and then install the new version of the application, it just won’t work with ClickOnce, ever. We do not make internal applications, if we did this wouldn’t be an issue at all. We pretty much sell a canned package that gets sent off and used in house by other organizations.

    Couple that with a few hundred customers and now our support department spends a lot of time on the phone with people helping them with upgrades. We minimized this by making our application do an automatic update once the database changes are applied, but it still doesn’t help with the user experience. They still have to wait while the new application is downloaded and then installed. If it was a web app we would just tell everyone to stop using it for a while, apply the database changes, install the new web app bits, and then be done. People could instantly go back in and get back to work.

    That is why we are willing to drop overall productivity for a better installation experience. What we would lose with developer time, we more than make up for it in our support department.

    Like

  4. Aaron,

    I see the general point, but I still don’t understand the details. You are mentioning database updates. In a Click Once scenario, I would probably have an admin tool which would be used for an upgrade process at the customer site — this can either be separate from the main application or integrated. In any case, I have to have some code somewhere that does the necessary work. In my eyes, this doesn’t change at all when using Silverlight — you still need to have some code somewhere that is executed when an upgrade takes place.

    You’re saying “we would just tell everyone to stop using it for a while, …” — why would you not be able to do the exact same thing in a ClickOnce scenario? Maybe I’m not understanding something, but I don’t see a single difference between these cases you’re describing.

    Just to outline a few cases:

    WinForms or WPF Click Once app:

    1. Coordinate things with your customer, so that the users on the customer side are told to stop using the app for a little while.

    2. Deploy an updated version of the application on your server.

    3. Get the admin at the customer site to run the app. It is updated on his machine automatically. He then executes the DB update code from that updated app.

    4. Let the users run the app again, which results in updates of the client app on all machines.

    Silverlight App:

    1. Coordinate things with your customer, so that the users on the customer side are told to stop using the app for a little while.

    2. Deploy the updated app to your servers

    3. Get the customer side admin person to run the app – there’s no installation process as such, but the user experience is exactly the same as above – one click, new app version running. For the same functionality as above, the app will be a bit larger, because the framework is smaller, so the update takes a bit longer. The admin then executes the DB updates from his updated app.

    4. Ask the users to re-run their apps. The new version of the app is downloaded by all the client systems and runs.

    Finally, Web app:

    1. Coordinate things with your customer, so that the users on the customer side are told to stop using the app for a little while.

    2. Deploy the updated app to your servers

    3. Get the customer side admin person to run the app – this time there’s no installation process at all, but again the user experience is very much the same, if perhaps a little faster than in the two examples above. The admin then executes the DB updates.

    4. Ask the users to re-run their apps. The new version of the app is used by all the client systems.

    Hm… again, maybe there’s something important I’m not seeing here. You’re making the statement that Click Once is not for you, and perhaps there are reasons for it — but the example with updates during the installation process doesn’t seem to explain your point of view.

    I guess in reality all these scenarios above could be simplified a bit more by getting rid of the “manual” user-notification step. Any of these applications could have a notification system integrated that pre-warns the user of an update process which is going to take place and shuts down the app automatically at some point. I don’t think there’s any difference there regarding that functionality — if anything, it’s perhaps a bit harder to do in a web app, because you can’t really force the user to close their browser.

    Like

  5. We don’t have an admin program that does database updates for us. That is in the works though, and maybe when that is done all of this would be a moot point anyway. But there are often times when we make such extreme changes that we need to either migrate some data to a new way of doing things, or we have to run a lot of update scripts to change existing data… I would imagine that a lot of that will eventually go away too just because of the nature of our product.

    Here is the pain point. When we started, we didn’t know what we were doing, code, database, or product wise. We had a great idea, but lacked the knowledge of how to implement it properly or how our customers would even do this stuff. So our product has gone through a lot of iterations while we clean up our code, database schema, and then, our logic in our application because we found out that our customers really do not do things the way we thought they would.

    We charge our customers a yearly fee to get support and product upgrades. If they pay this fee, they get to call us unlimited times and they get updates to the product for free. No matter what we do to it, they get it, as long as they pay the fee. So, with that in mind, we do all of the installs and updates for our customers, even if they have a competent IT department.

    So for us, in all of the above scenarios, number 1 has to happen no matter what.
    Number 2 has to happen no matter what. We have to either run the scripts to update the database or have our tool do it for us (ideally).
    This is where it changes depending on the technology used.
    For web and silverlight applications, the customer just goes back in and everything is done.
    For WinForms and WPF applications, both in clickonce and in our current iteration of our app, they run the program on their computer and wait for it to do it’s install, ClickOnce or not ClickOnce. This process can take a while.

    Installations are different too. Installations are a huge pain point for us right now. With WinForms and WPF, you still have a manual client install process to do on every machine. Even with ClickOnce, you have to go and install all this crap on the machine. Hopefully the IT department or the users have already had to install .Net 3.5 before so that process is not happening, but if it isn’t installed, the IT people or user has to sit and wait for all this to happen.

    In a Web or Silverlight scenario, we install the app and database on their server and then tell the person where to go in their browser and we are done. Even if we use Silverlight and they don’t have it, the install for that is pretty simple and quick.

    The other thing to all this, I know I only said that it would eliminate one of the steps, the big issue is that even though I am trying to do all of this just to eliminate one step, that step is a very large step that takes the majority of the time to complete. We’ve had the scenario on the jump from .Net 2 to .Net 3.5 where the install of the .Net 3.5 Framework took at least 20 minutes per machine. It didn’t impact us because we didn’t use the machines nor did we sit and do those updates for them. But our customers did, and they were not happy with the down time.

    And does ClickOnce work on machines that have no internet access? We do have customers that lock certain machines out of the internet.

    Plus, we could need a ClickOnce deployment for every single customer because we are not going to get every customer out of their application (100s, remember) and then do a new ClickOnce deployment then get everyone back in. We would either need to deploy directly to their server or have a deployment for every customer on our servers.

    If I am not understanding ClickOnce or saying that ClickOnce doesn’t handle this and it really does, please help me. Like I said, when we started, we had no clue what we were doing. So our whole process has evolved as we found the pain points and tried to solve them. When I looked at using ClickOnce to solve some of this, I really didn’t see how it would work for us because of our business model and how our customers run our software.

    Aaron

    Like

  6. > We don’t have an admin program that does database updates for us

    You could replace “program” with “process” in everything I said, it doesn’t make a difference.

    > For web and silverlight applications, the customer just goes back in and everything is done.

    This is not true for Silverlight applications. Why would that be true? Silverlight code is executed client-side, just like Click Once installed code. It needs to be downloaded to the client before it is executed.

    Of course you can use network infrastructure like proxies or caches to speed up this process to the point where it becomes quite irrelevant — but granted, web applications have an advantage in this area. The same is not true for Silverlight though. Whatever marketing people tell you, Silverlight is not a web technology in that sense. It can run inside a browser window, but the same is true for WPF/XBAP. Silverlight is a sandbox, a runtime environment that downloads code from elsewhere and executes it locally. In this regard, there is no difference whatsoever between Silverlight and any other .NET runtime.

    > With WinForms and WPF, you still have a manual client install process to do on every machine.

    Yes, granted. I have never seen this as a big problem personally, but I know that some people have big problems with customers who think that installing latest updates is dangerous, who want all updates to be double-checked in a staging environment before they are being rolled out. Of course this situation is going to be even more difficult with Silverlight — it’s being updated far too often, so the trust level in big organizations never has a chance to build up.

    Obviously that’s not even the type of scenario you’re talking about — you have the case in mind where your customer is simply being too lazy or stupid to auto-install updates on their client machines. Okay, sure, these are out there, too. But of course, as a consultant or similar service provider, I regard it as a responsibility of mine to educate such customers about the danger of what they’re doing. And in the end, as long as it’s an automated process, I don’t care very much if the installation of the necessary components takes a minute or 120 minutes. I’ll probably do it overnight anyway.

    > In a Web or Silverlight scenario, we install the app and database on their server and then tell the person where to go in their browser and we are done. Even if we use Silverlight and they don’t have it, the install for that is pretty simple and quick.

    You say these things again and again — but that’s exactly the same thing you do with a Click Once deployed application, or an XBAP.

    > the install of the .Net 3.5 Framework took at least 20 minutes per machine

    Well, yeah – but you’re not supposed to sit there and watch how it happens πŸ™‚ Why not run it overnight?

    > And does ClickOnce work on machines that have no internet access? We do have customers that lock certain machines out of the internet.

    Click Once deployments can be on any server that machines have access to — an intranet server just as well as an internet one. Of course this gets you into trouble with Silverlight or without. You’d have to have all the infrastructure, SQL Server, whatever, running in the customer intranet in such a case, because otherwise the machines can’t reach that infrastructure. But once more, no difference between Silverlight or not.

    > Plus, we could need a ClickOnce deployment for every single customer because we are not going to get every customer out of their application (100s, remember) and then do a new ClickOnce deployment then get everyone back in. We would either need to deploy directly to their server or have a deployment for every customer on our servers.

    You know, this is becoming a common theme… how is that different from the situation with Silverlight? You need to put your Silverlight application somewhere, right? Somewhere it can be reached by the clients that are supposed to access it. If you need “variations” of the app for different customers, then you’ll have to have several directories or virtual servers or something to host the different versions. With Click Once, you’d have several different packages instead, with all the same pros and cons.

    > When I looked at using ClickOnce to solve some of this, I really didn’t see how it would work for us because of our business model and how our customers run our software.

    With the information I have, I cannot really answer the question of whether or not Click Once can solve the problems you have or not. But the reality is that Click Once works by accessing a location on the web for a package that contains the (compiled) code which makes up your application. That is then downloaded onto the client, dropped into a local directory for caching purposes, and executed within the .NET runtime environment. On the next application start (or when requested through an API), the location where the installation came from is checked again, to see whether there’s a new version, and if so, that version is downloaded and the current version replaced. XBAPs, finally, add onto this the ability to execute the application within the visual confines of a browser window, so that it looks to the end user as if “the application runs in the browser”.

    With Silverlight on the other hand, you have a .NET environment in the form of the Silverlight browser plugin. By navigating to a URL, the plugin is pointed at a package that contains the compiled code of your Silverlight application. This is then downloaded onto the client, dropped into a local directory for caching purposes and executed in the .NET environment provided by the plugin. Everytime the original page is requested again, a new version of the application will be detected and downloaded as needed. While it is the “default” for Silverlight applications to run within the browser window, the new announcements for SL 3 mention that we’ll also be able to run them outside that window somehow.

    I think that’s it. Sounds extremely similar to me, don’t know about you.

    Like

  7. Do you like Silverlight?
    Yes

    Do you agree that the reason you like it is that it promises Mac compatibility?
    Yes

    If Mac compatibility is so important to you, why haven’t you been using Mono for several years? Or have you? Why aren’t you still using Mono instead of contemplating Silverlight? Or are you?

    Because DX components don’t work on Linux/Mac using Mono due to the reliance on Pinvoke. But you knew that πŸ™‚

    If there were a rich suite of third party controls provided by DX that work across all platforms then hell yeah, I’d use Silverlight.

    GG

    Like

  8. Just to clarify the above – I’m talking about DX Winforms components and the possiblity of running Silverlight cross-platform, on the desktop.

    Like

  9. Do I like Silverlight: yes
    Why should it be better then WPF in the Browser?
    – For once you can have more than one Silverlightapp running on the same web-site and you can mix Silverlight with classic web-stuff (you can access the codedom from silverlight – as far as I know you can’t do that with WPF in the Browser)
    – Silverlight 3 is able to run outside the Browser (or so they say)
    – Silverlight forces you to really think about seperation of layers (ok that might be my personal problem – but I tend to put some BL in the presentation layer – Quickfixes anyone?)
    – it’s all shiny new stuff for the web πŸ˜‰

    Ok Silverlight has some problems right at the moment:
    – what I don’t get at all: you can’t bind to other controls – not in Blend and not in XAML, per code is fine 😦
    – you can’t manipulate bitmaps – you *have* to use Canvas+(very)small Rectangles to simulate this or send you data to the server, to the bitmap stuff there and send the result back (silverlight 3 seems to correct this stupid limitation)
    – WCF support is limited to the basic stuff – this seems strange because you can communicate to the server side with tcp/ip streams, so why not give us some tcp-channel? (maybe the RIA stuff changes this – had no time to check the details – and yeah I guess you can implement your own channel for wpf/silverlight … but as you don’t seems to like implementing existing stuff …. πŸ˜‰

    PS: your antispam test is almost to much this early in the day πŸ˜‰

    Like

  10. Hi Oliver,

    I’ve replied on the julian’s blog and I’d appreciate your comments on them.

    TIA
    Shloma

    Like

  11. Amen. I’m surprised that someone shares my exact sentiments on Silverlight.

    I made a quick front-end for an advertisement calendar application in Silverlight. It was a complete PITA and a total waste of time.

    There are way too many unnecessary restrictions, beginning with the fact that all the classes are sealed. The Silverlight team’s excuse for this is that it improves initialization performance in their implementation of the CLR, but that really doesn’t explain why the hell they would seal classes like ScrollBar which there would be only a couple instances of. It’s an excuse to avoid cleaning up their classes.

    WPF has ListView and no DataGrid — which is extremely frustrating. Silverilght has DataGrid and no ListView — which is even more frustrating. It makes no sense at all.

    I have a friend who works at Philips, and it turns out that some arm-bending by his employers is what resulted in the addition of per-pixel access of images. Whether that’s an important feature in a web application, I don’t know. But what’s certain is that Silverlight isn’t being modeled around what LOB developers want but rather around what LOB app developers’ bosses want, which is a very superficial conception of what features should belong in a web API.

    And yeah, I read some article by a moron in the IT press who says that WPF and the rest of rich client is dead because “the only difference between WPF and Silverlight is that WPF has a richer runtime”.

    Yet all in all, Flash and Air are worse than Silverlight. Dismal performance. Enough said.

    Rei

    Like

  12. This post is rediculously out of date, and should be taken down. All of the points made are no longer the case, and my favorite, “competes even more obviously with WPF”… was never the case. Don’t forget, the original internal name of Silverlight was WPF/E… meaning WPF Extended (extended meaning for the web). They changed the name since SL is more of a subset of WPF than an extension.

    Moral of the story, SL can be incredibly complex for someone learning, and for them to across this post would be very misleading and simply incorrect. I’ve been following SL and WPF for quite some time, and I won’t lie, a lot of the points listed here were concerns of mine as well, but that just simply isn’t the case anymore. MS is investing heavily into SL, WPF and HTML5… while the comptetors can’t even keep up (Flex is a prime example).

    Like

  13. Hey Mike,

    Cheers, funny comment πŸ™‚ Taking down a blog post? Why? Agreed, too many blogs out there don’t clearly date their posts, I hate that myself. Which is why my blog posts all show their dates in large letters right there at the top. And hey – this post is only just two years old! A very interesting hint at the lack of maturity in Silverlight, if you ask me…

    Now, regarding your comment about competing with WPF – this is perhaps the funniest. Are you saying it’s not true? Holy cow. It’s never been as true as it is now. And while Silverlight has certainly grown into a more mature platform in the past two years, many of my comments about its targets still hold true today. Only, since it *has* grown into a more mature platform, it has perhaps made its own mission statement more obscure than ever. Who cares about the name or its origin? What does that have to do with anything

    Well… I see Silverlight projects being done here and there these days. I’m always looking out for the one project where it makes sense to me to recommend SL to a client over all other possible alternatives. Haven’t found it yet.

    Oliver

    Like

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s