25. May 2012 08:44
(This is a cross-post of a recent post I did for Clarity’s blogs).
I suppose it’s a bit hard to tell, since there is still a whole lot of new stuff to figure out. It’s both easier and harder than I expected.
CSS Experience: If you already are proficient with CSS, it will certainly serve you fairly well when writing Metro-style apps. I find CSS styling much more intuitive than trying to style things in a XAML environment, but then again I’ve been doing it for years. The tools now make it very easy to see exactly what styles are being applied at different spots in the DOM.
On the other hand, the new proprietary “ms-grid” system that Microsoft wants you to use is a whole new thing to learn. I’m not sure it improves much. Feels like to me they are trying to take the WPF Gridview concept and apply it to a web layout. I get that the point is to help keep you on a design grid to have a proper Metro appearance, but it’s not that intuitive for someone used to standard CSS.
Html Experience: You’ll have few issues making the leap to using Html to design a Metro-style app, but there are some quirky things. Right about the time we finally have Microsoft tools that support good semantic markup, we are back to a mismash of proprietary tags and Microsoft-only controls littering up the design. While HTML 5 is much more forgiving of this and even partially codifies it (I’m thinking of data binding syntax attributes for instance), it still feels messy. You also need to get familiar with the specific layout and design guidelines for Metro and understand how elements like the AppBar, Settings or buttons in general should look. There are also specific recommendations for typography, margins for certain elements and so on.
Design Experience: I’m not a fan of this at all. In the Visual Studio 11 preview, you really have no visual layout tools at all, not even a preview. While the purist in me who loves to handcraft html from scratch doesn’t mind this too much, it’s not a great developer experience. The intention is you will open the solution in Blend and do your design and style definition work there. I guess if you already know Blend, this will feel natural. There is certainly some nice tooling there for design. But for me it’s definitely an awkward flow to bounce back and forth between the two environments. Not sure I would work that way.
What I ended up doing is making changes and refreshing the app in the simulator to see the result. This isn’t a good developer experience either.
I found it a bit frustrating trying to figure out the WinJS way to do things to be honest. Doesn’t seem as elegant as jQuery. The databinding uses mostly proprietary controls in the WinJS.UI namespace rather than existing HTML elements like Knockout.js. This bugs me because it really isn’t necessary. For instance, unless I’m missing something I can’t bind directly to a select element for a simple dropdown list. I basically had to loop through my data and add option elements to the DOM. This works fine, but REALLY? That’s going to frustrate HTML developers. Good news is you can fly in Knockout.js and use that type of binding instead, at least based on this post. Haven’t tried it yet, but it’s on my list.
Data Experience: There isn’t one. Ok, I’m being overly dramatic, but certainly there’s not much of a local data story. I guess the idea is you’ll get everything from the cloud. That’s all well and good and certainly many applications are already moving that way. But once again it seems like right about the time we get cool small local database options like Sql Server Compact we can’t use them.
I needed a little data for a sample app I’m playing around with, so I ended up using WCF Data Services. This works fine except trying to get one of those services to output JSON is not as easy as it should be. Guess I probably should’ve used the new Web APIs and maybe I will play around with that option. Short answer is you can use this behavior class with the long name (JSONP and URL-controlled format support for ADO.NET Data Services). And that ends up being pretty easy to use, other than the weird JSON format that wraps everything in an extra “d” structure. That’s a WCF data service thing, not sure what the point is. The good news is that if you already have an Entity Framework context, it’s pretty trivial to create a WCF Data Service from it. I didn’t care about doing anything fancy with security and I just needed read-only, so it was very quick to get up and running. I also don’t need anything too fancy from an OData query standpoint, but I could see that changing in a real-world application.