I’ve been receiving lots of emails asking my opinion about ASP.NET Web API lately. One of the most recent messages boiled them all down pretty well in its subject line:

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

Click here to read the rest of this post »

There’s a great article on the Internet Explorer team’s MSDN blog this week, Advances in JavaScript Performance in IE10 and Windows 8. I’ve been running Windows 8 as my primary OS for several weeks, and I must say (as bizarre as it feels to type these words), IE10 is incredibly fast and fluid. It’s almost like that first time you used Chrome after using Firefox with too many add-ons. Whatever they’re doing over there, it’s working.

The entire post was interesting, and you should probably read the whole thing if you’re a serious JavaScript developer. However, one point in particular stood out to me, regarding a new approach to deferred parsing:

The JSMeter project from Microsoft Research showed that typical Web pages use only a fraction of code that they download – generally on the order of 40-50%. Intuitively, this makes sense: developers often include popular JavaScript libraries like jQuery … but only leverage a fraction of the functionality the library supports.

To optimize such scenarios, Chakra performs only the most basic syntax-only parsing of the source code. The rest of the work (building the abstract syntax tree and generating bytecode) is performed one function at a time only when the function is about to be invoked. This strategy not only helps with the responsiveness of the browser when loading Web pages, but also reduces the memory footprint.

In IE9 there was one limitation of Chakra’s deferred parsing. Functions nested inside other functions had to be parsed immediately with their enclosing functions. This restriction proved important because many JavaScript libraries employ the so called “module pattern,” in which most of the library’s code is enclosed in a large function which is immediately executed. In IE10 we removed this restriction and Chakra now defers parsing and bytecode generation of any function that is not immediately executed.

Microsoft’s focus on real-world performance enhancement in IE9 and IE10 has been an under-appreciated breath of fresh air in the browser wars. Remember when everyone was competing to improve scores on synthetic JavaScript benchmarks instead of concentrating on actual on-page performance? I don’t miss those days.

If Microsoft would address the archaic extensibility model in Internet Explorer, I’d probably be using it to type this post right now. Given replacements for the dozen-ish essential extensions I use in Chrome, I could see myself being tempted to switch back to IE after ten years of Firefox and Chrome.

The landscape today is reminiscent of how things were shaping up just before so many of us began switching from Netscape to IE5/6, way back when. Never underestimate how fiercely Microsoft can compete and innovate when an entire division of the company commits to winning.

When it comes to extracting data from an HTML document on the server-side, Node.js is a fantastic option. Not so much because of any particular feature of Node itself, but because running JavaScript on the server also means that you can run jQuery on the server. Then, many of the techniques you’ve learned on the client-side are applicable on the server-side as well.

Typically, using jQuery on the server with Node is accomplished via a handy module called jsdom. Unfortunately, later versions of jsdom took a dependency on a module called contextify, and that choice has made jsdom not-so-friendly to those of us running Node.exe on Windows.

As I was jumping through the hoops to build contextify in Visual Studio, copy that binary back into my Node.exe project, and cross my fingers, I realized that maybe I’d become too fixated on jsdom as the only solution to this problem. After all, one of Node’s strengths is its thriving ecosystem of third-party libraries (reminiscent of the community that sprang up around jQuery itself several years ago).

Surely, there’s a Windows-friendly alternative to jsdom out there, right?

In this post, I’ll show you why jQuery on the server is useful, the alternative to jsdom that I found (Cheerio), and how to use Cheerio’s jQuery syntax to request and parse a remote HTML document.

Note: You don’t need to be a Windows user to benefit from Cheerio. Though jsdom impressively emulates how a browser might interpret an HTML document, at a much deeper level than most simple HTML parsers, that’s massive overkill in a lot of scenarios. In those simpler situations, jsdom carries a needless performance tax for that highly realistic simulation of the DOM.
Click here to read the rest of this post »

It’s probably an understatement to say that ASP.NET Web API has sparked a bit of debate about RESTful design lately.

Web API’s new features like content negotiation, flexible media formatters, and improved JSON formatter are great, but they’ve been presented as features that are tied to the REST paradigm. That may seem troubling if you’re more accustomed to .NET’s RPC endpoints like ASMX, WCF, and even the way ASP.NET MVC controller actions are often used as a makeshift API.

A couple months after the new incarnation of Web API was announced, I’m still seeing a lot of confusion and unhappiness about Web API’s apparent push toward REST. However, what almost everyone has overlooked so far is that Web API supports RPC just as well as REST.

Click here to read the rest of this post »

There’s been plenty of cynical talk going around about today’s news that Facebook is acquiring Instagram for $1 billion in cash and stock. One of the most salient points is the simple arithmetic on how much Facebook is paying for each of Instagram’s roughly 30 million users. With Facebook paying somewhere in the neighborhood of $33 per Instagram user, that seems fairly pricey compared to Facebook’s own valuation of roughly $120 per user.

What’s missing from that math is that Facebook users spend a huge amount of their time sharing and viewing photos. According to recent Comscore data, Facebook users are spending 17% of their time viewing photos on Facebook. Photos are incredibly important to Facebook.

Thinking of how I use Facebook and how I’ve seen others use it, I’d even make a case for the photos being a crucial part of drawing users into the remaining 83%.

Almost overnight, Instagram’s social network of photo enthusiasts gave it a solid beachhead into some 17% of Facebook’s social stronghold. Perhaps maybe even more importantly, Instagram is entirely focused on mobile (where Facebook sees its future). Maybe Instagram had no intention of ever competing head-to-head with Facebook, but I believe Instagram actually posed a greater potential threat than Google+ has yet.

Though it’s hard to fathom a $1 billion valuation for such a simple app and service, maybe that’s a reasonable price to quash potential competition to the unimaginable windfall that is Facebook. Facebook isn’t buying new users, but paying a premium to retain the union of Facebook and Instagram’s shared users and redirecting this aspect of their engagement back toward Facebook.

It’s been a few months since I began reviewing ASUS’ Zenbook UX31 based on day-to-day use, and it’s time to wrap the process up with a third and final post. The original plan for this series of reviews was that I’d write three posts about the Zenbook, finishing with one that summarized my experience using it regularly for a few months.

Unfortunately, the trouble I had with its keyboard sabotaged that plan. If you haven’t been following along, a month with the Zenbook’s keyboard was all I could endure. However, almost every other aspect of the UX31 put it solidly in the running as a successor to my MacBook Air.

Rather than ending on that sour note about the keyboard, this last post in the series will cover a few things that the Zenbook did well. So well, I’ll be looking for these features in whichever Ultrabook™ ultimately does replace my MacBook Air.

Click here to read the rest of this post »

The IE team published an in-depth post over the weekend, raising a few concerns about StatCounter’s methodology (or lack thereof) for reporting browser market share. Their points were interesting to consider, but one of them stood out to me:

You’ll notice some pretty big differences in the weighting of StatCounter versus Net Applications. First and foremost, the most populous country in the world, China, doesn’t make the top 20 for StatCounter, when in fact it represents the world’s largest internet population.

[...]

To further explore this problem, we re-ran the StatCounter numbers and weighted their publicly reported individual country browser share numbers by the CIA internet population data. This calculation would then represent a true country or geo-weighted view of worldwide browser data based on the actual world’s internet population.

It’s true that we should be wary of methodology issues that can creep into data extracted from analytics services that weren’t designed with aggregate statistics in mind. StatCounter’s data is often accepted at face value, without any detailed scrutiny. However, I believe this geo-weighting approach they’ve explored may be as flawed as the raw, unadjusted data itself.

Click here to read the rest of this post »

There’s been some confusing back and forth lately about ASP.NET Web API and JSON. During the time between the last WCF Web API preview and the current ASP.NET Web API beta, it’s clear that effort has gone into smoothing out some of DataContractJsonSerializer’s (DCJS) quirks. However, while things like DateTime and Enum deserialization have been improved, issues have still persisted with Anonymous Types, Dictionaries, and DateTime serialization.

Unfortunately, the underlying cause of those remaining issues was too fundamental to simply spackle over. One of the most frustrating aspects of DCJS is that it’s rooted in WCF’s mindset that all things can be expressed as XML and then translated to other formats. In that world, data like Anonymous Types and simple collections of key/value pairs are uninteresting oddities. So, as long as ASP.NET Web API is saddled with DCJS, it’s at a disadvantage in scenarios requiring more flexible JSON serialization.

Click here to read the rest of this post »

Note: If you haven’t read my initial impressions of the Zenbook, you might want to head over and read that first: The ASUS Zenbook UX31: Initial impressions

I’ve been using my ASUS Zenbook for just over a month at this point, and it’s time for a second review now that I’ve used it for a while on a day-to-day basis. I’ve heard from many of you about being eager to read the next installment in this process, so I’m glad to know that you’re finding this experiment useful too.

Click here to read the rest of this post »

There’s been a bit of controversy lately concerning the rising dominance of WebKit-based browsers (e.g. Chrome, Safari, and Mobile Safari) and the potential that we’re repeating past mistakes:

Not so long ago, IE6 was the over-dominant browser on the Web. Technically, the Web was full of works-only-in-IE6 web sites and the other browsers, the users were crying. IE6 is dead, this time is gone, and all browsers vendors including Microsoft itself rejoice. Gone? Not entirely… IE6 is gone, the problem is back.

However, I believe there’s one gigantic difference between IE6 then and WebKit now that’s being overlooked.

Microsoft put the brakes on Internet Explorer development after IE6 because they realized that they were helping build the runtime for their own competition. If Internet Explorer releases had continued at the same pace, most everyone would probably be using IE15 today and IE6 would be as memorable as Chrome 4 or Firefox 7.

Conversely, Google has a vested interest in Chrome’s ongoing success (and WebKit’s success by extension). Instead of threatening Google’s primary revenue stream, WebKit and Chrome serve to enhance Google’s golden goose. So, unlike the past situation with Microsoft, Netscape, and IE6, Google has no motivation whatsoever to shutter active development on Chrome and WebKit if it overtakes Internet Explorer and Firefox.

Does that make vendor prefixes and targeting experimental features a great idea? Maybe not. Frankly, I’m not qualified to speak intelligently about cutting edge CSS features.

What I do know is that just because the current climate seems similar to the one ten years ago, that doesn’t mean it’s reasonable to assume history is repeating.