If you’re coming to JavaScript from a background in procedural languages like C#, Java, or PHP, it’s natural to reach for the same tools, like switch, that you’re accustomed to using in those languages. However, JavaScript’s flexible object literal syntax and first-class functions offer alternatives to switch that I believe are cleaner, more extensible, and more maintainable.

So, in this post I want to show you a few ways that you can refactor a JavaScript switch statement to use this alternate technique, and improve its extensibility and maintainability in the process.

Starting with a switch

To start with a concrete example, let’s say we need find the pricing for line items on an invoice and that those line items might be discounted based on the type of customer that’s being invoiced.

To do that, you might iterate over each line item and multiply the price times quantity and apply the correct discount depending on customer type. The latter bit being something like the following:

function getItemPricing(customer, item) {
  switch(customer.type) {
    // VIPs are awesome. Give them 50% off.
    case 'VIP':
      return item.price * item.quantity * 0.50;
 
    // Preferred customers are no VIPs, but they still get 25% off.
    case 'Preferred':
      return item.price * item.quantity * 0.75;
 
    // No discount for other customers.
    case 'Regular':
    case default:
      return item.price * item.quantity;
  }
}

That’s simple enough, but you’ve probably seen code that started like this and then spiraled out of control over time as more and more complexity was needed. I know I have (and been responsible for that myself a few times too).

Turn off the switch

JavaScript’s flexible object literal syntax makes it easy to replace the switch with something that looks similar, but can be decomposed later. To get started on that, we can define our pricing rules in an object literal like this one:

// This should be namespaced somehow in the real world,
//  not hanging off the global object.
pricing = {
  // VIPs are awesome. Give them 50% off.
  'VIP': 0.50,
 
  // Preferred customers are no VIPs, but they still get 25% off.
  'Preferred': 0.75,
 
  // No discount for other customers.
  'Regular': 1.0
}

Putting that into action is straightforward enough. We can check that pricing object for a key matching our customer’s type and then apply that custom pricing if it is available:

function getItemPricing(customer, item) {
  if (pricing[customer.type])
    return item.price * item.quantity * pricing[customer.type];
  else
    return item.price * item.quantity * pricing.Regular;
}

Now, instead of explicitly stepping through a case statement, we’ve separated the pricing rules from the actual pricing mechanism.

Embrace the functional side

Using the object literal is fine for the simple example of multiplying a few numbers together. What if our pricing rules needed to be more powerful than simple multiplication though? To complicate the example a bit, let’s say that the discount for “Preferred” customers should only apply to items costing up to $100.

One of the beautiful things about a functional language like JavaScript is that you can define and pass functions around just as easily as a basic type like a string or boolean.

We could approach our new object literal “switch” a little bit differently to take advantage of that:

function getItemPricing(customer, item) {
  var pricing = {
    'VIP': function(item) {
      return item.price * item.quantity * 0.50;
    },
    'Preferred': function(item) {
      if (item.price <= 100.0)
        return item.price * item.quantity * 0.75;
 
      // Else
      return item.price * item.quantity;
    },
    'Regular': function(item) {
      return item.price * item.quantity;
    }
  };
 
  if (pricing[customer.type])
    return pricing[customer.type](item);
  else
    return pricing.Regular(item);
}

That’s a bit more verbose than the original switch, but it’s worth the extra LoC in the long run. Now we’ve got all the power of arbitrary code in a switch, but none of the syntactical restrictions keeping us from breaking it into separate pieces.

The functional approach is a departure from the procedural languages you might be used to, and from JavaScript code rooted in those same old practices. It can take a while for the utility and flexibility of first-class functions to really sink in, but it’s well worth internalizing this approach in your day-to-day JavaScript.

Modularity === Maintainability

Now that we’ve refactored our pricing logic to be decoupled and functional, the getItemPricing method doesn’t really need to know anything about how the pricing works. The method only needs to understand how to choose which function, if one exists, to apply for a given line item.

In fact, they don’t even need to be in the same file anymore:

// Pricing.VIP.js
pricing = pricing || { };
 
pricing.VIP = function(item) {
  return item.price * item.quantity * 0.50;
}

// Pricing.Preferred.js
pricing = pricing || { };
 
pricing.Preferred = function(item) {
  if (item.price <= 100)
    return item.price * item.quantity * 0.75;
 
  // Else
  return item.price * item.quantity;
}

// Pricing.Regular.js
pricing = pricing || { };
 
pricing.Regular = function(item) {
  return item.price * item.quantity;
}

// Pricing.js
function getItemPricing(customer, item) {
  if (pricing[customer.type])
    return pricing[customer.type](item);
  else
    return pricing.Regular(item);
}

Now, adding a new pricing type to our program is as easy as dropping new file in a directory and referencing it in your program (e.g. a script reference for website code). As long as it augments the Pricing object with a key/function pair that matches the new customer type, everything “just works”.

If you use something like ASP.NET’s Web Optimization framework or Rails’ Asset Pipeline, you can configure server-side bundling to automate that work. Then, simply dropping a new pricing logic file into the right directory will affect pricing without any extra configuration or script reference.

Conclusion

To me, one of the nicest things about this approach is the flexibility and modularity. You can drop a discrete bit of logic in a file in the right directory and change the behavior of your program without touching the program’s core logic.

In this example, adding, modifying, or removing a custom pricing type doesn’t require touching pricing.js. That means we avoid even the potential for a range of regression errors that centralized logic constructs, like switch statements, are prone to.

Ultimately, my experience has been that this technique finds an ideal middle ground between inflexible switch/if-then cruft and over-complicated “rules engines”. I hope you find it as useful as I have.

My question to you is: Did you find this useful? Are you going to replace your switch statements with the functional approach going forward? Were you already doing this?

You've been reading My favorite alternative to JavaScript’s switch statement, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

However, ASP.NET Web API throws an unintuitive curveball at you when you want to accept simple primitive types as parameters to POST methods. Figuring this issue out is particularly confusing because it’s one of the rare parts of Web API that violates the principle of least astonishment.

Because of that, using jQuery to interact with those methods requires a slight contortion that seems strange at first, but makes sense once you understand why it’s necessary. In this post, I’ll briefly describe the underlying issue and show you how jQuery can be convinced to work around the issue.

POSTing primitive parameters to Web API

There are three things you need to know about Web API if you want to go the route of POSTing a primitive type (e.g. string, int, or bool) to a method. For example, say you’re working with this straightforward POST method in a Web API controller named ValuesController:

// POST api/values
public string Post(string value) {
  return value;
}

You might try POSTing a value into that Web API method using a standard jQuery $.post, like this:

$.post('/api/values', { value: 'Dave' });

If you inspect the server’s response to that request, you’ll be greeted with a bewildering 404 error:

Confronted with that response, it’s only natural to treat the problem as an issue with your routing configuration and debug from there, but that’s not the issue.

1. Parameters must be marked as [FromBody]

As it turns out, the reason for that 404 error isn’t a routing problem. ASP.NET correctly identifies our ValuesController as the controller to handle a POST to /api/values, but it can’t locate an acceptable method to process the request.

The reason for that is a twofold mismatch between the required parameter that Web API expects to accompany requests to our Post method and what we sent. The first of those mismatches is that the method’s parameter must be decorated with the [FromBody] attribute.

[FromBody] directs Web API to search for the parameter’s value in the body of a POST request. Adding that directive to our method is easy enough:

// POST api/values
public string Post([FromBody]string value) {
  return value;
}

I can’t say that I understand why this extra hassle is necessary, especially since it wasn’t required in WCF Web API and preliminary versions of ASP.NET Web API, but it’s easy enough as long as you’re aware that it needs to be present.

Adding [FromBody] fixes our 404 error, but things unfortunately still aren’t working quite right. Making the same request to it again works, but the value parameter is coming back as null now instead of the provided value:

2. Only one parameter per method

Speaking of the parameters to our method, another potentially confusing thing about accepting [FromBody] parameters is that there can be only one.

Attempting to accept multiple parameters from the POST body will result in a (refreshingly decipherable) server-side error along these lines:

Can’t bind multiple parameters (‘foo’ and ‘bar’) to the request’s content.

It’s possible to circumvent this limitation by using manual parsing techniques, but that seems antithetical to Web API and model binding to me. If you want Web API to automatically convert POST data to your [FromBody] input parameter, you have to limit yourself to only a single parameter.

I believe the thinking here is that, especially in a RESTful API, you’ll want to bind data to the single resource that a particular method deals with. So, pushing data into several loose parameters isn’t the sort of usage that Web API caters to.

This limitation can be a bit confusing when you’re coming from WebForms or MVC though, and trying work around it feels like going against the grain of the framework. So, if I need to accept more than one POST parameter, I just define a quick view model.

In other words, don’t try to do this:

public string Post([FromBody]string FirstName,
                   [FromBody]string LastName) {
  return FirstName + " " + LastName;
}

Instead, work with the framework and do something like this if you need to accept more than a single parameter:

// DTO or ViewModel? Potato or potato, IMO.
public class PersonDTO {
  public string FirstName { get; set; }
  public string LastName { get; set; }
}
 
public string Post(PersonDTO Person) {
  return Person.FirstName + " " + Person.LastName;
}

3. [FromBody] parameters must be encoded as =value

The final hurdle remaining is that Web API requires you to pass [FromBody] parameters in a particular format. That’s the reason why our value parameter was null in the previous example even after we decorated the method’s parameter with [FromBody].

Instead of the fairly standard key=value encoding that most client- and server-side frameworks expect, Web API’s model binder expects to find the [FromBody] values in the POST body without a key name at all. In other words, instead of key=value, it’s looking for =value.

This part is, by far, the most confusing part of sending primitive types into a Web API POST method. Not too bad once you understand it, but terribly unintuitive and not discoverable.

What not to do

Now that we’ve covered what you need to know about the server-side code, let’s talk about using jQuery to POST data to [FromBody] parameters. Again, here’s the Web API method that we’re trying to POST data into:

// POST api/values
public string Post([FromBody]string value) {
  return value;
}

You’ll have a hard time finding a  jQuery $.post (or $.ajax) example that conforms to the =value encoding approach. Typically, platform-agnostic jQuery documentation and tutorials suggest that one of these two approaches should work:

// Value will be null.
$.post('api/values', value);
 
// Value will be null.
$.post('api/values', { key: value });

Unfortunately, neither of those work with Web API in the case of [FromBody] parameters (the latter would work to send an object, rather than a single primitive value). In both cases, our method will be invoked, but the model binder won’t assign anything to value and it will be null.

Making it work

There are two ways to make jQuery satisfy Web API’s encoding requirement. First, you can hard code the = in front of your value, like this:

$.post('api/values', "=" + value);

Personally, I’m not a fan of that approach. Aside from just plain looking kludgy, playing fast and loose with JavaScript’s type coercsion is a good way to find yourself debugging a “wat” situation.

Instead, you can take advantage of how jQuery encodes object parameters to $.ajax, by using this syntax:

$.post('api/values', { '': value });

If the data parameter has properties with empty string keys, jQuery serializes those properties in the form of =value. And, that’s exactly what we need to make Web API happy:

You've been reading Using jQuery to POST [FromBody] parameters to Web API, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

It’s not that I don’t want to hear what everyone has to say, but automatically following thousands of people back would make my timeline impossible to keep up with (and even more productivity-cripplingly distracting than it already is).

One thing about these loose, asymmetric relationships constantly frustrates me though. The requirement that I must follow you in order for you to direct message me, even after I’ve direct messaged you, is too restrictive. Pointlessly restrictive.

It often makes sense to take a Twitter discussion private, but we can only use Twitter to do that if we have a symmetric relationship with each other. Sure, I can follow you temporarily or message you my email address for follow up, but why? It should be easy for Twitter to allow anyone to reply to any direct message for some period of time, or even forever.

Wouldn’t that make the direct message feature a lot more useful?

You've been reading I wish Twitter’s direct messages were less restrictive, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

Of course, this sort of thing is nothing new. Similar Google searches have been possible for years. However, GitHub currently seems to house a concentration of particularly sensitive secrets. Maybe that’s because it’s so easy to accidentally commit these things along with associated code with a quick git commit -a.

I’ve been working on a few Node.js projects hosted on Windows Azure lately, and one in particular is stored in a public GitHub repository but needs access to private oAuth keys. So, this topic is something I’ve been dealing with myself lately. Through that project, I’ve been fortunate enough to stumble onto a nice symbiosis between Azure and a Node.js module called nConf that solves the problem of storing secrets in my public repositories.

Adding nConf to your Node.js app

nConf is a simple, but handy, module by Charlie Robbins. As with any other npm module, adding nConf to your app is easy. A quick npm install nconf from your project’s root directory will do it:

You’ll see npm downloading nConf and its dependencies, and then you’ll be ready to start using the module in your code right away.

I can’t say enough good things about how well the folks at Joyent and Microsoft have made this work on Windows. I have a MacBook and I host this site on an Ubuntu VPS, but I still do the overwhelming majority of my serious development work on a Windows 8 desktop. In the early days, working with Node.js on my Windows desktop was tedious and painful, but things have changed significantly for the better during 2012. Kudos to everyone involved in making that happen.

Using nConf to read settings from a config file

With nConf installed, exposing configurable settings for your app is simple. For example, let’s say we want our app to have a configurable username and password. You might create a file called settings.json like this:

{
  "username": "dave@encosia.com",
  "password": "password123"
}

Then, you could pull those settings into your application with code like this:

var nconf = require('nconf');
 
nconf.file('settings.json');
 
var username = nconf.get('username'),
    password = nconf.get('password');
 
// Output: dave@encosia, your password is password123
console.log(username, ', your password is:', password);

That’s a handy way to read in settings from a config file, but this approach alone brings us right back the point where settings.json might accidentally get committed to a public repository.

Reading environment variables instead of a config file

Along with pulling settings out of a JSON file, nConf also supports reading arguments from environment variables. That’s particularly useful if your app is hosted on a PaaS like Azure that allows you to configure those environment variables through an interface that’s independent of your code.

For example, providing a username and password setting in this section of Azure’s “Configure” tab makes those settings available to Node as environment variables:

That’s great because nConf can read configuration from environment variables just as easily as a JSON file. All you need to do is a call nconf.env() instead of nconf.file():

var nconf = require('nconf');
 
nconf.env();
 
var username = nconf.get('username'),
    password = nconf.get('password');
 
// Output: dave@encosia, your password is hunter2
console.log(username, ', your password is:', password);

By itself, that’s not particularly impressive. You could also read those environment variables via process.env.username and process.env.password, without any extra modules.

However, the beauty of nConf is that you can combine both approaches.

The best of both worlds

Using environment variables works pretty well once the code is deployed to Azure, but I think the simple config file is a lot more convenient when I’m developing locally. The best thing about nConf is that it supports reading settings from both locations, in the priority that you specify.

So, you can use a settings file locally, but supersede that with environment variables if they’re present (i.e. once deployed to Azure). To do that, you can chain nConf initialization calls to both .file() and .env():

var nconf = require('nconf');
 
nconf.file('settings.json')
     .env();
 
var username = nconf.get('username'),
    password = nconf.get('password');
 
console.log(username, ', your password is:', password);

Now, running this locally with the settings.json file from earlier will output “password123″, but deploying it to the Azure site with the app settings shown above will change the output to… a 500 error, of course.

This simple example code doesn’t handle HTTP requests, nor does it output HTTP responses, so running it on Azure doesn’t work. But, the password variable will be correctly initialized to “hunter2″ instead of “password123″ when running on Azure with the environment variables we set in the previous section.

Now, add settings.json to your .gitignore and you’ll never need to worry about pushing your local, potentially-sensitive, credentials to a public repository.

You've been reading Using nConf and Azure to avoid leaking secrets on GitHub, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

Site stats

When I loaded up Google Analytics to check my stats for the past year, I was half expecting the numbers to be lower than last year’s. I haven’t posted very much this year and haven’t bothered to link-bait my way onto the front page of Hacker News or reddit either.

As it turns out, the site did manage to eek out a small increase in traffic over last year anyway. There’s always inflation, I suppose:

Since last year’s post, that’s about an 8% increase in page views, which isn’t terrible. It’s a good thing I managed to finish that Surface RT review, which accounted for the second spike on the chart.

It may seem weird to spend time worrying about things like page views and bounce rates on a non-commercial site like this one. These metrics are one of the few things I can measure consistently across the years though. It’s important (for me, at least) to have metrics that I can use to set goals against and then get relevant feedback to motivate myself.

So, I measure and watch these things, for better or worse.

2012: Better than the Mayans predicted

Aside from my poor posting frequency, 2012 turned out to be a good year. I started the year off by becoming a Microsoft Regional Director (though it’s neither regional, nor do I direct anyone) in January and then receiving an MVP of the Year award in February. Not a terrible way to get the year rolling.

Throughout the rest of the year, I continued to enjoy working with my excellent existing clients on interesting projects and began working with a few exciting new ones too. I truly do count myself fortunate to be able to earn a living learning and working with cutting edge technologies like Node.js, PhoneGap, C# 4.5, and ASP.NET MVC 4.

I also finally began recording new episodes with Rob at TekPub, starting with a new series called jQuery Garage. Though it’s getting a bit long in the tooth now, I was happy with how Mastering jQuery turned out. So, I’m very much looking forward to seeing what we’re able to accomplish in this new series.

2013: Let’s make it great

Since the Mayans were wrong (I know, I know), it looks like we get to take a shot at 2013 after all. Ignoring the political turmoil here in the US and the potential that poorly performing IPOs like Groupon, Zynga, and Facebook might threaten the software investment bubble we seem to be in, I’m still optimistic about 2013.

Between Node.js continuing to make inroads on the server-side, the ongoing proliferation of smartphones and the mobile web, and some early signs that Windows 8 is succeeding, there’s never been a better time to be an HTML, CSS, and JavaScript developer. I would have used the term “web” developer to reference that trifecta in past years, but that’s no longer the case.

If you’re reading this, you’re probably somehow involved with that mix of technologies. If so, you’re poised to be right at the forefront of some our field’s most exciting upcoming developments. I hope you’ll join me in taking advantage of that in 2013.

Thanks

Thanks for joining me here in 2012. I hope you’ll stick around for the upcoming year, because none of the work I put into the site would be worthwhile without you.

Most important of all: I hope you have a safe, happy, and prosperous 2013.

You've been reading Six years of Encosia, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

Since I had a few weeks to write it, this post grew a little bit out of control. Sorry in advance for the wall of text. To hopefully compensate a bit, here’s an index of the major sections:

• Windows 8 RT
• Hardware
• Touch and Type Covers
• ClearType Display
• Apps
• Performance
• Battery Life
• WiFi
• Conclusion

In an unsurprising twist ending, I wrote the first few drafts of this entire post on my Surface RT. I used the Touch Cover for most of it, and then picked up a Type Cover toward the end and used that for the rest.

I tried to write a post like this soon after receiving my original iPad, but was not successful due to a combination of the pain that comes along with long-form writing on a screen-board and the tedious multi-app workflow in iOS — it’s definitely possible, but it’s a task that requires more determination than I could muster at the time.

By contrast, Windows 8 and the physical keyboard made writing this on the Surface RT nearly indistinguishable from writing on my 13″ laptop. If you want a tl;dr for the next 6,500 words, I think that sums it up pretty well.

Windows 8 RT

At its heart, I think the Surface RT is at least as much about showcasing Windows 8 on quasi-reference hardware as it is about that hardware itself.

Having used iOS and Android tablets almost daily for a couple years, Windows 8 is the best tablet operating system I’ve used yet. There’s really no comparison. Once you learn the new gestures well enough to use them effortlessly, Windows 8 makes those older operating systems feel as dated as they look.

Even the simplest things — like accessing application settings and sharing features in a consistent location in the right-hand charms bar — are welcome improvements over the chaos that has been encroaching further and further into iOS’ UX for the past few years.

Multitasking is a pleasure. Swiping to cycle through open apps is neat, but I prefer the swipe left-right-left gesture that displays a temporary sidebar of open apps (and the “missing” Start Menu) on the left. From there, you can jump directly to the app you want instead of cycling through the ones in between. After an hour or two, using that gesture and sidebar became completely unconscious, even though I almost never use that approach on my Windows 8 desktop machine. By comparison, the iOS and Android approaches to multitasking now feels downright archaic.

It’s difficult to put such a visceral UX difference into words. It’s hard to take my iPad seriously anymore, after using the Surface RT. Even though the iPad does have more apps, they all seem to be constrained inside an overall interface that often makes them feel like a child’s toy. By comparison, using Windows 8 on the Surface feels like I’m using a high quality tool — which is what I want. I have enough toys already.

Touch

If you told me a year ago that I’d be using a laptop with a capacitive screen and actually touching the screen on a regular basis, I wouldn’t have believed you. The idea of touching the screen on a regular PC has never made much sense to me no matter how many times I’ve seen staged demos.

After just a few hours of using the Surface, I realized that I was reaching up from the keyboard to tap and scroll without thinking about it on a regular basis. Having a responsive touch screen a few inches from where my fingers naturally rest on the Touch Cover completely changes what feels natural.

So often on web pages, there’s a button or link that you can’t readily activate via keyboard, but tapping it is quick and easy when you’re already looking right at it.

Beyond simple button tapping, the system-wide gestures in Windows 8 are often effort multipliers compared to traditional keyboard and mouse inputs. A quick right-left swipe from the left edge shows thumbnails of open programs and then tapping the one you want to focus is usually faster than flipping through them all with Alt + Tab or hunting and clicking with the mouse.

Similarly, swiping down in Internet Explorer 10 to see thumbnails of open tabs and tapping on one is faster and more useful than cycling through them with Ctrl + Tab. On the Surface’s relatively narrow 16:9 display, it’s great that you don’t have to waste screen real estate on things like the address bar and open tabs while you’re using a particular tab.

A litany of relatively small things — as simple as being able to slide the volume slider up and down via touch after pressing the hardware button — all add up to a level of UI polish that you would normally expect from a more mature product.

Metro

The new “Modern UI” (aka Metro) interface in Windows 8 is at its best on a tablet. It’s easy to navigate, live tiles optionally provide useful ambient information, and it truly does feel modern. The grid of icons on my iPad reminds me of Windows 3.11 after using the Surface for a couple weeks. Not to mention how frustrating the arbitrary page breaks become after you’re accustomed to seamlessly scrolling across Windows 8′s landscape of tiles.

Being able to pin apps to the side was a lifesaver as I wrote this post. Often, I pinned Evernote to the left 1/4 while using the right 3/4 for WordPress’ full screen editor. Using Evernote as a scratch area to temporarily hold sections of the post or serve as reference for rewriting a paragraph was something I noticed sorely lacking from iOS’ simplistic take on multitasking when I attempted the same task with my iPad.

Within a week of using the Surface on a daily basis, I even began unconsciously trying to use its top-to-bottom swipe gesture to close apps on my iPhone. The entire interface is surprisingly natural once you get acclimated to it. Not necessarily discoverable for novices, but powerful, efficient, and intuitive if you put some effort into learning how to use it effectively.

Not perfect

Though the new interface is fantastic overall, I did have a couple minor issues using it even after learning all of its new tricks.

The most persistent annoyance is that, to my knowledge, you can’t see the percentage of battery charge remaining unless you flip over to the desktop and tap the battery icon in the system tray. That’s not terribly hard, but it buries the information a few steps away. I much prefer an ambient indicator of exactly what charge is remaining. The simple icon without a numeric percentage is not granular enough to instill confidence (imagine if the fuel gauge on your car dropped directly from 1/4 tank to empty without warning!).

Another thing I found myself missing is iOS’ scroll-to-top feature. In iOS, on both the phone and tablet, you can tap the status bar at the top of the screen to scroll to the top of wherever you happen to be. On web pages and long lists (e.g. my email inbox every morning), that shortcut back to the top is a very useful time saver.

Those are my only serious complaints about the Windows 8 interface after a month of daily use though. That’s impressive for a first generation device and first iteration of something as fundamentally new as Windows 8.

Hardware

Until very recently, one of the PC industry’s greatest failings has been a lack of solidly-constructed, aesthetically pleasing hardware. This year’s latest wave of UltraBooks has finally begun turning that around, but the MacBook Pro and Air still have advantages in some aspects. Similarly, there really hasn’t been a PC (or Android) tablet that compares with the iPad’s industrial design.

The Surface RT has finally made an impressive dent in that status quo. I’ve found it to be every bit as nice in reality as it looks in Microsoft’s advertisements.

The VaporMg case

The Surface’s construction and VaporMg case truly do seem to live up to the marketing hype thus far: It’s as solid as any electronic device you’re likely to ever hold. During one of the launch events, Panos Panay dropped a Surface on the floor from shoulder-height, picked it up, and continued his demo. Steven Sinofsky rode a make-shift Surface RT skateboard. It continued working after CNET froze it for over two hours and cooked an egg on it for another hour after that. I’ve even seen a few stories about Surfaces that have been run over by automobiles and survived with only superficial damage to the case but not the display or innards.

I have not been treating my Surface gently during the past month and haven’t had the slightest worry that it would break. I feel no trepidation tossing it around on semi-soft surfaces without a case, and generally treating it like a tool instead of something pretty and fragile.

Notably, I haven’t seen a single story yet about an accidental drop shattering the front glass like is so common with iDevices.

The kickstand

It’s interesting how much attention Microsoft’s marketing has given to the kickstand. It seems almost odd until you use it regularly, but the kickstand ends up being as integral to the overall experience as its Touch and Type Cover counterparts.

The kickstand’s hinge offers just enough resistance that it never flops open accidentally when you’re moving it around on soft surfaces, but easily opens into place with satisfying tactile feedback when you intentionally give a tug via the recessed groove on the side. Similarly, flipping it closed requires just enough force that you’ll never slip it shut while touching the screen when it’s upright, but shutting it with a squeeze of one hand requires only a comfortable effort.

It would be nice if the kickstand’s angle were more adjustable. Its 22-degree angle is usually pretty good for content creation and I’ve actually made use of its symbiosis with the rear-facing camera’s opposing 22-degree angle a couple times. On the other hand, it props the Surface up a bit steeper than I’d prefer when I’m sitting at a table and reading. However, if I had to choose between how secure and steady the kickstand is currently or a couple more angles, I’d happily take it as is.

Other

The front- and rear-facing cameras are about what you would expect from a tablet. They’re just passable for video conferencing and recording low-end HD video, but forget about using them for still photos of any kind. Neither camera in the Surface RT begins to compare to the camera in any smartphone you’re likely to own in 2012.

I’ve never really cared about the iPad’s lack of a standard I/O port, but the combination of a USB port and Windows’ broad hardware support is more useful than I had expected. Ironically, I even used it to transfer photos from my iPhone without any configuration hassle.

The built-in speakers are underwhelming. I can live with tinny sound from such tiny speakers, and that’s the case with every tablet I’ve used, but the maximum volume is far too quiet. In a noisy environment like a coffee shop or a Microsoft Store, you can barely hear the sound at all. One consolation is that the internal sound hardware does drive headphones with fine volume and quality. I plugged my Bose headphones into it and the sound was loud, clear, and rich. The built-in speakers desperately need an upgrade in the next revision though.

Touch and Type Covers: Surprisingly good

I opted for the bundle that included a 32gb Surface RT and a Touch Cover. I was tempted to also get a Type Cover in case the Touch Cover didn’t work as well as advertised, but decided to make myself to give the lighter, thinner keyboard a fighting chance first. As it turns out, almost no acclimation was necessary. Typing on the Touch Cover is nothing like typing on a real keyboard, but it feels surprisingly natural to me (and I’m picky about my keyboards).

You may have read that laying your fingers on the touch cover’s home row results in unwanted “asdfjkl;” gibberish, but that hasn’t been my experience at all. I can replicate that by forcefully slamming my fingers down onto the home row and wiggling them around a bit, but you’d have to be incredibly ham-fisted to have that problem during normal usage. If anything, I think the “pinky finger” keys take slightly more pressure to activate than I’d prefer for my typing technique, but it’s definitely better to err the side of extra pressure than accidental gibberish.

Probably for the same reason that I felt like significant pressure was necessary, I haven’t had much luck typing on soft surfaces. Using the Touch Cover in my lap or on an ottoman, I couldn’t find a good rhythm.

An unsung benefit of the Surface’s Touch and Type Covers, as compared to Bluetooth keyboards that work with other tablets, is that the Surface’s keyboards draw their power from the Surface itself through the magnetic connector. The tablet-friendly keyboards that companies like Logitech and Zapp sell are nice enough in theory, Bluetooth pairing and 2.4ghz interference aside, but no one talks very much about the extra hassle that comes with keeping the keyboard’s battery charged in addition to the tablet itself. You never have to think about that with the Surface.

Can you hear the words that I’m… typing?

I think that one of the keys to learning to use the Touch Cover is making sure the Surface’s sound isn’t muted. Similar to Windows Phone, the Windows 8 RT on-screen keyboard gives helpful audible feedback as you type — not just monotone clicks that are the same for every key, but varying beeps and bloops for different keys. It’s a surprisingly satisfying feedback mechanism. Over time, you can almost recognize the sound of distinct sequences of letters being entered.

The biggest drawback of a keyboard like the Touch Cover’s is that you don’t get much tactile feedback as key presses are registered. However, if you have the Surface’s sound unmuted, typing on the Touch Cover produces exactly the same audible feedback that the on-screen keyboard does. I was surprised how quickly that audible feedback trained my fingers to calibrate for pressure and rhythm while I typed.

So, do be sure that the device’s sound is audible if you’re trying one in a Microsoft Store or using your own Touch Cover for the first time.

A cover that actually works as a cover

Compared to my iPad’s Smart Cover, which I rarely use as a cover, folding either the Touch or Type Cover over the Surface and carrying it is a great experience. Where the iPad’s cover feels awkward as a stand and flimsy as a cover, the Touch and Type Covers’ single panel makes a great cover and the built-in kickstand is perfect for propping the Surface up at good reading and typing angle on flat surfaces.

A tiny trackpad is better than no trackpad

One nice thing about both the Touch and Type Cover is that they include a tiny, but serviceable, trackpad. You might be skeptical about the usefulness of a trackpad barely bigger than the spacebar when you have an 10.6″ capacitive touch display just a few inches away, but I disagree for one reason: hover.

Years into this supposed post-PC era, a depressing number of websites still depend on the mouseover event for crucial aspects of their functionality. Sometimes you can double-tap those elements, but if hovering reveals an element that isn’t in exactly the same location (e.g. many popup menus), you’re probably out of luck if all you have is touch input.

With the Touch Cover’s trackpad, temporarily fiddling with the mouse pointer allows you to circumnavigate those situations that would otherwise be dead-ends on other tablets.

Type Cover: Perfect

A couple weeks into this experiment, after I thought I’d forced myself to test the Touch Cover thoroughly enough, I also purchased a Type Cover. I’m not going to say very much about the Type Cover other than it’s perfect. I probably wouldn’t change one thing about it.

I use a Logitech diNovo Edge on my desktop PC, which is probably my favorite keyboard of all time. Even coming from that high level of expectation, I found a rhythm on the Type Cover almost immediately and can type at full speed.

If you don’t mind the slight extra thickness and feeling keys move under your fingers when you flip the cover behind the Surface, the Type Cover is good enough to directly replace almost any laptop keyboard and even some desktop keyboards.

Display: ClearType saves the day?

Most of the criticism I’ve seen targeted at the Surface RT has been directed at Microsoft’s decision to use a relatively low resolution display. Compared to the current iPad’s 2,048 x 1,536 resolution, the Surface RT’s 1,366 x 768 sounds pretty disappointing.

Microsoft has responded by saying that several aspects of the Surface RT’s display, ranging from lower reflectivity to ClearType subpixel rendering, negate the resolution difference:

First prong, Microsoft has the best pixel rendering technology in the industry (cleartype 1.0 and 2.0) .. these are exclusive and unique to Windows, it smooths text regardless of pixel count.

Second, we designed a custom 10.6” high-contrast wide-angle screen LCD screen.

Lastly we optically bonded the screen with the thinnest optical stack anywhere on the market.. something which is more commonly done on phones we are doing on Surface. While this is not official, our current Cleartype measurements on the amount of light reflected off the screen is around 5.5%-6.2%, the new IPad has a measurement of 9.9% mirror reflections. Doing a side by side with the new iPad in a consistently lit room, we have had many people see more detail on Surface RT than on the Ipad with more resolution.

It’s easy to interpret that response as misdirection away from the core issue of display resolution, but it doesn’t seem to be wrong in my limited experience. Most of the time, the display looks fantastic. It’s clear, sharp, and images look like they’re closer to the surface of the device’s glass than other tablets that I’ve used.

When viewing photos, video, the start screen, and most native Windows 8 apps, the display looks perfect. Beyond my own experience, no one that I’ve shown my Surface to has had anything but positive comments about the display.

They weren’t joking about the viewing angle

The range of usable viewing angles on the Surface RT is unbelievable. I exclusively use LCD displays with IPS panels, and the Surface RT still has the best off-center viewing quality I’ve ever seen.

I didn’t notice just how well the display looks nearly on-edge until I accidentally left laying face up on a tall kitchen counter one day and walked across the room to do something. Walking back toward the Surface, I realized that even at my ~10-15 degree viewing angle, there was almost no color distortion at all. In fact, it looked almost as bright and legible as if I were holding it at arm’s length directly in front of me.

That may not sound incredibly important, but keep in mind that you’ll be using a tablet in a wide range of positions. Being able to hold it at any comfortable angle and still see the screen clearly is an important feature.

Ambient light sensor

The biggest display-related complaint that I have after a month is that the ambient light sensor is too sensitive.

As with most devices, when you adjust the Surface RT’s display brightness, the device attempts to maintain that relative brightness as ambient lighting conditions change. So, if the lighting where you’re using the Surface at gets brighter, the display also gets brighter to compensate, and vice versa when the ambient lighting dims.

An ambient light sensor is a nice feature for a device that you’re likely to use in a variety of settings, but the Surface’s light sensor has a hair trigger. When I’m using it in a dark room, even the light from bright app or page reflecting back from my face is enough that display reacts as if lighting in the room changed.

At first, the effect is very disconcerting. Seeing the adjustment happen right as you’ve tapped to open an app makes it seem almost like there’s an intermittent problem with the backlight. Over time, I realized what was actually happening and it’s less alarming, but still annoying.

Hopefully, this is something Microsoft can address in a software update.

Apps

Angry Birds Space running on my Surface RT (perfect shot!).

Running Windows 8 on an ARM device means that you can’t install existing x86 software (e.g. Visual Studio, QuickBooks, Comet Cursor…), so Windows 8′s new “apps” are going to be a crucial ingredient in the Surface RT’s success or failure.

Built-in apps: Not bad

When you see the start screen for the first time, you’ll already have a handful of Windows RT apps installed. Those built-in apps include a wide range of Metro-style apps for email, calendaring, photos, news, weather, finance, music, video, and the camera. There are also a few quasi-desktop apps, the desktop version of Internet Explorer 10 and the pre-installed Office 2013 preview.

Most of these built-in apps are passable.

• The People app is sluggish at times and difficult to navigate when you’re viewing dozens of status updates, but it does a pretty good job of what it’s intended to. I’d prefer a dedicated Facebook app to this aggregation though.
• The Calendar app works well enough for my simple needs and its integration with the lock screen is nice. It has kept in sync with my Google Apps account and setup was hassle-free.
• Messaging works well enough for Facebook and MSN (and/or Skype now?) instant messaging. I was disappointed that it doesn’t support Google Chat though — especially since the Mail app does support Google’s services. There doesn’t seem to be a good reason to leave such a popular service unsupported.
• The ancillary apps like Travel, Finance, and Sports work well enough and have led me to discover some interesting content that I probably wouldn’t have found otherwise.
• Contrary to some reviews I’ve read, the Store app has worked well for me. It did give me trouble a couple times, but closing it with a downward swipe and reopening it fixed that (something I’ve experienced quite often in iOS 6′s app store as well, to be fair).
• The SkyDrive app is nice to have right out of the box. Since I used my existing Microsoft account when I set the Surface up initially, I had immediate access to my SkyDrive files.

Mail

With most of the built-in apps out of the way, let’s talk about the Mail app. The phrase “unmitigated disaster” comes to mind.

It’s slow. Often, it blanks out the entire message list and reading pane for several seconds after I delete or move a few emails and then redraws the whole thing. The editor’s performance when composing some messages — particularly when replying to a message with a large body of preexisting content — is unbelievably slow. It has trouble with inline images in messages on one of my accounts, prompting me to individually download each inline image and then failing every time. Dealing with multiple emails, whether moving or deleting, is cumbersome. I could go on, but you probably get the idea…

The Mail app is the worst email client I can remember using since Lotus Notes. This app needs to be overhauled and an update pushed out via the Store with absolutely the utmost urgency.

Considering that email is one of the most important tasks I used to use my iPad for, the current state of the Mail app is absolutely unacceptable to me. If anything about the Surface RT drives me back to the iPad, it will most likely be this.

Store: Reminds me of the original iPad

As I mentioned earlier, one of the biggest drawbacks of running Windows 8 on an ARM device is that you can’t install existing x86 apps. With the Windows Store is still in the process of ramping up its inventory of Windows RT apps, that’s an important limitation to understand. Some notable apps like Netflix and Hulu+ are already available, but others like Dropbox and Facebook are conspicuously absent (though the built-in People and Messaging apps attempt to replace the latter).

It’s often suggested that Windows Phone 7.x has struggled to gain traction due in no small part to its lack of corresponding native apps that iOS and Android users enjoy. Following from that, some pundits claim that Windows 8 on ARM will suffer a similar chicken-or-egg problem while bootstrapping its new app store and hardware ecosystem.

I think the app store situation is interesting because it reminds me almost exactly of the iOS app store when the iPad was first released. It’s hard to remember now, but apps targeting the iPad’s screen size were scarce during the months after the iPad’s initial launch. As we all know now, iPads sold like hotcakes and developers responded by filling the iOS app store with compelling apps that took advantage of the iPad’s form factor, but that took time.

I expect that Microsoft’s massive distribution will result in such a proliferation of Windows 8 desktops and laptops that its app store will also become an irresistible development target. As a side effect, even if Windows 8 tablets don’t sell at the same pace that the iPad has immediately, they will still benefit from much of the  development that targets Windows 8 as a whole.

Only time will tell, but I think the Windows 8 store is a promising platform.

Internet Explorer 10

While the Store is still ramping up its inventory, Internet Explorer 10 is probably the most important app that ships with the Surface RT.

For example, while there’s no native Facebook app for Windows 8 yet, Facebook’s full desktop website works perfectly well even in the “Metro” version of IE10. The web interfaces to my email accounts have even blunted the agony of using the built-in Mail app somewhat.

Internet Explorer 10 is a surprisingly good browser. It lacks some features that I wish it didn’t, like WebGL, but it’s far and away better than its reputation from years past might suggest. It even supports WebSockets, which you probably wouldn’t expect if you haven’t kept up with IE10′s development.

Testing Internet Explorer 10 on HTML5Test.com.

Even with the recent improvements, IE10 scores an underwhelming 320 at HTML5Test.com. For comparison, Mobile Safari on iOS 6 scores a 386 and Chrome 24 on my Windows desktop comes in at 453. So, IE10 will keep up with almost every mainstream website, but don’t expect it to handle the latest tech demos or sites using advanced HTML5 features.

One thing I’ve noticed is that IE10 seems to prioritize ongoing page rendering more than it does re-rendering the current viewport when you change zoom levels. On many pages I visit, one of the first things I do is zoom and pan to just the text I’m interested in reading. IE10 often leaves that newly-zoomed text heavily pixelated for several seconds before refining it to match the new zoom level. Not a good experience at all. By contrast, Mobile Safari on my iPad always stops everything to immediately re-render fonts when I zoom in on a page.

Hopefully, that’s an IE10 issue that can be solved with a software fix though, and not a long-term problem. I do think it’s a common enough scenario and jarring enough issue that it does need to be addressed long before IE11 though.

Performance

An nVidia Tegra 3 ARM CPU and 2GB of RAM are at the heart of the Surface RT. My experience with native apps, streaming HD video, viewing web pages, and playing games has been mostly smooth and impressive.

Particularly, scrolling across the constantly updating live tiles on the start screen always feels satisfyingly “fast and fluid”. Where I’ve noticed that Android tablets struggle to smoothly juggle animating its widgets and moving them around at the same time, the Windows 8 on the Surface RT never feels slow or sluggish.

Even typing this 6,000+ word post in WordPress’ “visual” editor, all of the text and several images crammed into an HTML textarea, has never appeared to be a challenge for my Surface RT.

Office 2013

There have been some high-visibility complaints about performance in the preview version of Office 2013 that comes pre-installed on this first wave of Surface RT devices. Mine suffered the same problems initially, to the point that even rendering newly typed characters in Word 2013 would often lag seconds behind my keystrokes.

However, installing the RTM version of Office 2013 via Windows Update completely solved the Office performance problems on my device. I even tried creating documents based on some of the more complex templates and typing gibberish as fast as possible at the top of the document (so the rendering engine also had to move the entire document down as a result, which previously exacerbated the performance issue previously), with no visible lag at all.

So, it may be true that the Surface RT’s Tegra 3 processor doesn’t have quite enough horsepower to make up for unoptimized preview code targeted at powerful desktop machines. That’s not something I’m going to hold against it though. Running a fully functional instance of the latest version of Office on an ARM-based processor is quite a feat in any case, and updating to the optimized release version eliminates all of the performance issues that I could reproduce.

Games

One of the first things I tried on day one was installing Cut the Rope and Jetpack Joyride, both of which I’ve played on other platforms. I was disappointed to find intermittently choppy graphics performance in both games — no where near as smooth as the same games on my second generation iPad.

A few days later, I decided to give gaming on the Surface RT a second chance and purchased Angry Birds Space. Since purchases on the Surface transfer over to my other Windows 8 PCs anyway, that $5 investment would at least be worthwhile on my desktop.

I was pleased to find that graphics performance in Angry Birds Space on the Surface RT was nearly flawless — almost indistinguishable from playing the same game on my iPad 2 or Core i7 desktop. Compared to the other two games I had tried, the difference was night and day. The disparity was so great that it even prompted me to spend a few minutes killing processes and trying the other two games again to make sure that I hadn’t inadvertently played them during some background task I was unaware of  previously (nope; performance was the same).

A few weeks later, I had the same kind of positive experience with Angry Birds Star Wars (which is surprisingly fun, not a cheesy sellout).

I suspect that Microsoft has been lax about enforcing performance criteria when approving apps that are already popular on other platforms, putting a premium on filling the Store out with apps that iOS and Android have as quickly as possible. Over time, I doubt this will be a serious issue as developers have more time to tune their submissions, and in the shorter term the bad apples are avoidable by using the Store’s trial feature before you buy.

To the cloud!

Speaking of how my Angry Birds Space purchase applied to all of my Windows 8 PCs, so did my progress in the game itself. I happened to install the app on my desktop to see how well it worked with mouse (pretty well) and was surprised to see that I was already credited with the stars and achievements for the levels that I had played earlier on my Surface.

It’s a small thing, but I was impressed. There have been several times that I installed the same iOS game on both my iPad and iPhone, only to be faced with replaying already-defeated levels and losing interest in that proposition almost immediately.

Seamlessly syncing an arbitrary application’s settings and data across multiple devices is going to be a huge differentiating factor for Windows 8 tablets, PCs, Laptops, Windows Phone 8, and the Xbox when compared to the competition’s fragmentation. Microsoft has struggled to find a coherent synchronization story for years, but seems to have finally brought its entire ecosystem into firm alignment this year.

Battery Life

54% remaining after nearly a full day’s use.

The ARM architecture’s key selling point is that it offers adequate performance at low power consumption (and produces less heat as a byproduct). So, one big question about the Surface RT is whether or not the extended battery life is worth the performance loss and significant compromise of not being able to run “legacy” x86 software.

Compared to any other PC running Windows that you’ve used in the past, you will be impressed with Surface RT’s battery life. I haven’t yet managed to deplete a full charge in a single day of moderate use, ranging from light tablet reading, heavy-duty content creation with the keyboard, to playing a few levels of Angry Birds Star Wars, to using Xbox SmartGlass in the living room. You’re basically looking at the same charging cycle as a good smartphone, where you can expect more than a full day of moderate usage, but probably wouldn’t want to try for two full days.

My initial opinion about the Surface RT’s battery life, compared to my iPad 2, wasn’t very favorable. On further reflection, I realized that the Surface’s battery was actually great. The difference is that the Surface is far more useful than the iPad and I’ve been using it more intensively than I have ever used my iPad. I think that says a lot about both the Surface RT and Windows 8.

Heat

Talking about battery life and the ARM architecture’s benefits wouldn’t be complete without talking about heat. The short answer is that there isn’t any.

I was able to make the back panel warm up ever so slightly at one point after I’d played Angry Birds for about fifteen minutes, but it was negligible. I wouldn’t have noticed if I hadn’t specifically been trying to stress test.

On the flip side of that same coin, I have no idea if the Surface RT even has a fan. I’ve never heard one spin up and heat has never been an issue anyway.

Mag-not-Safe

Speaking of charging the battery, the charging connection needs some work.

When I read that the Surface had a magnetic charging connector, I had visions of Apple’s excellent MagSafe connector. Unfortunately, the Surface RT’s connector, while magnetic, is awkward to connect to the side of the device.

Worse, I always feel like I’m probably scratching the area around the connector when I maneuver it into place (though I haven’t seen any visible wear in the area yet). This really should be improved in the next device — hopefully as soon as the Surface Pro.

WiFi

I’ve always considered WiFi to be a fungible feature. Either it works or not, based primarily on whether or not my device supports the same frequency and standard that the available hotspots do, right?

Not so much, apparently. The dual-antenna WiFi hardware in the Surface RT changed my mind about the varying quality of WiFi hardware after two specific experiences.

No more holding it wrong

As a long-time iPad user, one thing that can be incredibly annoying, at least with my iPad 2, is that holding it “wrong” significantly hampers its WiFi performance. Unfortunately for me, the way I preferred to hold my iPad happens to be exactly the “wrong” way. I try to avoid holding it that way, but my hand usually slips back into that position every few minutes and websites stop loading. If I move my left hand, everything starts working great again.

At first, I didn’t believe that could possibly be the case. I always assume coincidence with these things until I can prove otherwise. However, running SpeedTest and varying my hand position confirmed my suspicions.

On the contrary, I can’t find a way to hold the Surface RT that impacts WiFi performance in the least. It’s a small thing, but a nicety that compounds over time.

Can you hear me now?

Since the Surface RT doesn’t support a cellular data connection, being able to reliably connect to WiFi is important. Almost immediately, I ran into a perfect example of how exceptional the Surface’s WiFi support is.

There’s a local restaurant a few miles from me that has a great patio where I can take the dog for a late lunch, relax, and catch up on email for a bit. The only problem is that the WiFi there is terrible. With my MacBook Air, I can only connect to it about half the time (and only if I sit in a particular seat) and it’s painfully slow even then. My iPhone and iPad won’t connect to it at all. Usually, they don’t even detect that the network is available.

With the Surface, I can sit anywhere on the patio and connect right up with 2-3 bars of signal strength. I had hoped for at least a reliably minimal connection with the Surface’s dual-antenna setup, but that result surpassed my expectations to be sure.

Sure, the root problem here is that the restaurant has their WiFi hotspot buried in the back of the building somewhere, but that’s hardly the exception. Not many businesses prioritize WiFi coverage, so the Surface’s ability to lock onto a weak signal and make the best of a bad scenario is welcome.

Conclusion

It’s been a few years since Ballmer first unveiled Microsoft’s “three screens and the cloud” strategy, but I’ve never really been very convinced by that vision very fully until these past few weeks. In a household with a litany of iDevices and a MacBook Air, like mine, an unproven device like the Surface RT is not an easy sell. Though I develop primarily on the Microsoft web platform, I’ve never been one to buy Microsoft products in other segments just for the sake of brand loyalty.

Yet, I recently realized that not only have I completely stopped using my iPad, I haven’t even turned on my MacBook Air since the Surface arrived. For my needs, the Surface RT really is that good. In fact, the integration between my Windows 8 desktop PC, Surface RT, and Xbox has actually made me want to try going “all in” and replacing my iPhone 5 with a Windows Phone 8.

Windows 8 on quality tablet hardware, like the Surface, is simply delightful to use. Even though I miss a few iOS apps, I don’t think I could go back to using iOS itself now. Everything else feels clumsy and tedious once you’ve used and mastered Windows 8 on the Surface.

As you might infer from all of the direct iPad comparisons in the preceding sections, I almost made the mistake of judging the Surface RT directly against the iPad. Most of the mainstream reviews I’ve seen have done exactly that, and I think that’s natural, but also a mistake. The Surface RT does fall short in some very specific niches where the iPad excels, but that’s because they aren’t really the same kind of device. I believe the combination of Windows 8 and the Surface is a subtly different type of thing than the current crop of consumer tablets, focused on a more optimal balance between content consumption and creation without sacrificing sleek, beautiful construction.

Nothing else I’ve seen or used has struck that chord so perfectly.

Should you buy a Surface RT?

Maybe. I personally like my Surface RT so much that it’s hard not to recommend it to everyone, but I don’t think it’s necessarily appropriate for every user (yet).

If you’re thinking about buying one for a non-technical friend or family member, wait. The Store needs to fill out a bit more with popular apps and a few rough edges, like the built-in Mail app, need to be smoothed out before it’s an ideal device for a non-technical user. There’s a good chance this will be an ideal device for consumer users after a few software updates and a couple months worth of Store submissions, but it’s not quite there today.

If you’re considering a purchase for yourself or someone else technically savvy, understand the limitations of Windows 8 RT on an ARM device, and still want to give it a try then you absolutely should. The Surface RT has met or exceeded almost all of my expectations, and completely superseded my iPad from day one.

Don’t forget the Surface Pro

The inability to develop software on the Surface RT might be a non-starter for some of you. There is a remote desktop client that you could use to develop on a remote machine, but that’s not a great experience (I’ve tried). Over time, I expect tools like Cloud9 to support IE10 and good Windows 8 code editors to start showing up in the store. However, I doubt it will ever be possible to develop for ASP.NET or Windows 8 itself on the Surface RT.

If screen resolution, app selection, performance, and/or development are too important for to you to compromise on, you can always wait a few months for the Surface Pro. It’s rumored to pack a 1920 x 1080 resolution into the same 10.6″ package, have a full-power Intel processor, a stylus/digitizer, and other PC-class hardware. As well as my lowly Surface RT has replaced my MacBook Air, I think the Surface Pro will be a game changer for users with more demanding needs.

Disclaimer

To be clear, there is no disclaimer. I purchased my Surface RT, Touch Cover, and Type Cover online at the Microsoft Store with my own funds and received no promotional consideration for writing this post.

You've been reading A month with my Surface RT, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

Though Windows 8 apps don’t look like traditional Windows programs, many of Windows’ traditional keyboard shortcuts still work in them. In Windows, Alt + F4 is the keyboard shortcut to quit the active application and that shortcut also closes apps running in the new UI.

At first glance, the Surface’s Touch Cover doesn’t appear to have traditional function keys. However, the top row doubles as function keys if you hold down the “Fn” key at the lower right. As you might expect, the fourth key from the left (marked as a play/pause key) is F4′s secret identity.

So, holding both Alt and Fn and then pressing play/pause works to close the active application without dealing with the vertical dragging gesture.

You've been reading Closing Windows 8 apps with Surface RT’s Touch Cover, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

Have you ever tried washing dried, day-old ketchup off a dish? It’s not fun. What would have taken just a couple seconds to rinse off while it was still fresh can take minutes and multiple attempts to scrub off later.

Worse, the realisation that you’re going to have to deal with the dried ketchup is most likely to come right when you need to do something else with that dish the most.

As you let ketchup (and other foods) accumulate on your dishes without cleaning them immediately, eventually your entire collection of dishes is unusable.

Some dishes are more disposable than others. For some dishes, you’re eventually more likely to throw the dish out and start over with a new one than find a way to make the ketchup-spackled disaster you’ve created serviceable again.

Seriously though

One of the hardest parts of software development is simplifying and explaining it to the non-technical people who write the checks. Technical debt is one of those crucially important concepts that can alter the course of an entire company if left unchecked, but it can be incredibly difficult to clearly convey that to non-technical stakeholders.

Your negative notions about what debt is might be what a “business guy” considers productive leverage. You can just pay that debt back after the new feature makes us all rich, right? I wonder if that has ever happened?

Next time, tell them it’s like ketchup.

You've been reading Technical debt is like ketchup, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

The whole thing began when I tweeted about some rough benchmarks on ASP.NET MVC controller actions vs. ASP.NET Web API endpoints last week, and Ashic Mahtab asked me to also run some benchmarks comparing MVC’s Razor and WebForms view engines. When I ran those benchmarks and replied to him with the result that Razor was running much slower than WebForms, he had this suggestion:

@encosia did you remove the web forms view engine for the razor test?

— Ashic Mahtab (@ashic) September 2, 2012

Good idea. I did that, re-ran the Razor benchmark, and the magnitude of the change really surprised me. Razor was over twice as fast with the WebForms engine removed!

I knew that removing the WebForms view engine improves the performance of Razor view resolution, but I didn’t expect the difference to be nearly that significant. So, why was the difference so large?

The search for a view

Before we get to the fallacy in my benchmarks, you may be wondering why removing the WebForms engine made such a big difference. The root cause can be seen in an error message that’s probably all too familiar if you’ve spent any time working with ASP.NET MVC:

By default, MVC is configured to resolve named views by searching for files that match the WebForms view engine’s naming conventions first. Only after scanning unsuccessfully for those first four variants does MVC search for Razor views.

As you can imagine, running through the process of checking four unused locations first for every return View() and Html.RenderPartial is quite wasteful if you aren’t using the WebForms view engine in your project.

Removing the WebForms view engine

If that view resolution inefficiency bothers you, it’s easy to remove the WebForms view engine from the mix. Just drop code something like this in your Global.asax.cs’ Application_Start event:

ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());

In debug mode, that small change results in a significant performance boost because MVC will be able to locate views four I/O operations quicker. Often, the very first location MVC searches is now the correct one for C#-based Razor views.

Benchmarking bad

I wanted to get a better idea of what impact removing the WebForms view engine would have on a real-world page. With the plethora of view resolutions necessary on a complex page, a real site is a more interesting test than benchmarking a simple DateTime.Now. So, I found an older MVC site that I had recently migrated from WebForms to Razor, benchmarked it, removed the WebForms view engine, and benchmarked it again.

The results spoke for themselves. Before, with the WebForms view engine’s search locations taking precedence over Razor:

1,225 requests per second across 1,000 concurrent connections. Not too shabby, but now let’s eliminate the WebForms view engine from the mix and try it again.

Running the same benchmark with only the Razor view engine, using the Clear/Add approach shown earlier in this post:

2,671 requests per second now, testing the same page with the same benchmark settings. Two lines of code have resulted in roughly twice the performance!

That’s a pretty impressive improvement, but incredibly misleading.

All for naught

At this point, you might be thinking that the point of this post is to remove the WebForms view engine if you’re using Razor. After all, twice the performance is pretty compelling.

Quite the opposite, it turns out that my benchmarking was pointless because I was running these sites in debug mode locally. I’ll explain why that matters in a minute, but first let’s look at the same benchmarks with debug set to false.

First, I benchmarked the default view engine setup again. With the WebForms view engine’s search locations coming before Razor’s, these were the results:

Now, with the WebForms view engine removed and only Razor’s view resolution in play:

We’ve gone from a 100% performance increase to a meager 1-2% increase. What in the world happened? Wouldn’t you expect the performance optimizations in release mode to apply equally in both scenarios?

So, what happened?

In debug mode, view resolution is optimized for ease of development. MVC iterates through the view resolution process each and every time your code renders a named view. That’s helpful since you obviously do want the environment to respond immediately to your changes when you’re working on a site.

In release mode, however, MVC’s view resolution is optimized for performance. When a view location is successfully resolved in release mode, MVC caches the result of that lookup and doesn’t need to perform another filesystem search when it encounters a reference to that named view again.

The result is that the apparent inefficiency of having WebForms’ naming conventions take precedence over Razor’s becomes negligible after the first resolution. So long as you don’t allow your production sites to run in debug mode, the view resolution issue is almost entirely eliminated.

debug=”false” – not just for view engines

View resolution caching is just one reason of many to ensure that you do not run your production sites in debug mode. Other serious drawbacks include:

• Timeouts – Have you ever noticed that you can spend an indefinite amount of time fooling around in the debugger without a halted request timing out? That’s because debug=”true” disables timeouts entirely, which is never a good idea on a live site.
• Bundling and Minification – ASP.NET’s new web optimization feature can automatically bundle and minify your JavaScript and CSS, but it only does so in release mode. When you run with debug=”true”, bundles are served as separate, unminified, uncombined script references with short caching headers. That’s important during development so you can read/debug your JavaScript code, but it defeats the entire point of the optimization exercise in production.
• WebResource.axd caching – Speaking of client-side resource optimization, resources served through WebResource.axd include aggressive caching headers in release mode. In debug mode, they are not cached at all.

There are even more reasons to avoid debug=”true” in production, but the items above are a few that I think are less obvious since they aren’t directly related to benefits associated with release mode compilation. It’s easy to think of debug and release in terms of compiler optimization and debug symbols since the configuration switch is on the “compilation” element in web.config.

So, it’s important to be mindful that this single “compilation” setting controls a wider range of your site’s functionality than you might expect.

Conclusion

Of course, you probably already know that you shouldn’t deploy a live site in debug mode, but how many times have you seen it happen anyway?

There’s always a “good” reason, like coaxing more detailed error messages from a site that only breaks in production, or disabling client-side resource caching to fix issues when rolling out new assets. Stretched as thin as most of us are, it’s all too easy to leave that site running in debug mode after the immediate issue is resolved.

So, let my benchmarking blunder be a reminder to check today and be sure that you don’t have any production sites running in debug mode.

You've been reading A harsh reminder about the importance of debug=”false”, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

I thought it was an interesting episode. Though I’ve occasionally been sucked into “someone’s wrong on the Internet” myself, I try to avoid drama. So many debates-turned-arguments on the Internet are all downside and have almost no potential upside even if you “win”.

So, I was really interested to hear what others had to say about the topic, and they did not disappoint. If the subject sounds interesting to you (and fair warning, there’s almost no technical content in this one), you might enjoy it too.

You can stream or download the episode here: The Developer’s Life – 2.0.9 Drama

You've been reading Hear me talk about drama on This Developer’s Life, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

That’s good news on both counts, but reminds me of an issue that I’ve been meaning to write about for quite a while now. Unfortunately, each new 1.n jQuery release results in a new wave of sites linking to the Google CDN’s copy of jQuery in a way that seems intuitively correct, but results in needlessly poor performance.

If you don’t care about the hows and whys, the short story is that it’s crucial that you always specify the full major.minor.patch version number when you use the Google CDN. Even though jQuery itself only refers to its new releases with a major.minor version number (e.g. 1.8), it’s important that you append a trailing .0 when you use the CDN to include a new minor revision on your page.

In other words, please use this URL to reference jQuery 1.8 on the Google CDN:

ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js

Under no circumstance should you omit that seemingly superfluous .0 in the version number on a production site. Failure to include the trailing zero will result in significantly degraded caching.

If you don’t care about why, you can stop here. Just be sure to add the .0 when you’re referencing jQuery 1.7, 1.8, 1.9, 2.0, 2.1, and so on. If you’re interested in why it’s so important, keep reading.

My least favorite Google CDN feature

One of the Google CDN’s less obvious features is that you can reference the libraries on it without specifying a full version number. If you do that, the CDN will determine what version of the library is the latest one that matches your partial version number and respond with that.

For example, referencing any of the following URLs will retrieve the exact same copy of jQuery 1.8 at the time this was written:

// Obviously...
ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js
 
// Makes sense...
ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.min.js
 
// Living dangerously.
ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

Similarly, both of these URLs will retrieve the same jQuery 1.7.2 script content, probably for as long as the Google CDN hosts jQuery 1.7.x:

ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.min.js
 
ajax.googleapis.com/ajax.libs/jquery/1.7.2/jquery.min.js

When you first discover this “latest version” feature, it seems clever. Whether you want to keep your site’s jQuery reference up to date automatically or don’t feel like typing the couple extra characters, using the less-specific references may be appealing. However, if you care at all about your site’s performance, you should not use this feature.

Since the abbreviated references return the same content, you may be wondering why it matters whether you use the 1.8 or 1.8.0 URL variation. Caching is the key.

Caching makes the web go ’round (faster)

If you’re interested in web performance, you’ve probably already heard of far-future caching headers as a best practice. In the struggle against lethargic load times, good caching is one of the most potent tools in your arsenal.

As it turns out, that far-future caching mechanism is at the crux of why a fully-qualified version number is important in references to jQuery on the Google CDN. So, it’s worth talking about exactly how that works.

Better than nothing: 304 “Not Modified”

Even without special caching instructions, browsers automatically cache local copies of static files, like jQuery, that they download in the course of rendering pages. To speed up subsequent visits, they then attempt to use those local copies instead of downloading the same file over and over again. However, without any knowledge of how long each file is okay to reuse before it has been updated, the browser needs to check in with the server before it uses that local copy.

When your browser makes a request for static content that it has cached locally, it also adds an If-Modified-Since HTTP header to the request. That header essentially gives the server an opportunity to indicate whether or not the resource has been changed since that timestamp.

If that If-Modified-Since header that the browsers sends is more recent than the file’s last modified timestamp on the server, then the server can return a response of 304 “Not Modified” instead of sending the file back at all. When the browser receives that 304 response, it will then load the file from its local cache instead of retrieving it from the server.

When you’re dealing with large assets, a 304 response can save significant amounts of download time. Unfortunately, with a file as small as jQuery, the ceremony necessary to retrieve that 304 response is nearly as time consuming as just downloading the file in the first place.

Best: Far-future caching

Eliminating the inefficient 304 “Not Modified” handshake is where far-future expires and cache-control headers come into play.

Returning those HTTP headers along with a resource allows you to pre-authorize the browser to reuse that content again for some period of time in the future when it encounters a reference to the same URL. Taking advantage of that mechanism empowers the browser to skip the request for a 304 check entirely and immediately use its cached copy from disk if available.

Even when you apply far-future caching to site-specific content served from your own servers, the impact on a visitor’s repeat page views can be dramatic. Applied to a public CDN, where many sites reference the same URL for popular scripts like jQuery, a far-future expires header means that browsers can go weeks or months between requests for a particular version of the asset.

Too much caching: Not always a good thing

With that performance difference in mind, it obviously makes sense to take full advantage of far-future caching for relatively static content like jQuery.

However, far-future caching isn’t without its drawbacks. The same mechanism that makes it great for performance can also be a troublemaker when you instruct browsers to aggressively cache content that is eventually updated.

Imagine what would happen if your site served up /scripts/jquery.js with an expires header indicating that it was cacheable for one year. That would be great for performance initially, but what happens when a newer version of jQuery is released?

If you replaced that same file with the new version of jQuery when it was released, browsers that had visited your site before the change would continue using their older, cached version of jQuery. Since the whole point of far-future caching is that browsers don’t need to check for a 304 “Not Modified”, browsers with older copies of the file would never know their cache was stale.

On the other hand, visitors with empty caches would download the newer version of the file from your server and then begin caching that revision of it for the one year expires period.

In other words, using a single URL for multiple versions of a well-cached script means you can never be sure that any two given users were viewing your page with the same version of that script. The only solutions are to decrease caching, which impacts performance, or use unique URLs for each version of the script.

So, how does that affect the Google CDN?

As you’re probably realizing, you can’t serve a constantly evolving library like jQuery from a single URL and use optimal expires headers. When you’re serving evolving content through a single URL, you have to make a choice between performance (longer browser cache invalidation) and reliability (quicker expiration so new versions roll out evenly).

Taking a look at the HTTP headers that the Google CDN sends back with the 1.8 and 1.8.0 URLs, you can see that they choose a point dramatically on the reliability end of that spectrum.

“Latest Version”

First, let’s look at the “latest version” reference for jQuery 1.8.x. That’s the most recent minor revision of jQuery as I’m writing this and a reference to 1.8 returns a copy of jQuery 1.8.0.

Looking in the network section of Chrome’s developer tools, these are the HTTP headers returned with a “latest version” request to the CDN:

In an attempt to minimize inconsistencies when a new version (like 1.8.1) rolls out, the 1.8 reference is served with a meager 3,600 second cache expiration. That’s just one hour of caching.

The Cache-Control header returned with the “latest version” response even bolsters that conservative cache timeout with additional revalidate directives. Those directives instruct intermediate agents like caching proxies that they should not attempt to cache this resource more aggressively than stated.

Fully qualified

Now, let’s request exactly the same jQuery 1.8.0 content, but use the fully qualified 1.8.0 URL:

Since requests to this URL will never return different content in the future, the CDN safely instructs the browser that it can continue using this same copy of the file for up to 31,536,000 seconds. If you don’t have a calculator handy, that’s one full year, or 8,760 times longer than the “latest version” URL.

Conclusion

One of the greatest strengths of using a popular public CDN to serve jQuery is that your users may already have the library cached as a result of visiting another site that references the same URL your site does. When you use the “latest version” reference, you almost completely eliminate that possibility. The chances of a cross-site cache hit within one year are great. Within one hour? Good luck.

Clever as the “latest version” feature might seem at first, you should never use one of these partial version references in production.

In closing, I hope that I’ve convinced you just how important it is to use a fully qualified references to scripts on the Google CDN. Go forth and enjoy the best caching possible!

You've been reading The crucial .0 in Google CDN references to jQuery 1.x.0, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

Taking advantage of HTML5 in real-world sites and applications can be a daunting proposition. Though modern browsers are implementing HTML5′s new features at a rapid pace, few of us are lucky enough to write applications supporting only the latest crop of browsers. As a professional web developer, that browser fragmentation forces you to spend significant effort navigating the uncomfortable space between the promise of the future and the realities of the present. The good news is that Internet Explorer 10 and 9 support HTML5. Users are also leaving older versions of Internet Explorer. But the share of older versions is likely to remain just enough for developers to support in the foreseeable future.

However, that doesn’t mean you have to give up on supporting HTML5 in the near term. Just as there are techniques for a site to gracefully support variances like multiple screen sizes and different levels of CSS capability, it’s also possible to achieve surprisingly robust cross-browser HTML5 support. Even though older browsers lack many of HTML5’s new APIs, JavaScript is an incredibly flexible language and exposes opportunities to retroactively add new features when they aren’t natively present.

Continue reading HTML5 Now: Getting More Through Polyfills on MSDN »

You've been reading Read my article about HTML5 Polyfills on Script Junkie, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

It’s more of an open-ended conversation than us talking about the details of a particular technology. So, we’d both welcome you joining the conversation in the comments there on Scott’s post.

Click here to head over to the Hanselminutes website, give it a listen, and let us know what you think.

You've been reading Scott Hanselman and I talk about Web APIs, #!, and more, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

Manually firing a click on the collapsible div element is one option, as if the user had tapped it. I’ve never been a fan of that approach though, and especially not in frontend JavaScript. Co-mingling your internal flow control with events that are intended to be triggered by user input is a good way to find yourself with inconsistent issues that are difficult to reproduce and track down.

More importantly, I needed to control whether the widget was expanded or collapsed in this case. So, I really wanted to find a clean way to deterministically open and close the collapsible instead of toggling it. Luckily, there turned out to be an easy, straightforward way to do that.

Looking under the hood

A nice thing about interpreted languages like JavaScript is that it’s easy to take a look at the source for a library you’re using and find undocumented behaviors when these situations arise. For example, here’s the relevant source for jQuery Mobile’s collapsible widget (as of version 1.1):

.bind( "expand collapse", function( event ) {
  if ( !event.isDefaultPrevented() ) {
 
    event.preventDefault();
 
    var $this = $( this ),
      isCollapse = ( event.type === "collapse" ),
        contentTheme = o.contentTheme;
 
    // Lots of CSS style toggling omitted here.
  }
})

The CSS toggling in that event handler is less important than how that handler is triggered. Seeing that the widget bound a couple custom events named “expand” and “collapse”, it seemed logical that using jQuery’s trigger method on the collapsible div might have the same effect.

To test that the solution is really that simple, you can open a page with a collapsible and experiment from that browser’s JavaScript console. That approach is great for testing JavaScript ideas in any browser, but I used Chrome since it’s based on the same rendering engine that my jQuery Mobile site was targeting.

Sure enough, selecting a collapsible div and chaining .trigger('expand') or .trigger('collapse') opened and closed the widget just as if a user had clicked on the collapsible’s heading.

Pulling the “trigger”

To give you a more concrete example of how that works, here’s an excerpt of a simple jQuery Mobile page with two collapsibles on it:

<div id="collapsible1" data-role="collapsable">
  <p>Collapsible 1</p>
</div>
 
<div id="collapsible2" data-role="collapsible">
  <p>Collapsible 2</p>
</div>

Given those two widgets, you could use this JavaScript to select the first one and ensure that it’s expanded:

$('#collapsible1').trigger('expand');

Similarly, you could use this code to force the second one to be collapsed:

$('#collapsible2').trigger('collapse');

Nice and easy. Now we have complete control over the collapsible instead of being limited to a toggle operation.

Of course, since this is an undocumented behavior, there’s no guarantee this will continue working in future versions of jQuery Mobile. However, it seems straightforward enough that it’s unlikely to change in the near future.

You've been reading Expand and collapse jQuery Mobile collapsibles from code, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.

ASP.NET Web API – Why is it so cool?

That’s a great question.

Too many of the answers to that question come down to subjective, personal preference. Worse, you’ll often hear that it’s what you should use simply because it’s the new thing Microsoft is pushing (you know, like WCF once was). If you’re already making good use of ASP.NET MVC’s controller actions as a makeshift API, just hearing that Web API is “better” might not be all that compelling.

However, I think Web API objectively wins out over MVC controller APIs in a few key areas. In this post, I’ll cover why these three aspects of ASP.NET Web API make it a clear choice for my ASP.NET-based APIs going forward:

• Content negotiation
• Flexibility
• Separation of concerns

Content negotiation

Content negotiation is one of those features that can seem overwrought at first glance. The technical demos we’ve seen most often, returning content like images and vcards based on the Accept header, are neat, but not something you’re likely to need on a daily basis.

However, content negotiation is still a nice feature even if you only expect to return a single type of serialization. Why? Because it decouples your API code’s intent from the mechanics of serialization.

For example, which would you rather write and maintain?

ASP.NET MVC

public class TweetsController : Controller {
  // GET: /Tweets/
  [HttpGet]
  public ActionResult Index() {
    return Json(Twitter.GetTweets(), JsonRequestBehavior.AllowGet);
  }
}

ASP.NET Web API

public class TweetsController : ApiController {
  // GET: /Api/Tweets/
  public List<Tweet> Get() {
    return Twitter.GetTweets();
  }
}

The choice between those two options is an easy one for me. Not only is the return value of List<Tweet> more expressive (especially when you revisit this code in a year or two), but letting Web API handle the serialization means you don’t need to clutter the action up with the Json() code.

Of course, you never know when it might be helpful someday for that same endpoint to support returning its data as XML, CSV, MessagePack, or some future serialization format. Content negotiation makes adding that across an entire API relatively simple with Web API, but it would be cumbersome to update a plethora of MVC controller actions.

Flexibility

It’s clear that flexibility was a central goal in Web API (without resorting to the configuration tedium that burdened WCF). Content negotiation is a great example of that, but that’s only the beginning. Web API starts with sensible defaults, but then provides a GlobalConfiguration object that you can use to tweak a wide range of options.

A couple more concrete examples:

Down with XML!

One initially disconcerting thing about Web API is that hitting an endpoint in your browser will result in an XML response. That’s correct behavior because regular requests in browsers usually send an Accept header preferring text/html and application/xml, but not JSON.

If you want to bring Web API’s behavior more in line with the output of MVC’s Json() helper, you can remove XML support from your API entirely. Just add this to the Application_Start event and you’ll never see XML again:

// Normally, you'd probably be doing this in a setup method that
// accepts the configuration as a parameter and this line wouldn't
// be necessary, but you can do it right in Application_Start too.
var config = GlobalConfiguration.Configuration;
 
config.Formatters.Remove(config.Formatters.XmlFormatter);

Now, even if a client’s Accept header prefers XML over JSON, Web API won’t respond with XML. Personally, I’d prefer to see Web API prefer JSON over XML by default, but it’s great that Web API is flexible enough to allow these global changes with a minimum of configuration ceremony.

Tweaking your API’s JSON format

You’re generally stuck with the JSON that JavaScriptSerializer wants to generate when you use MVC’s Json() helper. Luckily, JSS does a pretty good job of creating sane JSON, but it also opts you into some unusual conventions like “MSAjax” date encoding instead of the more common ISO format.

Web API and Json.NET allow you to tweak the JSON that your API produces very easily. For example, Json.NET defaults to using ISO dates, but you can switch that to the Microsoft format for backwards compatibility across your entire API with a simple configuration setting:

// Separate statements for purposes of fitting within my tiny
// 492px code blocks. You could do this on one line if you wanted.
var js = GlobalConfiguration.Configuration.Formatters.JsonFormatter;
 
var dfh = js.SerializerSettings.DateFormatHandling;
 
dfh = Newtonsoft.Json.DateFormatHandling.MicrosoftDateFormat;

There’s a wide range of options you can set this way, from “pretty printing” the JSON to support for automatic translation between camelCase and PascalCase. For more examples, see this article on the ASP.NET site.

Separation of concerns

All of the preceding examples highlight one of my favorite overall advantages of using Web API. It’s possible to quickly drop these high-impact changes in across an entire API largely because Web API helps separate your API from the part of your project that returns HTML.

MVC controller actions are optimized for building up an HTML document through the use of things like views, partial views, and HTML helpers. That whole pipeline doesn’t really make sense in the context of an API that returns entities, DTOs, or ViewModels, and I think it’s valuable to keep them separate.

So separate, it’s not tied to a website at all

In fact, you may eventually want to isolate API from your website to the point that it doesn’t even make sense to host the API within the same project. With Web API, you can self-host the same API code in a Windows Service or even a console app.

You could do that with an ASP.NET MVC “API” by creating a separate project for the API, but then you’re still paying the performance penalty for your API requests to filter through MVC’s rendering pipeline. In simple load testing on my local machine, I’ve found that Web API endpoints hosted in console apps are nearly 50% faster than both ASP.NET controller actions and Web API endpoints hosted within MVC projects.

It’s great to have that low-cost, high-performance option as usage of your API grows. Starting with Web API means you’re not tied to ASP.NET MVC (or any web framework) in the future. It’s quick and easy to migrate an MVC-hosted Web API to a centralized project of its own as your needs organically grow.

Conclusion

These are the three main reasons why I’m using Web API controllers for client-side callbacks in my ASP.NET MVC projects going forward. Even though many of those “APIs” will never grow into more than endpoints for AJAX callbacks, using Web API for those endpoints is still easier and more flexible than other built-in alternatives.

What do you think? Are you using Web API yet? Do you plan to migrate from MVC controller actions to Web API in the future? Did I miss an aspect of the MVC-centric approach that makes it work better than Web API for you (I can think of one, but I haven’t seen many projects actually doing this in the real-world anymore)?

You've been reading ASP.NET Web API vs. ASP.NET MVC “APIs”, originally posted at Encosia. I hope you enjoyed it, and thanks for reading.

If you've got any feedback, please click through and leave a comment; I'd love to hear from you. You can click here to jump directly to the comment section of this post.