> It was a brilliant mix of graphs for flow control, premade boxes for all common data manipulation and scripting for that extra feature if needed

I work for a startup that builds a dataflow app platform that fits that description nicely. We support gathering data from databases, files, APIs, etc., full graph-based flow control, strong .NET types on everything, tons of premade boxes for common operations, and support for C#/Python/R/F#/VB for custom data manipulation. Here's a quick example dataflow: http://blog.composableanalytics.com/2016/09/25/querying-data...

> I don't think you remember how the yahoo pipes worked.

True, I learned about it when it was already dead, but thought the goal was similar to the stuff Zapier offers and I would really like to try it. Not to automate stuff, but to checkout the visual editor.

Some screenshots from old Yahoo pipes that show a bit how that worked: https://imgur.com/a/p6uf0

The pipes goal was to transform data upon a pull, not move data on triggers. The client was likely a reader, while those event system mainly push to api.

Oh, Zapier is a programmer's nightmare.

Funny you say that -- engineers are one of Zapier's best customer personas. Quicker and easier to implement functionality than deploying code to the cloud. Plus, non-engineers can take over maintenance so engineers can work on more interesting things.

We also have code/scripting steps -- https://zapier.com/help/code/ or https://zapier.com/help/code-python/.

I work on Webmatr which is also for building integrations except its with Javascript code. The entire platform runs of API Specs (Swagger, Open API).

I just posted it on Show HN https://news.ycombinator.com/item?id=14469734 or the direct link https://webmatr.com

That's an odd response. Why do you feel that way?

Why/how so?