Blogroll

It is clear. There is open warfare at Microsoft between the Silverlight/WPF camp and the HTML camp.

HTML used to be slow and a memory hog, but the IE team have sharpened their pencils and it is looking hot and competitive. This is thanks to the competition coming from other web browsers, who are increasingly seeking to displace IE from the enterprise desktop.

Did you remember the painful Longhorn reboot? The one where WPF was not good enough for your own operating system? Well, HTML is good enough Windows 8, and that says something about how competitive the IE team has got.

What does this mean for Silverlight developers? It means that we increasing are going to be forced to choose between Silverlight and ASP.net. Business decisions are going to be made around whether which of these technologies are going to be the most productive.

The answers used to be clear years ago, but they no longer are. HTML is increasingly standardized and a lot of the pain points in the past have been addressed. Meanwhile, Silverlight, in concentrating on the niche HTML is poor at (video) is looking increasingly weaker in the presence of the hoards of web developers who are making enterprise development a cinch. The days users are willing to spend 15 seconds waiting for their application to load and start up are gone. Web applications provide an instant start experience. Don’t fool yourself into thinking that the richness will save Silverlight. It will only postpone the date before the pig is sent away for its bacon.

I suggest the Silverlight PMs spend sometime with the ASP.net MVC PMs and look at the speed which applications can be punched out. ASP.net is a stunning platform.

When I reimagined what a productive Silverlight workflow might look like, I believe it looks like this:

1. Switching WCF to a basic profile with JSON rather than complicated plumbing. Alternatively, tighter integration with ASP.net MVC than with WCF.

5. Projectless Assembly Cache. In the development environment, we should abandon building out a large XAP file for download. Rather we should be incrementally downloading DLLs like clickonce. This brings the workflow closer to developing HTML pages. Compilation is done incrementally one page at a time. ASP.net would be laughed off the planet if they said that each .ASPX page must be held in a single .CSPROJ. But if you look closely at MEF, it is exactly what SL is supposed to do.

6. Release a Silverlight visual tree inspector, so that devs can quickly work out what is wrong with their layouts.

7. Fix the build, debug cycle time. I know there are seconds that you can shave off there. See how HTML devs have F5 to refresh their screen?

As I said earlier, it is now open competition between HTML and Silverlight within MS. Do your best. We are on your side and counting on you to make Silverlight competitive, not against Java, but against HTML+js developers working on IE. The opposing team is not to be underestimated. After all, they too are Microsofties.