This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Services vs. Applications Feed Title: Avi Bryant Feed URL: http://smallthought.com/avi/?feed=rss2 Feed Description: HREF Considered Harmful Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Avi Bryant

I think we have to draw a crucial distinction here, between web applications and web content. What Daniel is talking about is effectively content: here's the URL you go to if you want to see so and so's profile. That's great, and very useful, and in fact what the web was designed to do - but it's not an application. At most it's a service: it has a simple, well defined set of inputs and outputs, has minimal user interaction, and can be used from many places.

My argument is that this content or service view of the web doesn't scale up to the application level. It's like unix commands - it's nice that you can string together cat and sort and grep to do useful things, and that these provide services that anyone can take advantage of. But even though the loose coupling is great, you're going to have a real hard time writing emacs as a shell script. Or even pine. At a certain point, you need a richer model of state, of components, and of control flow. Building a complex application by stringing together a series of simple stateless parts, at the level of granularity we're talking about (essentially one user interaction per part), is madness.

Conversely, continuations aren't that useful for building web sites that are largely content, even dynamic content, or simple services. I make this clear whenever I give a talk on Seaside: it is targeted purely towards large, workflow-intensive applications with a lot of non-trivial user interaction. The lower boundary of what I would use Seaside for is a webmail application, or maybe one of the more complex blog packages. Anything simpler than that probably should be a couple of stateless CGI scripts.