Mike Coyle’s Weblog

If you follow web technology news, you may have seen a number of postings about SproutCore over the last couple of weeks. SproutCore is the framework that Apple’s using for their MobileMe applications.

The “sync-all-your-devices-to-the-cloud” functionality is MobileMe’s core value proposition. The beautiful and rich web client experience is icing on the cake, and could have been implemented using a half-dozen existing JavaScript libraries.

Therefore, my intitial reaction to these “Cocoa apps for the Web” and “Flash Killer” reviews was that the revolutionary-ness of SproutCore was definitely overblown.

I figured that the hype would be over in a couple of days. Since articles like Why Objective-J, Cappuccino and SproutCore are completely changing the web app industry are still cropping up all over the place, I figured that I’ll weigh in on the discussion. I hesitated because I think that the techniques in question are very clever. Just not “Completely-Change-The-World-As-We-Know-It-Forever” clever

I’ll hedge a bit here here by saying that all bets are off if Apple leverages technologies like these to allow Cocoa developers to use Interface Builder and XCode to build web apps and/or build special stuff into Safari to natively render SproutCore markup as native Cocoa. But at the current time, I think that the hype machine is in overdrive.

SproutCore and Cappucccino extend Cocoa concepts such as Key-Value Coding (KVC) and Key-Value Observing (KVO), and it’s great to see these ideas brought to the world of web development in a big way. But I think that SproutCore and similar frameworks will have limited long term appeal to the broad web technology marketplace, considered niche players alongside the Java-based Google Web Toolkit (GWT). Methinks that web app architectures that rely on code generation will have limited appeal moving forward.

Keep in mind that I’m not anti-niche: Creating the framework that powers Apple’s MobileMe apps by itself is quite the accomplishment, and their approach is both novel and effective. I’m simply making the case that web app development in the large is not likely to follow MobileMe’s direction from a client engineering perspective.

I think that if we fast-forward the clock by a few months, we’ll see a backlash against these SproutCore-like frameworks, since they go against the grain of traditional web development approaches. Instead, they’ll be a call for a return to The Idiomatic Web, where semantic markup, stylesheets, and good JavaScript are top-tier building blocks, not simply implementation details below a new set of alternate client architecture abstractions.

The real widespread change will come to web app development when KVO/KVC approaches are employed in conjunction with idiomatic web frameworks like YUI.

When staking out the future of the Web, Evolution rather than Revolution will rule the day.

Don Dodge has an interesting analysis of Ray Ozzie’s recent Tech•Ed speech.

I think that there will be four key drivers of this movement back to the client/server world, none of which involve dusting off your old PowerBuilder books (not that there’s anything wrong with that):

1. Tools like the iTunes Music Store and (our very own) ProjectPipe.com will leverage and blend web technologies and existing desktop infrastructure, so that the underlying, infrastructure-spanning solution “just works”.
2. A platform for desktop-level, consumer-friendly “mashup”-type applications, that glue together RSS feeds, web services, and local data in interesting and useful ways. This will probably be some sort of Firefox extension.
3. Microsoft Live, and the ecosystem that springs up around it.
4. The movement toward desktop web applications. I think that two factors will drive this:
• The continued growth of rapid web dev frameworks, such as TurboGears and Ruby on Rails, which increases the supply-side (i.e. developers, ISVs) opportunity cost of not using one of these frameworks when building an application.
• The maturity and growing popularity of embedded databases such as Sqlite, which considerably simplifies the deployment footprint for such applications.

Don states that “The seamless, blended, client-server-services approach makes intuitive sense.” I couldn’t agree more. This was one of the core problems that we set out to solve in ProjectPipe, since so much project activity occurs on the desktop, yet so much collaboration occurs over the Internet.

We’ve referred to this blend of “Thin Client” (web) and “Thick Client” (client/server) as our Right Client Architecture, where we let the user pick the right tool for the job, and we figure out how to do the integration. For a real-world example, read about how ProjectPipe integrates with MS Project and Excel.

Venture Chronicles mentions that the current Thin Client debate going on between two columnists (Mark Hall and Frank Hayes) at Computerworld looks like it was ripped from the pages of a 1999 edition.

Both thin and thick client approaches have their relative merits and downsides. At Botonomy, our applications (such as ProjectPipe) are built around a hybrid concept that we call the Right Client Architecture.

Our Right Client approach has three core tenets:

• Make the basic functionality as thin as possible (i.e. browser-based), and provide “Thickness” for a small set of high-value functions or services via local desktop software
• Where possible, leverage existing apps that the user already understands for Thick client capabilities. In many cases, this happens to be Microsoft Office (Excel, Word, Project, etc.)
• Let the user pick the right tool for the job, with the understanding that the user experience will vary by platform

We believe that this is a very compelling vision for computing across heterogeneous platforms (Windows, Macs, Palm, Phones, etc.) because we’re not trying to convince users to trade the rich desktop tools that they’re used to using for crude web-based substitutes, nor are we sitting around waiting until the base model El Cheapo PDA screams like a Cray supercomputer that’s liquid cooled with Red Bull and provides a desktop-like experience in a pocket-size form factor.

We realize that all computing devices are not equal, and that this fundamental capabilities gap will not change anytime soon. Trying to provide user experience parity across diverse platforms is a losing proposition. In that game, the best you can be is mediocre. In our Right Client model, we lay out the options and let the user pick the right tool for the job.

Let’s take the case of managing issues in ProjectPipe. When I’m using a Mac, I can input issues through a web interface. However, if I’m on a Windows PC, I can input issues in an Excel spreadsheet and then, by clicking the “upload” link on the Issues web page, automagically load the issue data from my local spreadsheet to the centralized database.

[In case you’re wondering how it works, ProjectPipe employs a small client program that makes an XMPP (Jabber) connection between your desktop and our server farm. This local client runs in your Windows system tray and allows for seamless yet totally optional desktop integration with the rest of the browser-based application.]

If we wanted a pure-play Thin Client experience that was 100% cross-platform and 100% browser-based, the guy with an existing spreadsheet with a few dozen issues that need to be entered into web form is going to cut-and-paste his way through a very tedious afternoon.

Conversely, if we built ProjectPipe as a Thick Client app in Windows, then the MS Office integration would be a cakewalk, but all of our Mac and Linux users would be out of luck.

We believe that our Right Client approach strikes an attractive and flexible balance between the two extremes. While this approach may not fit some pundits’ view of computing utopia, it keeps the heavy lifting of our applications 95% server-side, while providing a rich desktop integration experience where necessary.

]]>

Really Simple Sharing.

In his post, Ray talks about the fact that many software packages don’t get the “mesh model” for data synchronization, and discusses the simple extensions to RSS that he and his team have put together (and published under a Creative Commons license) to assist in cross-product synchronization.

I have three thoughts on this subject:

First, I wholeheartedly agree with his observations about the industry not being tooled up to embrace a mesh model of data ownership and management.

As an industry, we have simply not designed our calendaring and directory software and services for this “mesh model”. The websites, services and servers we build seem to all want to be the “owner” and “publisher”; it’s really inconsistent with the model that made email so successful, and the loosely-coupled nature of the web.

There are so many cases where a vendor’s monolithic product works great, so long as you operate within their box. Integration with external systems is either difficult or unsupported. I’ve always felt that this is somewhat akin to these all-inclusive resorts located on very impoverished Carribbean islands: Everything is wonderful so long as you stay on this side of the razorwire fence.

This should turn out to be a short-term problem. Every day, we’re becoming more and more of a “mashup” world, where new things are created by combining old things in new ways. The ability to integrate is, in kind, crawling its way to the top of the required feature list for new products.

Second, I really like the fact that they’ve published SSE as a minimalist spec. The Extreme Programming crowd would probably consider this “The simplest thing that could possibly work.” To quote the FAQ:

SSE defines the minimum extensions necessary to enable loosely cooperating applications to use RSS as the basis for item sharing-that is, the bidirectional, asynchronous replication of new and changed items among two or more cross-subscribed feeds.

Third, while SSE is far from being “Groove for Syndicated Data” from a feature/functionality perpective, it’s safe to say that Ray, Jack, and the other folks involved have all thought about the problems involved in masterless, deterministic synchronization. Specifically, the problems that SSE doesn’t address are omitted from the spec by design rather than by naivete.

]]>