Despite the marketing efforts of Adobe, Microsoft, Sun, and other RIA toolkit vendors to generate a level of RIA hype that echos the client Java excitement of the mid 90s or the thin client enthusiasm of the late 90s, RIAs haven’t really taken on the world by storm. Instead, Flash, Silverlight and other proprietary tools and their required runtime plugins are all still aiming at some future date when they can claim the status of being the platform monopoly in RIA development.
However, many of the most popular rich web apps today are from Google, including Maps, Reader, Docs, and Sheets. Google’s rich web apps take on Microsoft Office desktop apps without even needing Flash, Silverlight, or Java. Instead, Google simply uses open web standards: HTML, JavaScript, and CSS. If Google’s leading rich web apps avoid using those proprietary plugins, why should anyone else resort to using Flash or something similar?
Google’s frequent partner Apple has been thinking along the same lines, scrubbing its website of all unnecessary Flash elements and building everything in those same open web standards: HTML, JavaScript, and CSS.
The Challenge of Funding Open Tools Development.
One might think that all web developers would flock to free and open solutions rather than selling themselves into slavery to a propriety web-like platform such as Flash or Silverlight. After all, once they’re dependent upon those runtimes, the power will lie with Adobe and/or Microsoft and competitive pressures to improve those tools will dry up, just as Windows and Internet Explorer flatlined after reaching their monopoly critical mass.
Of course, one might also think that PC makers would embrace free and open Linux, but that largely hasn’t happened either, for many of the same reasons. The problem in both cases is that open web standards don’t directly make anyone rich. Nobody owns them, so as with Linux, nobody can make much of a business model out of investing development efforts into improving them… unless they do so indirectly or for indirectly strategic purposes, as RedHat and IBM do in profiting from sales Linux related services.
Indirect strategies explain why both Google and Apple share the same strong affinity for an open web, in contrast to more short sighted developers would would blindly shackle themselves to Flash or Silverlight simply because those tools might help them accomplish their immediate objectives without too much effort.
Why Google and Apple Want an Open Web.
Google is investing in standards-based tools for web development because it wants an open Internet; Google needs an open web because it can’t compete and sell ads if Adobe or Microsoft infect the open web with proprietary Flash or Silverlight plugins and subsequently convert web content into opaque binaries instead of open HTML.
Apple doesn’t sell ads, it sells hardware. But if the web requires Flash or Silverlight to run, Adobe or Microsoft can either intentionally kill alternative platforms like the Mac (or Linux), or simply make them work so poorly due to their own incompetence that those platforms risk becoming non-viable. Adobe has already proven its incompetence in delivering Flash for the Mac (and really any platform outside of Windows), and I shouldn’t need to recap Microsoft’s historical readiness to destroy anything that isn’t Windows.
And so Google and Apple are bound together by different interests that happen to converge: Google wants the web open so it can sell ads, while Apple needs it open so it can sell hardware that browses the web well. Currently, the two companies are both working to achieve these goals in independent, often complementary ways.
Google’s API Inexperience.
Google introduced its Google Gears as a mechanism for beefing up rich web apps with offline storage. However, Google’s API development experience is really limited to exposing access to its web services such as Maps, Gmail, and others. Google Gears, Android, and the company’s other efforts to deliver significant new platform APIs are still unproven.
An an example, Google’s progress in delivering the Android SDK, while introduced back in November 2007, has been eclipsed by Apple’s iPhone SDK both in release cycles and in sophistication and polish since its debut in February 2008.
Another problem for Google is that it doesn’t have a large and committed user base. Google has contributed a lot code to the community, but that doesn’t mean that the community will necessarily use it.
The Apple of Your API.
In contrast, Apple has very strong and mature development tools and platform frameworks that have been proven in the marketplace for many years and are widely adopted in the markets Apple competes in.
Apple originated the first mainstream graphical platform with the Mac. That model subsequently served as the basis for Microsoft’s Windows, which grew into popularity as Apple lost itself in the conundrum of Copland in the early 90s.
Apple employees who left in the late 80s to form NeXT created the first mainstream object oriented platform frameworks, again establishing the standard that the rest of the industry would aspire to clone or use as a reference to develop upon. Apple and IBM’s Taligent, Sun’s Java, and Microsoft’s unfinished Cairo all intended to ship something that NeXT already had in production use among high profile clients.
Apple’s API Philosophy.
After the remains of the old Apple acquired NeXT in 1996 and began work on Mac OS X, the company worked to continually develop and refine its desktop APIs using a unique philosophy that focuses upon:
* enabling features
* abstaining from developing unnecessary APIs
* iterating over code to refine it
* and delivering quality over quantity.
Apple’s emphasis on code quality and elegance in the API has allowed Apple to move faster than Microsoft over the last decade while also preventing Apple from having to painfully revisit major legacy problems resulting from sloppy coding and poor planning. That in turn has rebuilt Apple’s reputation in API development following its mid 90s Copland disaster.
Despite having a significant following of developers behind its desktop platform, Apple hasn’t begun resting on past performance. With the iPhone, Apple didn’t just directly port its desktop Cocoa API, but took the opportunity to refine and rethink how things should work given an entirely new set of circumstances and the opportunity to start fresh. As cited by the Apple document “iPhone Getting Started Docs,”
“One of the biggest differences is the extensive use of properties throughout the UIKit class declarations. Properties were introduced to Mac OS X in version 10.5 and thus came along after the creation of many classes in the AppKit framework. Rather than simply mimic the same getter and setter methods in AppKit, UIKit employs properties as a way to simplify the class interfaces. For information about properties, see Properties in The Objective-C 2.0 Programming Language.”
Apple’s Cocoa Flavored Open Web.
The company is now pushing Cocoa-inspired development outside of Mac OS X and the iPhone to a broader scope: the web. Apple has already demonstrated its ability to deliver rich web applications with the kind of direct interaction and offline state features normally associated with desktop apps in .Mac Web Gallery, which debuted last fall. After experimenting with a variety of JavaScript framework helper tools to do this, Apple put its resources behind SproutCore.
That has not only allowed Apple to advance its own rich web apps using open web standards, but also to share SproutCore, its Cocoa-inspired, cross platform JavaScript frameworks, under an open source MIT license. That sharing will help provide an open alternative to Flash in the RIA space. SproutCore doesn’t compete against the use of Flash to make animated ads or navigation applets, but rather in deploying full, highly interactive applications, the target of Adobe’s Flash-based AIR platform plans.
One of the biggest announcements of WWDC was Mobile Me, a rebranding of .Mac that aligns it with the iPhone and cross platform users. Apple added a new web calendar and contacts, and a revised Mail and iDisk online file manager modeled after the Finder. The Gallery component of Mobile Me is an update of the existing .Mac version of Web Gallery, which was built using an earlier version of SproutCore.
Charles Jolley’s SproutCore.
The SproutCore JavaScript framework was developed outside of Apple by Charles Jolley, originally to create an online email manager called Mailroom. Apple hired Jolley as part of its .Mac team and collaborated to rapidly improve upon his framework.
SproutCore not only makes it easy to build real applications for the web using menus, toolbars, drag and drop support, and foreign language localization, but it also provides a full Model View Controller application stack like Rails (and Cocoa), with bindings, key value observing, and view controls. It also exposes the latent features of JavaScript, including late binding, closures, and lambda functions. Developers will also appreciate tools for code documentation generation, fixtures, and unit testing.
A key component of its clean MVC philosophy that roots SproutCore into Cocoa goodness is bindings, which allows developers to write JavaScript that automatically runs any time a property value changes. With bindings, very complex applications with highly consistent behavior can be created with very little “glue” code.
Cocoa Bindings Programming Topics: What Are Cocoa Bindings?
That makes SproutCore a light Cocoa alternative for deploying web apps that look and feel like Mac OS X desktop apps. At WWDC, Dr. Michael B Johnson of Pixar gave a lunchtime presentation where he pointed out that if you don’t need 64-bit addressing, multithreading, or other desktop-only features, it makes a lot of sense to deploy apps using the web.
But aren’t web apps awful? They historically have been, particularly in the days when every server response required a page load. The development of Ajax technologies, which allow the current page to draw new data from the server asynchronously in the background, has helped. Modern Ajax websites such as Flickr offer drag and drop features, and Google’s use of Ajax in its web apps has made them more desktop-like, but web apps are often well behind those designed for the desktop in terms of a usable interface.
SproutCore helps push things forward; it keeps rich interaction local within the user’s browser and supports offline functionality, making web apps behave more like desktop apps and less like the constantly reloading HTML pages that users dislike. They also look like desktop apps, and in particular can look like Mac OS X desktop apps.
The SproutCore framework also solves a lot of problems for web developers. It takes care of browser incompatibility issues to run cross-platform in Safari, Firefox, or Internet Explorer 6/7. It also makes it easy to leverage the fancy CSS features of modern browsers.
A Front End to WebObjects, WebDAV.
SproutCore also delivers the premise of thin client computing, where applications all run remotely from a back end server and therefore don’t need to be installed or managed on every client.
The disadvantage of thin client apps is that they have typically offered minimal functionality due to the weaknesses in thin platforms such as the web. SproutCore solves this by relying on modern web browser features, which are now sophisticated enough to enable thick client web apps.
SproutCore web apps also combine the power and flexibility of web services with the advantages of client-server computing, prompting Apple to refer to the new model as “web client - server.” In Mobile Me, its new web apps tie into web services vended by WebObjects and WebDAV servers, but anyone can build SproutCore web apps that tie into PHP or any other existing servers that offer up data in XML or JSON objects.
Cocoa and the Death of Yellow Box and Rhapsody
If you were waiting for the resurrection of Yellow Box or Cocoa for Windows, stop waiting and start coding. SproutCore brings the values of Leopard’s Cocoa to the web, domesticating JavaScript into a functional application platform with lots of free built-in support for desktop features.
Being based on open web standards and being open source itself means SproutCore will enable developers to develop cross platform applications without being tied to either a plugin architecture or its vendor.
Sitting on top of web standards will also make it easy for Apple and the community to push SproutCore ahead without worrying about incompatible changes to the underlying layers of Windows, a significant problem for the old Yellow Box or some new Cocoa analog. SproutCore also lives in a well known security context, preventing worries about unknown holes being opened up by a new runtime layer.
Make Apple SaaS.
All of this advances some interesting new potentials. Apple already has a silent lead in the consumer “Software as a Service” market with .Mac; While Google, Yahoo, and MSN have built models around pushing ads to fund their online mail, photos, and other applications, Apple has been quite unique in being actually able to sell its .Mac service to subscribers. Everybody wants to do what Apple is actually doing.
Mobile Me will retarget .Mac to also serve iPhone users, greatly widening its potential audience and putting Apple’s Mac OS X apps in front of a lot of Windows users. In the future, Apple will undoubtedly add new apps to its Mobile Me suite. Will it get into the online Office race with SproutCore versions of its iWork apps, available to both Mac and Windows users? How about an expanded Back to My Mac, with direct home file sharing and VNC Screen Sharing services available over the web?
And what about third parties? Surely there are enterprising developers who’d like to get in on the Mobile Me platform. Apple should consider hosting third party web apps, either bundled as part of the service (and making Mobile Me more valuable) or as additional apps users can subscribe to for a small additional cost. Imagine a Mobile Me version of QuickBooks that offered similar direct web access and mobile push sync with the iPhone.
The WebApps Store.
Web developers have often found it rather impossible to sell their services, but Apple can solve this problem just as it is solving the same problem in mobile software. By offering the equivalent of an iPhone Apps Store within Mobile Me, Apple could create a viable subscription market for web apps and web services that worked like an extension of iTunes. In fact, Apple could add a WebKit view in iTunes and use it to display Mobile Me apps to a wide audience, tied right into iTunes for billing.
Of course, Apple doesn’t need the iTunes infrastructure to sell web apps, as it also has Safari for Windows and its apps also run in Firefox or Internet Explorer. If you thought the Apps Store was interesting, a market inside of Mobile Me should really get interesting.
With everyone clamoring over Facebook for offering Flash-like applets as a free service in the high turnover, profitless profile market, perhaps Apple’s ability to serve real applications and web services as a paid service to its highly loyal users who are driving record profits will get some attention, too.
No comments:
Post a Comment