[rco8786]

I agree on the face of things, but what the web is missing from the unix philosophy is an equivalent to |.

Without the ability to string multiple, focused tools together even tools that did one thing well(i.e., Evernote) will continue to add features until it does a bunch of things meh.

[dahart]

Absolutely! And just follow that to logical conclusions, to me it seems to answer the question of why we don't have it, right?

On the web, "|" (pipe) means integration with other services, and it comes with all the associated trials and tribulations. To make web pipes work, just to even get started, you first have to solve authentication and data format/transfer standards. Those things are a big pain, its not surprising that most services attempt to provide the service directly.

Unix pipes were designed for builders, technical people who understand the structure of the data they're piping around. Posix commands come in a minimum standardized set that work well together, and while there are some commands here and there to pipe structured and/or binary data, the core set and what most people use pipes on and love pipes for is plain text.

The internet just doesn't have the same foundation or purpose or user base, its usage is not centered around technical people building pipelines, so its not surprising that web services by and large haven't flocked to meet a unix analogy -- its technically much harder to do than writing unix, and its not even clear its even close to a useful thing to do, for most people.

[nostrademons]

The other big factor is that pipes only work because of the power of plain text. The output of every UNIX command is ASCII text, and most of the time, it's ASCII text with columns delimited by \t and rows delimited by \n. And there are command-line utilities like awk, cut, sed, & xargs for parsing & rearranging that text, and funneling it into formats that other commands understand.

The web has a variety of other content types - images, videos, applications, structured data - that don't map well to this model. Before you have interoperable webapps, you need to define common data formats for them to interop.

[TeMPOraL]

I disagree with that. Pipes seem to work in spite of plain text, being only made incredibly inefficient by it. A much better way is to send data structures through them (for which, btw. modern web is perfectly well-suited, with present JSON domination) - you can always render the data to text if you need, but you don't have to write arcane and bug-laden shotgun parsers with sed and awk because every step in UNIX polka means throwing away metadata.

Also: ditch plaintext for structured data and suddenly handling of other content becomes much, much easier, and they map perfectly to this model.

[Tiksi]

I pipe things in and out of ffmpeg, curl, convert (and the rest of imagemagick), mysql, tar, netcat, jq, etc pretty frequently, and that's all images, video, audio, applications and structured data. It seems to map quite well for all that.

[progman]

> To make web pipes work, just to even get started, you first have to solve authentication and data format/transfer standards.

Unix pipes have already solved the authentication problem. For instance, to stream a compressed harddisk copy safely between two hosts you can use the following statement:

  dd if=/dev/harddisk | gzip -9 | ssh user@xyz dd of=hdcopy.gz

Data format standards could be implemented right now using encrypted JSON or something like that. I would prefer Lisp s-expr by the way because they could be handled immediately in client/server lisp without any transformation.

[detaro]

RSS, Yahoo Pipes (RIP), ... come to mind as potential candidates for your pipes. Not a well-supported ecosystem sadly.

[egometry]

Webhooks are pretty pipe-y... but not every service implements them.

[hullo]

That's such a natural reaction to draw given the setup, that even the author of the article draws it, if one reads through.

[GavinMcG]

So... you agree on the depth of things as well? That's exactly what the author argued for.