My background is in client application development. I started on the Commodore 64 in seventh grade in the 1980s, later moved to DOS with dBase, QuickBasic, and C++, and eventually Windows programming using C++, Borland Delphi 1.0, PowerBuilder, Visual Basic 3-6, and .NET.

Though I've written plenty of pure HTML/JavaScript web applications, I've always preferred client programming over strict web programming because I felt HTML/JavaScript programming treated the immensely powerful PC as a dumb terminal, squandering its CPU cycles for applications that were almost entirely network bound in performance. Only recently is this changing.

Back when web applications started to become more popular, customers loved the flexibility of the blank canvas of HTML versus the old battleship gray look, as well as the ease of deployment of web applications. On the client development side, we had some things that came close (WPF for appearance, for one) but nothing that combined the ease of deployment with the modern look.

For a while, it looked like the world was going to move to relatively dumb web applications, treating the local PC as just a keyboard and display—a disappointing move to say the least.

Back in 2006, long before I took my job as a Silverlight and WPF Community PM with Microsoft, I attend the first Microsoft MIX conference in Las Vegas. On March 21, day two of the conference, I attended some sessions about WPF/E, the product that would later be named Silverlight. Even then, Microsoft had a strong vision for Silverlight, a vision that included desktops, mobile devices, and set-top boxes. It was planned to be a lightweight version of WPF optimized for cross-platform scenarios, which would both take advantage of client-side processing power (when the .NET CLR was incorporated) as well as provide the ease of deployment of a traditional web application. This was exactly what I was looking for!

I was pretty jazzed about WPF/E at the time. I was also a little concerned about making the case for adoption. I took a wait-and-see approach. When Silverlight 1.0 CTPs and betas hit the street, I was less than impressed, because they were JavaScript only. I wasn't a big fan of JavaScript at the time and felt WPF/E wouldn't make any meaningful impact until they delivered on the promise of the CLR inside the browser. Nevertheless, early in 2007 I took on a project to create a carbon offset calculator in WPF/E, to be hosted in SharePoint on a public internet site.

Then, we had MIX07 and the name Silverlight was given to WPF/E. Along with it, Microsoft introduced Silverlight 1.1 alpha—a version that worked with managed code and included a cross-platform version of the .NET CLR. Yay! No JavaScript! (Hey, this was before jQuery proved to me that JavaScript can also be awesome.) Right at that point, I lobbied the project sponsors to let us work in Silverlight 1.1a. I also spoke with some contacts at Microsoft and received permission to go live with the Silverlight 1.1a application, happily foisting alpha code on unsuspecting users.

Despite, or perhaps because of, having to code many primitives from scratch (we needed buttons and drop-down lists, none of which existed in Silverlight 1.1a), I was completely hooked. It felt like the old days of DOS programming when you had to spelunk without much support and make up your own tricks for how to best accomplish things. It was the Wild West of programming. (And, by that, I mean the Wild West with giant Steampunk spiders added into the mix.)

I still had (and have) a place in my heart for Silverlight's big brother WPF, but it was easy to see that Silverlight was going to take the world by storm. WPF is still an incredibly powerful technology, but it tends to appeal more to niche users and ISVs as opposed to the broad group building web-based applications for a living.

The two of us on the carbon calculator development team released the first Silverlight managed code application ever to go live. It included video, Windows Live Maps integration, web services integration with SharePoint, carbon offset calculations of course, and a completely data-driven, configurable UI with SharePoint as the backend, supporting everything.

At the time, there was no real ecosystem around Silverlight, and the idea of using real designers on client applications in the Microsoft stack hadn't yet caught on. Despite the primitive UI we designed, I'm still impressed with what we put together. I was thrilled to be able to use .NET skills in something that was truly unique in the .NET space.

Later that year, Silverlight 1.1a would be updated to a stronger subset of WPF and rebranded as Silverlight 2, laying the groundwork required for Silverlight 4, a release that continues to impress and engage me every day I use it.

Pete Brown