The Problem with Native JavaScript APIs by Nicholas C. Zakas

Author:Nicholas C. Zakas [Nicholas C. Zakas]
Language: eng
Format: epub, mobi, pdf
Tags: COMPUTERS / Programming Languages / JavaScript
ISBN: 9781449339951
Publisher: O'Reilly Media
Published: 2012-07-19T04:00:00+00:00

Facades and Polyfills

A facade is a design pattern that creates a different interface for a feature. The goal of a facade is to abstract away some underlying interface so that you don’t need to access it directly. All of your interaction goes through the facade, which allows you to manipulate the operation of the underlying functionality as necessary. There’s nothing magical about a facade. If you’ve ever used jQuery or YUI, then you’ve used facades.

Polyfills (aka shims) are a bit different. A polyfill tries to implement a native API directly. Paul Irish attempted to create a polyfill for matchMedia(), defining his own function with that name if one didn’t already exist. There are other polyfills that you’re probably familiar with, such as Modernizr, that seek to fill in other pieces of missing functionality in the browser.

When there’s a choice between facades and polyfills, I always choose the facade. The reason is that polyfills suffer from the same downsides as native APIs. They represent yet another implementation of the same functionality. The big problem for polyfills is determining which implementation to follow. Taking the matchMedia() method as an example: which of the two strange bugs will the polyfill mimic? Again, the goal is to have your application logic completely free of browser-specific code. Accessing matchMedia() directly from your application logic assumes that it works the same everywhere, but in fact, it would behave in at least three different ways: the Firefox way, the WebKit way, and the polyfill way. Polyfills just don’t give you enough protection from underlying browser differences.

On the other hand, using a facade allows you to completely abstract away the browser differences from your application code. The facade doesn’t even need the same method signature or objects; it just needs to provide the same functionality. I wrote a matchMedia() facade as a YUI module so that I could use it in my application. It’s quite different from the native version, which allowed me to work around the various browser bugs to get a consistent experience. Here’s how it would look in your application code:

YUI({ //Last Gallery Build of this module gallery: 'gallery-2012.01.18-21-09' }).use('gallery-media', function(Y) { //detect current media state console.log(Y.Media.matches("screen and (max-width:600px)")); //subscribe to change in media state Y.Media.on("screen and (max-width:600px)", function(result) { console.log(result.media + " now " + (result.matches ? "matches" : "doesn't match")); }); });

In some cases, a facade may end up implementing a feature that doesn’t exist (as I did in this example), which makes it seem more like a polyfill. The difference is that a polyfill implements an already-existing interface while a facade is implementing the functionality without the interface. The latter is much easier to deal with in the long term since there aren’t synchronization issues.

Facades give you a big advantage in keeping your code maintainable and ensuring your application logic doesn’t need to know which browser is being used.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.