To put it simply, it’s a matter of understanding “layers” of development choices. So by choosing a particular technology as a “layer”, your next technology “layer” choice is enriched by the previous, and so on. This means that when you compare a particular technology with a rival, in this case Silverlight Vs Flash, you find that the choice is made a lot easier for you, simply because of the “layers” it is built upon. I hope that made sense…..
I’m not going to be too technical in this blog, as I still want non technical people to read and engage in this topic. It’s one that I feel many “non technical” people will find cropping up more and more, especially as Flash has been unchallenged in the world of rich web experiences. Well until now…
Let’s start with the web…
Well, I have to be honest, in the world of web development I got involved a little later than some. My first experience of programming in a web environment was developing custom step processors for FileNETs’ eProcessor workflow engine. (Now part of the P8 suite and owned by IBM). At the time there were two choices, HTML or Java Applets. After looking into the requirements, and how to actually build the web interface, I quickly opted for the Java Applet route. Why? Simple, it made more sense. It provided a logical programming environment that didn’t seem messy. Using HTML with server and client side scripts, just seemed too messy, time consuming and far too prone to frustrating errors and bugs. Not for me….
While developing Java Applets, and some standard websites, my main development activities revolved around thick client business applications, almost all of which utilised COM based APIs (which all the business based applications I saw did at that time). And to be honest, I hated switching between the two very different ways of developing. When ASP.NET arrived, I was asked to start to develop thick client applications in .NET. However, I could now use the same platform to deliver web based applications and web sites. You guessed it, I soon moved away from the Java Applet form of thinking for my step processors, and standard ASP for our websites. To be honest, I thought it was Christmas.
With this in mind, there really was only one choice for me, a developer who developed traditional client based businesses applications but also web based applications / experiences.
The fundamental platform for us at One Degree, .NET
Once I formed my own development company (with a friend), we quickly chose our development platform of choice as .NET. For us both, it offered the greatest flexibility, allowing us to consume .NET components, COM APIs and XML Web Services (which were very new at that time). .NET really chose itself.
In addition, the development environment is almost as important as the technology you choose to develop in. Visual Studio is second to none. It provides an easy to use developer experience while providing all the tools you need to deliver enterprise wide solutions. You see why we choose .NET???
XML Web Services
Now why doesn’t all APIs out there utilise these? They provide so much interoperability and benefits to programmers that for me, it’s a no brainer. When I look at the web today, many APIs still don’t utilise these types of services the way they should. I find this a great shame.
Myself, and the technical Director at One Degree and OD Media, always ensure anything we deliver contains a full API layer. Sometimes we may only need to deliver and utilise XML Web Services, this is a mark to how easy they are to work with. By providing a separate location for our API layer, web services can not only serve our own applications, but also be opened up to third party applications / sites. We also use XML Web Services for traditional thick client development. Our workFile ECM platform can be delivered as a thick client or as a website; both use the same XML Web Services API.
So why WCF Web Services?
Well first off, we are still in .NET and still using Visual Studio. This means all the benefits of developing with .NET 3.5 apply here, with our web services. WCF Services (.svc) are more flexible than the standard ASP.NET web service (.asmx), and as such more desirable. In addition, WCF now supports RESTful implementations, which again provide other benefits of choosing WCF.
There is also the benefit to us, the fact that Visual Studio provides powerful templates to help get our WCF development started. Templates include RESTful WCF development, and development of services used by Silverlight applications. These templates drastically reduce the amount of time, and coding that a developer may have to do outside of Visual Studio.
Why Silverlight and not Flash?
Ok well I hope you have followed me to this point. So why Silverlight? Well Silverlight provides us developers with that next layer. It means we can still work in .NET managed code, we still have access to XML Web Services, we can still quickly and easily access other APIs, data centres etc and we can still work in Visual Studio. We have all the benefits of why we choose our .NET platform, but with Silverlight, we have the added dimension of delivering richer user experiences.
There are many comparisons out there now between Silverlight and Flash, however most of these it seems, concentrate on the simple “look” differences. This really isn’t a comparison; you have to look at the whole picture. If you are thinking of delivering rich web experiences, and you have no particular language preference, or no particular requirements to integrate with different applications etc, then the Silverlight Vs Flash decision is harder. However, Silverlight isn’t just Microsoft’s answer to Flash, it’s an extension of the .NET platform, and as such, Silverlight brings to the table a wealth of benefits that other web technologies, including Flash, cannot match.
Silverlight has a number of benefits when working on the web over its competitors (video streaming without streaming servers for one), and its competitors have some benefits over Silverlight (remember that Silverlight 2.0 isn’t even a year old yet). However, once you start to look under the covers, looking at the layers on which Silverlight sits upon, you see exactly why we, as a software and web development company, choose and recommend .NET, WCF services and Silverlight.