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.

Google App Engine was announced last night. This is a service that allows you to write a web application in Python and deploy it to Google, where it can run atop Google’s uber-scalable infrastructure. Here is the transcript and video of the announcement, where Kevin Gibbs from Google explains the App Engine’s value proposition (Easy to use, Easy to scale, and Free to get started.)

Like most big announcements, it’s the most sensational aspects of the story that emerge first. But I think that the broader impact of Google App Engine is a fundamental rethinking of the relational database value proposition among the RDBMS’ staunchest allies. Google makes a compelling case for deployment, so long as your application can live within its constraints.

I see data management as the biggest impedence mismatch between the Google App Engine and the traditional web application design. However, over time I’m certain that a set of patterns will emerge to aid the masses in bridging the gap between the relational model and the Datastore API.

They have some great stuff in the Datastore API, and Christian and I are already at work putting together some offerings to help companies attracted to Google’s Infrastructure-as-a-Service model objectively evaluate and/or embrace the App Engine for their web application needs. Email me if you’d like to discuss.

So that being said, I’ll argue the following:

• Is it a giant piece of flypaper to help Google acquire the next generation of startups? Maybe, but I contend that the real killer next-generation apps will need more feature-rich networking capabilities. Let’s wait until we see what kind of XMPP/GoogleTalk integration comes along.
• Is it a sign that commodity web hosting providers are going the way of the corner video store? Perhaps.
• Is it a welcome counterbalance to the Ruby-on-Rails hype machine in the dynamic language arena? Yep.
• Is it a final blow in the in the Google vs. [INSERT NAME HERE] battle for the hearts, minds, and wallets of the IT crowd? No, the Infrastructure-as-a-Service game is just beginning. The Amazon infrastructure offerings are generalized and piecemeal (by design), whereas the Google App Engine is more of a “vertical” play tailored to traditional data-backed web applications.
• Is it a symbolic victory of Django over Pylons in the Python web frameworks world? No, it’s a victory for WSGI. Django just happens to be up on stage, ably and graciously accepting the award on WSGI’s behalf. I think that the stuff coming out of the App Engine ecosystem in the coming weeks will provide additional validation to the idea that WSGI is Python’s not-so-secret weapon.

Lastly, I’ll throw out some predictions, none of which are Earth-shattering:

• An Open Source application stack that emulates the Google App Engine SDK’s runtime environment will emerge from the community for folks that want to build applications that are compatible with the App Engine, but do not want to deploy their application to Google’s cloud at the current time. Also, this stack would provide an option for companies that deploy a custom app to the App Engine, but subsequently wish to take their application in-house.
• Within time, you’ll see integration with other elements of the Google infrastructure (Docs, GTalk, Search, etc.).
• The next language to be supported will be JavaScript, but that will not come for quite some time.

It seems that even the venerable Guido van Rossum (creator of Python) is weighing in on the ongoing Python web frameworks debate in two very good blog entries here and here.

Personally, I find this to be a fascinating time to be in this business. There have never been so many good technology stacks for building web applications. As I’ve mentioned in previous posts, Ruby on Rails is largely to thank for the current web application architecture renaissance. Python also has its share of very good frameworks to choose from.

However, I believe that in the coming years we will be moving away from a pure web/HTTP-based view of the world, and the value of a single server-side application being able to speak multiple protocols will become more and more apparent, as network-based applications stretch out beyond the traditional web browser.

The Python-based Twisted Networking Framework was developed to solve this specific problem of unifying multiple services in a single networked application. My favorite treatment of this topic is the chapter that Glyph contributed to Massively Multiplayer Game Development, titled Using the Twisted Framework for MMP Service Integration. Some of the code examples are a bit dated (it was published in 2003), but the conceptual material is worth the price of admission alone, IMO. Also, Abe Fettig’s new book Twisted Network Programming Essentials is quite good, with a couple of multi-protocol examples to boot.

Where will this leave the majority of the lightweight web frameworks? Unfortunately (and with absolutely no disrespect intended), it’s somewhat akin to the adage “Even if you win the rat race, you’re still a rat”. By this I’m referring to the fact that the web application framework that gains the most critical acclaim and popularity is still, by definition, a web application framework. Once you need your web app to talk to both web browsers and IM clients (or email, SMS, FTP, etc.), the game is fundamentally changed, and all bets are off.

Don’t get me wrong, web-based applications as we know them today are the dominant segment of the modern application development world, and will continue to be for the foreseeable future, but this doesn’t mean that there isn’t room for innovation beyond the typical capabilities of a mainstream web application. Specifically, presence and real-time messaging/collaboration will likely play increasingly important roles in the application development world, and Jabber/XMPP will likely become the de facto compliment to HTTP for stateful user interaction.

I’ll take this opportunity to cite a concrete example of the power of complimenting HTTP with XMPP-based messaging in a single server-centric application. We’re doing this exact type of thing with ProjectPipe today. ProjectPipe is our hosted project management solution. The web-based elements of the application talk traditional HTTP all day long between the browser and the server. However, we also provide rich integration between the web app and Microsoft Project and Excel residing on the user’s desktop. This is accomplished by using Jabber/XMPP as a compliment to HTTP (via a tiny client-side application that is installed on the user’s PC).

By building our application atop Twisted and Nevow, we are allowing our customers to do things that they otherwise couldn’t (without a bunch of additional strings attached). Having the user click on a web link and automagically generating an updated cut of their MS Project plan from server-based data is genuinely useful. Using the same technical underpinnings, users can also upload issue lists from Excel to the database server via a single click on a web page. From their perspective, transferring data back and forth between a remote database and their local desktop apps is easy to do.

Multi-protocol (HTTP/XMPP) server support has helped us take a reasonably complex integration scenario (bi-directional MS Project/Database integration) and make it appear unremarkable to our users, largely because we were able to envision and implement a solution that didn’t have to live within the architectural constraints imposed by a typical web application.