On Sunday, in a New York Times story about Popfly, John Markoff wrote:

Because the company chose to design Popfly using a Microsoft Web graphics and animation technology called Silverlight, it will be treated with suspicion by an Internet universe that is increasingly committed to open standards.

Disclaimer: I work for Microsoft, and John Montgomery, who leads the Popfly project, has been a friend since our days together at BYTE. That said, I think this overstates Popfly’s relationship to Silverlight. Although the Popfly designer runs in Silverlight, mashups created in Popfly don’t require it. Most are just made of plain old HTML and JavaScript.

Elsewhere in the article, this quote from Tim O’Reilly appears:

Popfly shows me that Microsoft still thinks this is all about software, rather than about accumulating data via network effects, which to me is the core of Web 2.0. They are using Popfly to push Silverlight, rather than really trying to get into the mashup game.

Silverlight, as I’ve said, isn’t Popfly’s focus. I do agree that Popfly doesn’t operate in the cloud in the same way as, say, Yahoo! Pipes. While the article doesn’t mention Pipes, I often hear Popfly and Pipes mentioned in the same context. Both are mashup creators, but they are architecturally very different — in complementary ways. Because Pipes is a great example of data-oriented network effects, and because I’ve sometimes confused myself about the differences between Popfly and Pipes, it’s helpful to spell them out.

Mashup engine

Popfly’s mashup engine is a hybrid. There’s a service running in the cloud, but your browser can do a lot of work too.

Pipes’ mashup engine lives entirely in the cloud.

Sharing and discovery

Both systems provide a cloud-based environment for sharing and discovering mashups, and the components of mashups.

Inputs

Both systems can mash up data flowing from a variety of services on the web, including those that produce RSS feeds and other kinds of XML outputs.

Outputs

Popfly ends at the glass. The output is an HTML/JavaScript page or widget that renders in your browser. Although the components used to produce that output live in the cloud, the final result ends in your browser and isn’t available for downstream processing in the cloud.

Pipes can keep going. The output is a data feed that may or may not drive a browser-based display. But even when it does, the output is still available for downstream processing in the cloud — for example, as RSS.

Programming

In Popfly, you do basic stuff with a special-purpose visual programming language that runs in the cloud. You do advanced stuff with JavaScript running in the browser.

In Pipes, you only use a special-purpose visual programming language that runs in the cloud.

It gets confusing, even to me, because you can sometimes use both systems to achieve the same result. Consider this FluxnetTowers mashup in Popfly, which maps the locations of a worldwide network of C02 flux sensors. I just now made a simplified version in Pipes. I’m sure it’s possible to reproduce the annotations shown in the Popfly version. But from my perspective it’d be harder, because Pipes lacks the general-purpose programming available in Popfly thanks to JavaScript.

Suppose you wanted to include that same tower data in a widget on your WordPress blog, though. Here, Pipes would be the choice. WordPress lives in the cloud, and so does Pipes, so you can make Pipes produce a feed that WordPress consumes. But you couldn’t use Popfly in this scenario because a cloud-based service like WordPress can’t access the output of Popfly’s browser-based mashup engine.

Pipes likes to aggregate, transform, and filter data feeds within the cloud, and can produce a few kinds of renderings in your browser. Popfly likes to aggregate, transform, and filter data feeds from the cloud, and can produce arbitrary renderings in your browser. They’re complementary because Popfly can consume and render data feeds coming from Pipes.