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.
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.)
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.