Another Prediction

I'm seeing a lot of noise in the blogodrome about REST these days. Ian Bicking says that continuation-based frameworks are doomed as they are workarounds for the web, based on the fact that that Bill de hÓra says REST has won some kind of epic battle against... what? I wasn't aware that REST was fighting a war against someone. In fact, I see no mention of what the war was against, or what the observable signs of the victory are. Is it a victory against WS-*? Over stateful web UIs?

It reminds me of another war, one that America "won" several years ago. The triumphant cries of "mission accomplished!" in the REST community ring hollow to me, although maybe this is just because I am personally working very hard to work around the web.

Don't get me wrong, the web is great and all, and REST is definitely a superior alternative to WS-*, if you want to do server-to-server information exchange. However, being better than WS-* is pretty easy; web services as they stand today are a nearly unmitigated disaster. I'm very happy to never have to work with them. The brief run-ins I've had with them (like the SOAP stuff in Universal Plug and Play) have been hellish nightmares.

Let's come at this whole "REST vs. rich applications" thing from another perspective.

I don't want to be writing software for the web. I'd much rather be writing a Python desktop application which makes its own socket connections, over its own protocol, and distributing that. It would provide a much richer experience. If I had total control of the user's desktop that's what I'd be doing. However, there are certain advantages that the web provides on a logistical level, unrelated to application architecture:

• Python isn't secure, and many security-conscious users (those in our target market) won't just go installing new applications willy-nilly (javascript is hardly as secure as it should be either, but at least there is an expectation that it should be, and constant effort put towards improving it)
• every computer has a web browser: often users have to use applications on computers they don't control
• "downloading" a web-based application is zero-friction; it by definition cannot involve any complex setup or barrier-to-entry
• web browsers have a very rich presentation layer which would be hard to re-implement in a native application, and schemes to access it through "native" APIs like PyXPCOM are, although higher-performance than generating HTML and Javascript strings, unfortunately unweildy and complex
• Many networking situations don't allow anything but HTTP, for completely ridiculous political reasons. This is a stupid, social restriction, usually put in place for "security" reasons by people who don't really understand the security issues involved, but nevertheless it is a very common problem
• finally, JavaScript might not be Python, but it is a highly dynamic language, and many of its flaws can be fixed (especially with a "real" language like Python on the server to help you out)

None of this has anything to do with the statefulness of the API, or the greatness of REST. Right now, it just makes more sense to write software for the browser than for any other client API, because the browser happens to be the most portable and most seamless deployment target.

These advantages also don't mean that the browser is free of problems. In addition to being a highly convenient deployment environment, the browser is at times an insanely bad development environment. None of the frustrations and difficulties encountered trying to work with the browser as a programming environment, nor the poor performance and poor usability that come from trying to treat it as a "regular" browser and doing all the work on the server, have given me a great deal of confidence in the generality and power of REST as a programming model or the web as a model for applications.

I don't care about application architecture per se - what I care about is an architecture for building usable, powerful applications which make it easy for the user to do what they want without a lot of waiting. That's hard any way you slice it, and by forcing everything your application does into tiny, stateless chunks, REST doesn't help that very much.

So, yes, Divmod Athena, like Seaside, is a giant workaround for the web, and it's turning out to be a pretty good one, at that. I'm pretty happy about that.

The Internet is a global, stateful, interconnected mesh of computers. It's an amazing achievement. The web is a historical accident, a hopefully brief one, which throws away much of the Internet's utility by forcing every networked application with a user interface into an almost-but-not-quite-too-narrow mold. Cookies have replaced authenticated connections, blobs of ever-changing unparseable HTML have replaced application-specific protocols, and dumb clients have replaced intelligent peers.

Here's my prediction. REST will continue to be useful as an architectural pattern for certain applications. However, it is in no way the only way to program "for the web". Workarounds for the web - like google mail, like Meebo, like YouOS, and like Divmod, will continue to be successful because they don't sacrifice the user's experience on the altar of architectural purity. There is no indication that they are going away any time soon.