Development vs deployment

Sorry to be banging this drum so consistently, but I’m not sure why this new “Apple will rule JavaScript!” meme is so big.

Ryan Carson has an essay on how different methods of creating JavaScript will somehow transcend the browser they run in. Here’s a sample snippet from up top:

Right now, people are generally building web apps with CSS, HTML, a sprinkling of AJAX and their framework of choice (Rails, Django, Symfony, etc). The basic client-server model still dominates.

Objective-J and SproutCore change all that. They allow you to create true desktop-like apps right inside the browser. They don’t rely on a continous web connection and they are as quick as desktop apps. In fact, if you run them inside a site specific browser like Fluid, you probably would think they were real native desktop apps.

Everyone already generally agrees that we’ll see a melding of the desktop and the browser, but Objective-J and SproutCore are the first solid step in this direction. They’ve abstracted away all the basics so developers don’t have to re-invent the wheel for every web app they build.

But… you still end up with JavaScript, running in the various browsers. I agree with many of the comments at the cover article from Dion Almaer, who ask what’s new about this. Being able to develop with Objective-C-like constructs doesn’t change the final runtime experience at all.

It’s reminiscent of many of the Silverlight discussions a year or so ago, where the focus was on porting someone’s habits with Visual Studio, while silently ignoring the increased enduser participation costs.

You first calculate deployment costs to figure whether a project’s worth doing. If so, then you look at development costs and figure the best way to build it. You don’t start out by just focusing on what you can build and then doing it… you look at what needs doing, then how you might best do it. (That “lookit what icando!” approach leads to skip-intro-itis, “looks best in IE” and other problems.)

I keep re-reading these pieces, in hopes of finding some nugget that will suddenly turn the whole discussion sensible. The closest I’ve got so far is that this whole SproutCore discussion promises existing Mac-only developers a way to get to cross-OS delivery, similar to how Silverlight offered a way for investors in .NET a way to reach the wider world. Maybe this whole topic pits Mac-desktop devs against JavaScript devs. That’s a weak hypothesis, but it’s the most plausible I’ve seen so far.

There are some basic realities, some very simple concepts which many of the lengthy essays ignore:

  • A content transaction is based on a creator and audience agreeing with each other. It’s not just what the creator wants to do, and (contra PCF) not just what each audience member might want to do either. It’s what both can agree on, together. Ignoring enduser costs and only trumpeting development costs is silly.
  • Defining the format and then soliciting implementations (the HTML path, eg) is a useful strategy. But it’s not the only strategy the ecology needs. Providing a predictable capability is also useful, particularly if that predictable capability can be universally deployed. It’s easier to test atop one engine than eight.
  • Similarly, one runtime engine will grow faster and more consistently than will the set of engines attempting to implement a predefined standard. 8-bit alpha support in images is a good example… depending on your audience’s choices for IE6, you may still not be able to rely on it, even a decade after the first web implementations.

Google Gears has a little bit of hype attached to it… it has a potential, but that potential would be clearer once we see an actual deployment path. The HTML 5 VIDEO tag has much hype attached to it, because of the continued avoidance of the question of codecs and production workflows (there has been a little acknowledgment recently, thankfully). But this recent spate of Apple-aligned commentary seems to beat them all.

It’s still just JavaScript, folks. You’ve got to look at what it can do, realistically. No slamming of it, because I believe JavaScript is useful technology. But the sooner we cut down on the hype, the sooner we can get some real communication going.

Comments are closed.