3 Essential Tips for ASP.NET Developers Moving to WinJS / Metro Application Development

One of the most exciting announcements surrounding Windows 8 development is the fact that you can create Metro-style applications in HTML 5 and JavaScript. This means that you as a web developer can leverage your existing skills and tools and to develop Windows applications.

However, moving from traditional web development to WinJS (a.k.a. Metro-style or Windows 8 applications) development can be a bit of an adjustment if you are an ASP.NET developer by trade. Therefore here are a few tips to help you keep your head on straight as you make your way into WinJS development.

tl;dr

• You can take your existing skills as a web developer and apply them to WinJS, but not everything transfers and you’ll have to fill in some gaps.
• Grasping the inherent difference between stateless and stateful applications and learning the new UI framework is at the core of a successful switch from ASP.NET to WinRT applications.

1: There is No Server

As web developers we are used to stateless client-server architecture of our applications. We are used to the concept of a distinction between server-side code and markup. We’re used to the constraints of session, view state and have adapted to the benefits of Ajax to help increase the effectiveness and responsiveness of our applications. It might seem like I am stating the obvious because WinRT development after all is Windows development by definition, but when you use web technologies (that you've grown accustomed to using for the last decade or so) without the existence of a server - it can be a bit of a paradigm shift without a clutch. Further, web servers are expected to be more or less reliable and available. A Windows 8 application can be suspended, resumed or even terminated with very little ceremony.

Practical Implications

• Classic stateless challenges disappear
• Classic stateful challenges appear (For instance, once you load a CSS file into a page it doesn’t go away just because you navigate to a new page. This could cause problems if you’re not careful.)

2: No Generated Markup

While working with a binding template that wasn’t rendering correctly, I opened the Visual Studio DOM Explorer looking for a value I had applied to an element's class property. The value didn’t get applied because I tried to apply it directly to the class property (which is exactly what you would do if you were working with a server control). Looking back on this face-palm moment I realized that it should have been obvious to me that a JavaScript binding was at play instead of my normal thinking of “generated HTML by the server”. Instead of setting the class property I needed to set the className property as className is the valid JavaScript notation to set the class property of an element.

Practical Implications

• WinJS applications use JavaScript exclusively to manipulate the view – all the same rules apply
• Technically markup is generated in the view, but it’s not generated into the markup stream. New elements are generated in-memory by JavaScript when you are dynamically manipulating the DOM.

3. There is a Learning Curve

Remember how we said you could write Windows 8 applications with HTML and JavaScript? Well that’s all true, but that doesn't mean that the same .NET framework APIs you’re used to are available. For instance: Want to send an email? Go for it, but you won’t be using System.Net.Mail to make it happen. Have an existing business logic layer that you want to expose to a Metro app? Well, you’ll need to create a WinMD wrapper or expose it via an xhr request. If you are directly referencing managed code, you must make sure you only expose Windows Runtime Types as return types and parameters in your methods.

Further, the WinRT framework comes with a host of new controls, animations and design considerations that were never at play in the past. For instance you may be a wizard at jQuery UI, but those same controls may not present as well in a Metro application as they do in a web application.

Practical Implications

• Working with managed code in WinRT is similar to, but not the same as writing the run-of-the-mill .NET application
• There are new design considerations and UI patterns  to learn and apply appropriately

4. It’s a ‘State’ of Mind (Bonus!)

As I’ve alluded to above, a big part of making the switch is fully grasping stateful application development. Let me give you an example. ASP.NET developers are used to a page event lifecycle where a request comes into the page which is usually first handled by Page_Load then control event handlers fire then you have a final chance to interact with the page at Pre_Render and then you’re done. Many of these events are indicative of the statelessness of a web page. In a Metro application you’ll handle the activation event (roughly equivalent to the jQuery ready event) , the suspended event and the restored event (which coincidentally are indicative of the statefulness of a native application).

Practical Implications

The stateful nature of a native application means that you will interact with controls and data in a different way than you would in an ASP.NET application. Issues like guarding against global variable pollution in JavaScript and allowing your application to gracefully handle being suspended, resumed or terminated become an important part of your development concerns.

What Do You Think?

What other aspects of the transition would you include in this list?