I decided at Build to try and not answer the question I was getting all the time:

So, what do you think this means for Silverlight?

I wanted to take time and not just spurt out my gut reactions. I wanted a thoughtful response to my week at BUILD. I’ve been watching videos, playing with the tablet and trying out the WinRT SDK and think it is time for me to chime in. Let’s take this step by step.

Windows 8

I, like every other BUILD attendee, lined up and got my Windows 8 tablet to experience what Microsoft is going to have for tablets. I’ve spent the better part of several days with the operating system (yeah, it’s preview – that’s code for pre-beta, very early). For a product this early in its development cycle, I am duly impressed. I have nits, but overall the Metro experience is very good if not great. I love showing the device off and showing two apps on the screen at once and the live tiles. The search and share experiences are great too. I can’t wait to see what this looks like once we have more apps…real apps.

The touch experience is very good (but not perfect). I find the navigating apps a little more trouble than I’d like it to be and icon placement isn’t perfect. But those are nits really. The keyboards work mostly, though I’d love to see more use of context specific keyboards (e.g. InputScope people).

The bifurcation of the OS into desktop and Metro feels odd though. I was ecstatic to hear Microsoft clarify that the tablets will be Metro-only (or at least no x86 apps will run on it). I know this is a limitation for some power users, but this will make the tablets great devices for real-people (not us). That’s how we win…getting consumers to buy devices. I am not sure I won’t turn off Metro on my laptops/desktops, or at least keep it on a second monitor.

Some of my favorite parts of Win8 so far are (in no particular order):

• Picture Passwords (though not available for domain-connected machines)
• Contracts (WP7 needs these)
• Selection via Touch is Natural
• Sharing Two Apps on Screen at Once
• Windows Live Integration (including syncing of settings)
• Allow Adding Custom Apps to Lock Screen

Overall, the end-user story for Windows 8 is really good. Lots of great improvements, first class touch and it’s fast. My only hesitation is that until we see Win8/Metro on ARM tablets, I won’t be completely convinced that Microsoft has a real competitor for iPad.  It has to be fast and have great apps (I know, that’s our job).

WinRT and the New Development Environment

There was some confusion about what WinRT exactly was after the keynotes. Some said it was simply the new Win32; some said it was the new .NET. It’s actually a little old and a little new. You can see how it fits into the ecosystem from a slide I saw at build:

This slide implies a lot of things. First, for desktop applications, nothing really changes (yeah, that’s a big deal…later in this post I’ll say more about that). The true value in what Microsoft is doing is creating a new, object-oriented version of Win32 called the Windows Runtime (or WinRT for short). In WinRT, DirectX is used to draw the entire user interface and handle all the input so the APIs aren’t mapped back to Win32. This is awesome in that the performance of applications is greatly helped by this. No more GDI to hold us back.

The other (perhaps more important) part of what this slide implies is that everyone is on an equal footing for WinRT. Managed code, C++ and JavaScript can all use the WinRT to equal effectiveness. All developers are on an equal footing. Should you be learning JavaScript or C++ to use WinRT? Nope. You bring your own skills to the table and can equally be successful. Like CSS and the DOM but haven’t touched XAML? That’s fine. This allows developers to focusing on creating great apps and not worry about language or design tooling as much. This is a great idea.

Metro or Desktop Apps?

Along with Windows 8 comes these Metro Style Apps that you can build. If you’ve seen the Metro UI for Windows 8, you know that it is similar to a mobile platform in that you have the ability to create rich, touch based interfaces. Metro apps have the notion of multiple views (rotation, docked, full screen, etc.) as well as live tiles and contracts to create an ecosystem of apps that work together.

But what if you’re an enterprise application developer that creates complex, data entry applications – should you be creating Metro apps? Yes and no. Sinofsky made a point of showing PhotoShop as a good example of a desktop application that shouldn’t be a Metro application. Microsoft calls these Metro Apps and Desktop Apps. Desktop Apps are what we’ve always created.

So in my mind Metro doesn’t change much of this. When you need a big, data-driven enterprise application, existing tooling (Silverlight, .NET, etc.) work great. This story hasn’t changed. But you may also be building Metro Apps. You could imagine that many types of applications like dashboards or communication tools work better as Metro Apps.

In my mind, Metro apps are for a different experience. In fact, they are for a different experience many of us have already experienced: mobile apps. Yes, Metro Apps are for a great Tablet/Phone-like experience that we’ve already grown to love. For me, Metro is all about the tablet experience – and the tablet experience is a follow-on to the phone experience. As we’ve seen in the Apple space, a good phone app doesn’t make a good iPad app. This is true for Metro as well. Porting a simple Windows Phone or iPhone app to Metro isn’t going to be a great app unless you take advantage of the extra real-estate and the fact that many users can use two hands. It’s important to build apps for Metro but they’ll likely be adjunct to your existing applications.

As we move forward I think most shops will stop seeing the Application they build – but instead a corral of applications that you build. This is another place in that ecosystem. You will still build desktop applications, but will likely need web sites, phone apps and tablet apps to compliment them.

So What about Silverlight?

In the silence before BUILD, many people were ready to kill off Silverlight and maybe even .NET development as well. Oddly, the people that talked about the death of Silverlight the most were it’s most vocal proponents. The reality is that Win8 doesn’t change much for desktop applications. Silverlight, WPF, WinForms, VB, etc.  are all fine. For the typical enterprise application that is being writing in a XAML-based UI, just keep doing what you’re doing. Sure, Microsoft hasn’t said anything about Silverlight 6, but Silverlight 5 isn’t out yet so that’s no surprise. So no more panicking, ok?

For me the most interesting point is that if you’re building (or are about to build) a XAML-based desktop application (e.g. Silverlight or WPF), these skills are immediately applicable to the future. XAML and its data binding stack are the real magic of Silverlight to me and that’s not going away. WinRT is just another runtime. In fact, you’re probably already doing this. If you do Silverlight (Desktop or Windows Phone), you are already running on a different BCL (Base Class Library of .NET):

For managed languages, WinRT is just another stack. The XAML stack (like in Silverlight) is in an unmanaged layer below .NET and it’s another incarnation of the BCL, but with the same CLR. That means that your XAML and .NET skills apply. Sure, you’ll have to learn the differences between WPF’s, Silverlight and WinRT’s XAML stack but the basics are all the same. This is the opposite of what the naysayers were worried about. Wahoo.

Ok, a caveat. On Windows 8, there are two browsers: Desktop and Metro. They are both based on the same IE10 and JavaScript engines but run in different security contexts. On the Desktop (only available on Intel machines like laptops and desktops), the browser is IE10 and works the same way you’d expect. Flash and Silverlight haven’t changed. But in Metro (and on ARM devices), Silverlight and Flash aren’t going to be there. There are no plugins in the security model on Metro’s version of IE10. None. Period. This likely means you’ll need to write a Metro version of your app for the mobile story. But this is just like Windows Phone. It’s just another platform. If you need a Silverlight app, you’ll not only want to create one for Metro but it’s likely designed for a different interaction: touch all the time. Many of the lessons from Windows Phone can be drawn here. Touch centric, on-screen keyboards, save data often, no traditional close buttons, etc. It’s a different and better model for mobile.

“Should I Use Silverlight or Today?”

While I am not a completely unbiased observer, I don’t think much has changed for Silverlight. If you’re building Silverlight desktop/browser-based applications today, you should just continue on. If you’re thinking of building a desktop application that has to work on PC’s and Mac’s, Silverlight is still a compelling story. Nothing we heard solves the iPad/iPhone compatibility and I don’t expect this to change. We’re moving towards fewer plugins on other platforms. But any investments you make today in Silverlight can be brought forward to Metro’s XAML support in the future.

But what if you need cross-device compatibility (e.g. Win8, Android, iOS)? There isn’t a perfect story here. Frameworks like jQuery mobile or PhoneGap are attempting to address these, but I don’t think we’re quite there. But I don’t think they need to be. I still think building Obj-C apps for iOS, building HTML5 apps for the web, building Java apps for Android and building XAML-based apps for SL/WPF/Metro is where most organizations should be at. But that’s only for cases where you are going for full reach of users (e.g. consumer). In those cases, making your application work as fully like the underlying operating system is crucial. For enterprise applications, going web-based for a central experience on all devices might be fine. It’s a fine line to walk.

While I am not talking about it yet, I am in the same conundrum. I am building a product that has to reach onto every kind of device including a desktop application. I could have chosen to build one, but instead we’re building them all. As you might have heard me say before, I think the future platform is all of them. Trying to build one app to cover everyone is a losing cause. Build different UI’s and use the same back-end for all of them is how I am approaching it.

What about the Silverlight Tour?

As many of you know, I’ve spent the better part of the last five years teaching my Silverlight Tour workshop in the U.S. (as well as my partners who teach in the rest of North America, Latin America, Australia and Europe). In the short-term nothing changes. The course will be focused on building line-of-business applications using Silverlight. As Win8 approaches, I’ll be making more announcements about whether we’ll be adapting it for Metro/XAML courses as well as a Metro/JS course or two. We’re still determining the right thing to do.

UPDATE: Forgot to mention my great Latin American partner.

UPDATE: Added Link to Microsoft’s confirmation of no x86.