With the announcement of the iPad, the usual suspects have come out decrying a closed, proprietary, fully locked down system.

For instance, a story on the top of Hacker News today says:

This is what I asked in January 2007 on this site, shortly after the original iPhone was launched:

“1. Will Apple lock down the iPhone, blocking Flash, Java, custom widgets, and open development from its new platform?

2. Could Apple’s multi-touch patents actually stifle growth of new, interactive displays?”

Unfortunately, that turned out to prescient

And the FSF is out there calling this an unprecedented march of DRM:

With new tablet device, Apple’s Steve Jobs pushes unprecedented extension of DRM to a new class of general purpose computers

It’s a fair initial reaction. Apple didn’t build a general-purpose computer as its next entry into the market. Instead, they built a heavily proprietary, locked down device. In order to install an application onto the device, Apple must approve the application.

I don’t need to address the merits of the argument against how Apple handles native applications, because it’s irrelevant. A much, much larger force is at work here.

With the iPad, Apple has created two platforms. First, they have produced a heavily proprietary, native platform that requires Apple approval and has significant Apple restrictions. But ironically, with their heavy focus on improving the quality of Safari and the HTML standard, they have shipped the iPad with a platform based on open, unencumbered technologies.

If you haven’t been paying attention, over the past couple of years, the web platform has gotten offline APIs, improved caching support, local storage (on Safari, that includes an on-device SQLite database accessible through JavaScript), CSS-based animations, and custom, downloadable fonts. Mobile Safari has support for gestures, Geolocation, and hardware-accelerated graphics.

Additionally, Apple has remained at the forefront of these technologies, literally building some of them for mobile devices (hardware-accelerated animations were built for the iPhone, and by extension, the iPad). The Open Source Webkit project has remained extremely active, and in fact, has only accelerated progress since Apple first released its Native SDK, so Apple’s “locked down” strategy has a very carefully carved out intentional exception.

Apple even makes it easy to take a web app and put it on the home screen amongst normal apps. When you do this, the iPhone downloads all the assets in the HTML5 cache manifest to make the work better as an offline app. This is how I use Gmail on my iPhone (because Google knows what’s going on in this space, they leverage new tech in Safari quite well). When Apple rejected Google Voice, Google immediately built a Safari version of the app. The way they tell it:

Already, Google says it is readying a replacement for the Google Voice app that will offer exactly the same features as the rejected app—except that it will take the form of a specialized, iPhone-shaped Web page

Ironically, despite claims that not allowing Flash or Java represent a victory for proprietary technologies and a loss for open technologies, they represent quite the opposite. By restricting the web platform on the iPhone and iPad to open, patent-free, technologies, Apple has created a highly desirable market for pure-HTML5 apps. This is, frankly, a win for supporters of open technologies.

A couple of weeks ago I wrote a nice little piece of JS that implemented BDD-style testing in JS. It was originally 70 or so lines of code, and supported code like:

jspec.describe("Some stuff", function() {
  it("should rock", function() {
    7.should("==", 7);
  });
});

It was (and still is) a very simple piece of code, that only dumps the output to the Firebug console. Because should() was a simple method, I was able to delegate out to a pluggable jspec.matchers object, which is where I specified the “match” definition, and allowed the customization of a “failure message.” The original jspec had just two matchers (“==” and “include”), and allowed the creation of new ones by extending the jspec.matchers object (all JS, no magic).

When I tried to actually use it to test real-world code, though, some issues came up. First, functions were being dumped in full into the output, which was sucky. Secondly, the default describe syntax was sucking a bit for certain cases. And finally, I wanted you to be able to plug in any logger you wanted (for say, pretty HTML output). I added those new features, and am now releasing this quick and dirty code for people to look at.

Some examples

(which are included in the downloadable file)

jspec.describe("JSpec", function() {
  it("should support ==", function() {
    (1).should("==", 1);
    var arr = [];
    arr.should("==", arr);
    var obj = new Object;
    obj.should("==", obj);
    document.should("==", document);
  });

  it("should support include", function() {
    [1,2,3,4,5].should("include", 3);
    [1,2,3,4,5].should_not("include", 3);
    document.getElementsByTagName("div").should("include", document.getElementById("hello"))
  });

  it("should support exists", function() {
    document.should("exist");
  });

  jspec.matchers["have_tag_name"] = {
    describe: function(target, not) {
      return jspec.compress_lines(this) + " should " + (not ? "not " : "") + "have " + target + " as its tag name."
    },
    matches: function(target) {
      return (this.tagName && this.tagName == target) ? true : false;
    },
    failure_message: function(target, not) {
      return "Expected " + this.toString() + (not ? " not " : " ") + "to have " + target + " as its tag name," +
        " but was " + this.tagName;
    }
  };

  it("should support custom matchers", function() {
    document.getElementById("wrapper").should("have_tag_name", "DIV");
    document.getElementById("wrapper").should_not("have_tag_name", "SPAN");
    document.getElementById("wrapper").should("have_tag_name", "SPAN");
  });
});

And the Output

In Firebug

JSpec
  - should support ==
    - 1 should equal 1 (PASS)
    - [] should equal [] (PASS)
    - [object Object] should equal [object Object] (PASS)
    - [object HTMLDocument] should equal [object HTMLDocument] (PASS)
  - should support include
    - 1,2,3,4,5 should include 3 (PASS)
    - 1,2,3,4,5 should not include 3 (FAIL)
      Expected [[1,2,3,4,5]] not to include 3
    - [object HTMLCollection] should include [object HTMLDivElement] (PASS)
  - should support exists
    - [object HTMLDocument] should exist. (PASS)
  - should support custom matchers
    - [object HTMLDivElement] should have DIV as its tag name. (PASS)
    - [object HTMLDivElement] should not have SPAN as its tag name. (PASS)
    - [object HTMLDivElement] should have SPAN as its tag name. (FAIL)
      Expected [object HTMLDivElement] to have SPAN as its tag name, but was DIV

Some caveats

• Despite some work put in, I can’t figure out how to get jspec to recover gracefully from errors and continue on. This will work in a future release
• I temporarily override the Object prototype (evil, I know) for the duration of the test. You will still be able to load in libraries that expect Object to work correctly, but you will not be able to test functions (such as prototype’s Object.extend) without accounting for the fact that Object.prototype has been extended.

Happy hunting (Download here)

Update

There is now a git repo for the project at git.caboo.se/jspec.git